Re: Official Linux system wrapper library?
From: Andy Lutomirski
Date: Wed Nov 14 2018 - 09:46:53 EST
> On Nov 14, 2018, at 3:58 AM, Szabolcs Nagy <Szabolcs.Nagy@xxxxxxx> wrote:
>
>> 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
> without vdso).
Iâm not so sure itâs useless. Historically, POSIX systems have, in practice and almost by definition, been very C focused, but the world is changing. A less crufty library could be useful for newer languages:
>
> it obviously cannot work together with a posix
> conform libc implementation for which it would
> require knowledge about
>
> thread cancellation internals,
Thread cancellation is a big mess, and we only really need to support it because on legacy code. The whole mechanism should IMO be considered extremely deprecated.
> potentially TLS
> for errno,
errno is IMO a libc thing, full stop. A lower level library should *not* support 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),
This one is tricky. I wonder if we could instead get a C compiler extension to set libc declare that a given struct is a layout-compatible variant of another.
> abi variants the libc supports
> (e.g. softfp, security hardened abi),
Hmm.
> libc
> internal signals (for anything that's changing
> signal masks),
This is nasty, but see my cancellation comment above.
> thread internals for syscalls that
> require coordination between all user created
> threads (setxid),
We should just deal with this in the kernel. The current state of affairs is nuts.
> libc internal state for syscalls
> that create/destroy threads.
I disagree. If you make or destroy threads behind libcâs back, I think you get to keep both pieces.