Hi Vineet,
On 12/03/13 10:10, Vineet Gupta wrote:
> On Tuesday 12 March 2013 03:03 PM, James Hogan wrote:
>> On 11/03/13 14:31, Vineet Gupta wrote:
>>> 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.
It's too late now, but in any case it's not really an orthogonal change:
#ifdef __NR_vfork
#define __NR__vfork __NR_vfork
_syscall0(pid_t, __vfork)
#else
/* Trivial implementation for arches that lack vfork */
pid_t __vfork(void)
{
return fork();
}
#endif
Markos' final patch effectively changed the above to implement the #else
case using clone to do the fork. It's not quite written that way
unfortunately as it originally tried to do the vfork in c.
Cheers
James
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
