> 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.
