This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus around kernel syscall wrappers?
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, Mike Frysinger <vapier at gentoo dot org>, Roland McGrath <roland at hack dot frob dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 18 Aug 2015 08:26:32 +0200
- Subject: Re: Consensus around kernel syscall wrappers?
- Authentication-results: sourceware.org; auth=none
- References: <55CCF8C6 dot 3060007 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1508132025440 dot 7713 at digraph dot polyomino dot org dot uk> <55CDF7A4 dot 50905 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1508141528371 dot 16651 at digraph dot polyomino dot org dot uk> <55CE4839 dot 3060701 at redhat dot com>
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. libinux-syscalls.so.N, 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. <https://sourceware.org/ml/libc-alpha/2013-07/msg00386.html>
> > 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 libinux-syscalls.so.
>
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.