On Tue, Sep 29, 2015 at 11:01 AM, Luca Bruno <[email protected]> wrote: > On Tuesday 29 September 2015 10:41:40 Ben Noordhuis wrote: > >> > 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? > >> If the system call wrapper is available in glibc 2.5, it's okay to >> drop libuv's wrapper if it causes problems. > > So I'm reading this as "let's keep current custom wrappers and rework the > problematic ones".
Correct. > In the specific cases, according to manpages: > * epoll_pwait has been introduced in (kernel 2.6.19, glibc 2.6) I could live with dropping epoll_pwait() altogether. I introduced it for an experimental feature that hasn't seen much use and can be comfortably emulated with pthread_sigmask(). > * preadv/pwrite have been introduces id (kernel 2.6.30, glibc 2.10) > > So it is not ok to just use glibc helpers in those cases, right? Correct. > As far as I understood, proper solution would be to change custom wrappers to > accommodate for kernel quirks instead. > > As a sidenote: just for documentation purposes, are the compatibility baseline > across supported systems noted down anywhere? Not sure if I wrote it down anywhere but it's basically the oldest RHEL release that RedHat still supports. -- 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.
