[PATCH] fix test for vfork function
vapier at gentoo.org
Fri Apr 27 05:43:59 UTC 2012
On Friday 27 April 2012 01:07:42 Rich Felker wrote:
> On Fri, Apr 27, 2012 at 12:58:33AM -0400, Mike Frysinger wrote:
> > On Thursday 26 April 2012 23:08:36 Rich Felker wrote:
> > > On Thu, Apr 26, 2012 at 10:50:57PM -0400, Mike Frysinger wrote:
> > > > > This patch adds a test for __UCLIBC_VFORK_USES_CLONE__ feature
> > > > > definition which an architecture may define if vfork is implemented
> > > > > using clone.
> > > >
> > > > err, if your kernel arch doesn't have vfork, why is it defining
> > > > __NR_vfork ? i.e. the uClibc logic should not require
> > > > __UCLIBC_VFORK_USES_CLONE__. it can deduce that itself by saying "if
> > > > !vfork && !fork && clone".
> > >
> > > I don't think !fork belongs in the test. Implementing vfork with clone
> > > is better than implementing it as just a duplicate of fork. But I'm
> > > not sure how having macros for this can be useful at all since,
> > > whatever syscall is used to implement vfork, it has to be written in
> > > asm unless it's just a duplicate of fork.
> > if we've got a C-callable clone(), i think we can implement a C vfork()
> > on top of that. it'd be a tail call, so the semantics of parallel stack
> > usage should be the same.
> > i know ia64 implements vfork() with clone(), but it does it in asm, so
> > that doesn't make my case :p.
> The standard libc wrapper API for the clone syscall does not return
> twice. It calls a function (function pointer argument) in the new
> thread/process. This makes it useless for implementing vfork.
err, yeah, i was thinking it only took flags
> theory it could be designed to return in the child as well if the
> called function returns, but I think the usual behavior is for it to
> call SYS_exit (exit thread) in that case..
probably could be done with a bit of care in C and writing a dedicated clone
func, but i don't think this would really gain anything, and would be hard to
write in a way that didn't just end up bloating.
since every arch has implemented vfork() and clone() in assembly anyways,
requiring someone who doesn't have a __NR_vfork isn't anything new. as
mentioned, ia64 already does this, and looking a little closer, seems that
mips does as well.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the uClibc