On Thu, 2012-04-26 at 22:50 -0400, Mike Frysinger wrote: > On Thursday 26 April 2012 10:14:30 Mark Salter wrote: > > A few places in the code check for existence of vfork by testing if > > __NR_vfork is defined. Newer kernels don't have a vfork syscall in > > which case, the library implements the vfork function using > __NR_clone. > > > > 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".
The problem wasn't that the kernel defined __NR_vfork. Originally the kernel did and libc used it for the vfork function. We then dropped vfork from the kernel and implemented the libc vfork function using __NR_clone. So, we had a libc vfork function but libc didn't think we did because __NR_vfork wasn't defined. We could indeed just use "#if !__NR_vfork && !__NR_clone". I used that originally but the whole idea of testing for a syscall to check if libc implemented a C function seemed wrong (since the C function doesn't necessarily exist even if the syscall does). --Mark _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc