Ronald Khoo <ronald@demon.net> writes:

  > Ian.Dall@dsto.defence.gov.au wrote:
  >> I do think it would be nice if
  >> there was an easy way to turn of vfork semantics for portability
  >> testing

  > just how portable do you want to test for ?

  > Ultimate portability:
  > 	don't use vfork, exec, etc, just use system(3)

The kernel, of course, can't tell the difference, because system(3) is
implimented in terms of system calls. If people want to check for this
level of portability, then it really should be a compile time option.

In the context of this discussion, I am interested in portability to
other systems which have vfork, but impliment it differently.

  > Pretty Good:
  > 	program behaves the same with 3BSD vfork as with -Dvfork=fork

  > Can't really see the point of a "portability" "less 'v'" vfork 
  > which just has the original 4.4BSD semantics separately from
  > those two ?

I agree. In the context of this discussion, I am interested in
portability to other systems which have vfork, but impliment it
differently. On some systems (linux is one [calm down everybody!]),
vfork is an alias for fork.

I'd think a flag settable via sysctl which caused a vfork system call
to execute the fork system call code would be easy to do.

Ian