Hi Rich, On Monday 11 March 2013 07:01 PM, Markos Chandras wrote: > On 11 March 2013 13:21, Vineet Gupta <vineet.gup...@synopsys.com> wrote: >> Signed-off-by: Vineet Gupta <vgu...@synopsys.com> >> Cc: Markos Chandras <markos.chand...@imgtec.com> >> --- >> libc/sysdeps/linux/common/vfork.c | 3 ++- >> 1 files changed, 2 insertions(+), 1 deletions(-) >> >> diff --git a/libc/sysdeps/linux/common/vfork.c >> b/libc/sysdeps/linux/common/vfork.c >> index a85156d..c4ebe1f 100644 >> --- a/libc/sysdeps/linux/common/vfork.c >> +++ b/libc/sysdeps/linux/common/vfork.c >> @@ -13,10 +13,11 @@ extern __typeof(vfork) __vfork attribute_hidden; >> # if defined __NR_clone && !defined __NR_vfork >> # include <signal.h> >> # include <sys/types.h> >> +# include <sys/sched.h> /* CLONE_* */ >> >> pid_t __vfork(void) >> { >> - pid_t pid = INLINE_SYSCALL(clone, 4, SIGCHLD, >> + pid_t pid = INLINE_SYSCALL(clone, 4, (CLONE_VM|CLONE_VFORK|SIGCHLD), >> NULL, NULL, NULL); >> >> if (pid < 0) >> -- >> 1.7.4.1 >> >> _______________________________________________ >> uClibc mailing list >> uClibc@uclibc.org >> http://lists.busybox.net/mailman/listinfo/uclibc > Hi Vineet, > > It was suggested to use only the SIGCHLD flag for clone. See > http://lists.uclibc.org/pipermail/uclibc/2012-November/047161.html > and > http://lists.uclibc.org/pipermail/uclibc/2012-November/047277.html
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. -Vineet _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc