Let me only answer your concrete questions.
: .. does your software support v6 UNIX?
Yes. I wrote large parts of my software under v6 UNIX.
It works on all Unix flavors. Such a pleasure.
: No, but there are gaping holes in the documentation. I'd most like
: to know what I can get from the raw system call, libc 5, recent glibc,
: and older glibc. For example, are file descriptors handled well?
The page says that vfork is just like fork.
>> DESCRIPTION
>> vfork, just like fork(2), creates a child process of the calling
>> process. For details and return value and errors, see fork(2).
>>
>> Under Linux, fork() is implemented using copy-on-write pages, so
>> the only penalty incurred by fork() is the time and memory
>> required to duplicate the parent's page tables, and to create a
>> unique task structure for the child. However, in the bad old days
Do you _know_ this? Off the top of my head I'd say the original process
will suffer minor page faults after the exec.
You can read this in the fork manpage. If you disagree, submit
a patch to the fork manpage.
>> BUGS
>> It is rather unfortunate that Linux revived this spectre from the
>> nated when proper system sharing mechanisms are implemented. Users
>> should not depend on the memory sharing semantics of vfork as it
>> will, in that case, be made synonymous to fork."
>>
>> Formally speaking, the POSIX description given above does not
>> allow one to use vfork() since a following exec might fail, and
>> then what happens is undefined.
Since the POSIX version is so useless, you can just consider vfork() to
be a Linux-specific call. On a modern Linux system, one may depend on
quite a few things.
Of course. But the posting by Reed H. Petty you reacted to
gave among the reasons for the introduction of this system call
standard compliance, portability and the like.
The present page stresses that it may be unwise to think
these are good reasons. Of course, as soon as you no longer
connect the BSD vfork with the Linux vfork then Linux got
a private system call (of which nobody so far has shown the use,
but which might be useful in special circumstances).
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/