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 -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S. | lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer -- 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.
signature.asc
Description: This is a digitally signed message part.
