> Ha! The first time around this vfork manpage only got
> smiling agreement and one comment on `broken' in the header.
> But now Albert D. Cahalan awoke and started ranting about politics..
I never saw any other messages. This isn't private mail that you
posted to linux-kernel?
I find it offensive that you are insulting kernel developers in
the system documentation. That isn't the right way to thank them!
I'd rather not even have a vfork man page. Just toss it out.
> 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.
You've tested this recently I assume, and such portability did
not detract from the features you could implement... sure.
Oh, portability ought to include VMS and MacOS too.
>> 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.
Well, that would be wrong -- but the man page doesn't say that.
>>>> 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.
Wild guesses and wishful thinking do not belong in system documentation.
If you don't know what the fork() penalty is, don't write about it.
>>>> 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.
To some extent, NetBSD is compatible. (to what extent?)
If the other BSD systems follow BSD, we may have a system
call that is portable to all free UNIX-like systems.
-
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/