[PATCH 1/7] vfork: Fix flags when using clone syscall

Vineet Gupta Vineet.Gupta1 at synopsys.com
Tue Mar 12 10:10:19 UTC 2013


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





More information about the uClibc mailing list