Hi James, On Tuesday 12 March 2013 03:03 PM, James Hogan wrote: > Hi Vineet > > On 11/03/13 14:31, Vineet Gupta wrote: >> On Monday 11 March 2013 07:50 PM, James Hogan wrote: >>> Note that the vfork man page has a few relevant comments, such as this: >>> >>> CONFORMING TO >>> 4.3BSD, POSIX.1-2001. POSIX.1-2008 removes the specification of >>> vfork(). The requirements put on vfork() by the standards are weaker >>> than those put on fork(2), so an implementation where the two are >>> synonymous is compliant. In particular, >>> the programmer cannot rely on the parent remaining blocked until >>> the child either terminates or calls execve(2), and cannot rely on any >>> specific behavior with respect to shared memory. >>> >>> So it sounds like busybox generically relying on vfork to block the >>> parent would be incorrect. >> I agree, and we are not debating the usage of vfork in Busybox - I just >> mentioned >> it to drive the point about semantics. FWIW, ARC port doesn't use the vfork.c >> which I fixed (same as what Markos originally did). >> >> The point here is that we should not be changing semantics of vfork wrapper >> for >> legacy-syscall-abi vs. the legacy-abi one. If new vfork.c is wrong - it was >> already wrong - so we might as well delete it from common code (maybe make >> it arch >> local if an arch exists which can reliably use the "C" version") > My point was more that implementing vfork() with fork() isn't incorrect,
I don't disagree - Busybox needs to be fixed. > since according to the manpage "an implementation where the two are > synonymous is compliant". Fine - but it's still behavioral change as far as an existing API is concerned - independent of the ABI. So lets not "sneak" this, as part of largely orthogonal code changes - lets do it as a separate patch where we clearly document that this is not a fallout of using a newer unistd.h, but a rather semantical one. Further, IMO, the decision to make them behave similar or not, i.e. "the implementation" should be left to the kernel rather than in libc itself. -Vineet _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc