This is the mail archive of the
mailing list for the glibc project.
Re: Official Linux system wrapper library?
- From: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- To: Dave P Martin <Dave dot Martin at arm dot com>, Daniel Colascione <dancol at google dot com>
- Cc: nd <nd at arm dot com>, Florian Weimer <fweimer at redhat dot com>, "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>, linux-kernel <linux-kernel at vger dot kernel dot org>, Joel Fernandes <joelaf at google dot com>, Linux API <linux-api at vger dot kernel dot org>, Willy Tarreau <w at 1wt dot eu>, Vlastimil Babka <vbabka at suse dot cz>, Carlos O'Donell <carlos at redhat dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Wed, 14 Nov 2018 11:58:08 +0000
- Subject: Re: Official Linux system wrapper library?
- References: <CAKOZuesB4R=dCz4merWQN0FSCGrXmOgUUr4ienSbStBJguNv8g@mail.gmail.com> <email@example.com> <firstname.lastname@example.org> <CAKOZues5SEESpJU=6MDTrPXTA1KTZFGNQE4Lw4t0fO-WBTU62w@mail.gmail.com> <email@example.com> <CAKOZuetdgk1QYhx1538-98rFpogMin=8DkPnCtU9_=ip23Vk7w@mail.gmail.com> <20181113193859.GJ3505@e103592.cambridge.arm.com>
On 13/11/18 19:39, Dave Martin wrote:
> On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
>> We should adopt a similar approach. Shipping a lower-level
>> "liblinux.so" tightly bound to the kernel would not only let the
>> kernel bypass glibc's "editorial discretion" in exposing new
>> facilities to userspace, but would also allow for tighter user-kernel
>> integration that one can achieve with a simplistic syscall(2)-style
>> escape hatch. (For example, for a long time now, I've wanted to go
>> beyond POSIX and improve the system's signal handling API, and this
>> improvement requires userspace cooperation.) The vdso is probably too
>> small and simplistic to serve in this role; I'd want a real library.
> Can you expand on your reasoning here?
such lib creates a useless abi+api layer that
somebody has to maintain and document (with or
it obviously cannot work together with a posix
conform libc implementation for which it would
require knowledge about
thread cancellation internals, potentially TLS
for errno, know libc types even ones that are
based on compile time feature macros (and expose
them in headers in a way that does not collide
with libc headers), abi variants the libc supports
(e.g. softfp, security hardened abi), libc
internal signals (for anything that's changing
signal masks), thread internals for syscalls that
require coordination between all user created
threads (setxid), libc internal state for syscalls
that create/destroy threads.
and thus such lib does not solve the problems
of users who actually requested wrappers for
new syscalls (since they want to call into libc
and create threads).
there is a lot of bikesheding here by people who
don't understand the constraints nor the use-cases.
an actual proposal in the thread that i think is
worth considering is to make the linux syscall
design process involve libc devs so the c api is
designed together with the syscall abi.
unfortunately i still haven't seen a solution that
makes using linux uapi headers together with libc
headers reliable, continuously testing them in
isolation is useful, but that does not solve the
potential conflicts with libc definitions.