Hi James, On Monday 11 March 2013 07:50 PM, James Hogan wrote: > Hi Vineet, > > On 11/03/13 14:02, Vineet Gupta wrote: >> IMHO, the reasoning in those discussions is flawed. I agree that any "C" >> implementation of vfork is dubious - because there is no gaurantee that stack >> won't be clobbered when the vfork wrapper returns (unless arch has a >> Branch-n-link >> reg and this function simply uses that to return w/o touching the stack). >> However if the orig code vfork based "C" version existed it meant that some >> arch >> could use it. By changing it to use clone syscall with CLONE_VM | >> CLONE_VFORK | >> SIGCHLD we are simply changing the mechanism but with same semantics. Making >> it >> behave like fork is a semantical change. >> >> Note that even on MMU system - Busybox init uses vfork for certain cases to >> guarantee that parent only runs after child has exited - something which fork >> can't guarantee. >> >> And further, if an arch doesn't/can't use the common vfork.c it needs to >> define >> it's own vfork.S - but we can't make the generic definition semantically >> wrong. > > 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") -Vineet _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
