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". > -mike
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. (Providing returns-twice semantics in the same memory space is not possible without asm, except perhaps on some oddball architectures where the return address is stored in a register and the compiler chooses not to use the stack to store anything in the syscall wrapper function...and relying on that is very unsafe since the compiler's behavior could change.) Rich _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
