>> The standard allows a range of behavior, including the extremes
>> of "just like fork" and "nothing useful works". Extremes are bad.
>
> The standard allows "nothing useful works", so a portable program (or
> library) has to work in that case too, and the kernel implementers can
> rightly give you exactly that if convenient.
Kernel implementers can indeed produce a crappy kernel that meets the
letter of a standard. Why would they want to make a crappy kernel?
Hey, Windows NT is POSIX. Is that good enough for you?
>> What people seem to want most:
>> open, close, dup, dup2, _exit, execve, stat, fstat, lstat,
>> link, unlink, rename, lseek, fsync, read, write, socket...
>
> Then use fork(2). vfork(2) is just a lightweight (half)implementation of
> fork(2) for cases where you can get away with it.
Nope, fork() doesn't share the address space.
There isn't any reason to have a useless system call that nobody can
stand to use. It is completely reasonable to have a vfork() that lets
the child set up IO before the exec, but still shares address space.
-
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/