This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919)


On Wed, 8 Jun 2016, Carlos O'Donell wrote:

> Regarding adding all linux syscalls, please see:
> https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers
> and the notes that Adhemerval provided.

Note that we have never managed to reach consensus on syscall wrappers.  
However, I now disagree with the idea of a separate libinux-syscalls.so 
library, or of only adding to libc.so those syscalls considered 
appropriate for the OS-independent GNU API.  I think that all non-obsolete 
syscalls that can meaningfully be used outside of glibc in a glibc-using 
program, even those extremely OS-specific or only likely to be of use to a 
handful of programs on an OS, should have wrappers added to glibc, and 
that we should not need to decide when adding them whether they are 
appropriate for the OS-independent GNU API (although if there is consensus 
for putting them in the OS-independent GNU API at the time they are added, 
they should go there at that point - other functions might be added to the 
OS-independent GNU API later).

We *do* still need to decide for such wrappers what the userspace types 
are to use with them, what the prototype is, what header declares the 
functions, and how errno and thread cancellation are handled.  And we *do* 
need documentation in the glibc manual for all such wrappers, and 
testcases in the glibc testsuite (though some such tests may not be able 
to do more than test that a call to the function compiles and links).

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]