On Tue, Sep 29, 2015 at 10:09 AM, Luca Bruno <[email protected]> wrote: > Hi all, > I'd like to ask Ben and Saúl some clarification about the current and future > status of the Linux syscalls wrappers at src/unix/linux-syscalls.c. > > At the moment, libuv contains some logic to try to detect if a syscall is > available on the running kernel version, thus bypassing the libc helpers in > favor of direct calls to syscall(2). > > In several cases, this caused issues/regression as Linux has several > architecture-specific quirks regarding syscall semantic. > In particular: > * #473 is a failure on hppa,mips,powerpc due to offset alignment [0] > * #335 is a failure on mips/mipsel due to epoll_pwait sigmask size > > The hinted solution seems to be to completely drop the homemade wrappers. > However I am confused by the baseline requirements shown in #351 [2] > (kernel 2.6.18 + glibc 2.5). > > How should we proceed for the future there? Should we just drop all the > syscall wrappers and assume libc has them all? Or introduce checks for them at > configure time? Or just drop the problematic ones? > > Cheers, Luca > > [0] https://github.com/libuv/libuv/issues/473 > [1] https://github.com/libuv/libuv/issues/335 > [2] https://github.com/libuv/libuv/pull/351
If the system call wrapper is available in glibc 2.5, it's okay to drop libuv's wrapper if it causes problems. Configure time checks are not allowed because libuv may end up running on an older system than the one it was compiled on. -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
