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