This is the mail archive of the 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: Consensus around kernel syscall wrappers?

On Fri, Aug 14, 2015 at 03:57:45PM -0400, Carlos O'Donell wrote:
> On 08/14/2015 11:33 AM, Joseph Myers wrote:
> > On Fri, 14 Aug 2015, Carlos O'Donell wrote:
> > 
> >> (a) All Linux syscalls that are considered useful for the OS-independent
> >>     GNU API should be added immediately.
> > 
> > With documentation and testcases, and consensus is needed in each case on 
> > the header that has the declaration, the types involved, conventions for 
> > errno / cancellation, etc.
> Agreed. There is much work to be done for each syscall to be added, but that
> can progress normally just like adding any new API. The most difficult thing
> is probably arguing that it *should* be included in the OS-independent GNU API.
> >> (b) All Linux syscalls that are not considered useful for the OS-independent
> >>     GNU API should be added to an AS_NEEDED library named appropriately
> >>     e.g., where this library is part of the implementation
> >>     and must be updated in lock-step with the implementation to ensure that
> >>     cancellation and other things are kept synchronized. It should not be a static
> >>     library to avoid security issues and to allow it to be updated.
> > 
> > With the same requirements as above on documentation, testcases etc., 
> > though there might be a bit more of a case here for the documentation just 
> > saying it calls a particular Linux syscall and giving the types / error 
> > handling / cancellation information.
> > 
> > (The absolute minimum for a testcase verifies that a call compiles and 
> > links.  Cf. <> 
> > regarding existing interfaces that aren't even tested to that minimal 
> > extent.)
> Agreed again. I Think that basically (a) and (b) are the same in terms of
> thoroughness of documentation, testing, etc. It's just that with (b) the
> thorough argument of inclusion in the OS-independent GNU API is missing.
> The very fact that linux-api decided on the syscall is sufficient to get it
> into the

While I am ok as interface of b) you need to expose lot of libc to new
library. It would need to use vdso for example. Also in gettid best way
is simply read it from glibc tcb and these abi concerns force us to add
glibc dependency so upgrading would be problematic.

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