Re: Official Linux system wrapper library?

[Joseph Myers <joseph@codesourcery.com>]

On Wed, 14 Nov 2018, Daniel Colascione wrote:

> > there is a lot of bikesheding here by people who
> > don't understand the constraints nor the use-cases.
> 
> Conversely, there's a lot of doubt-sowing from the other side that

"other side" is the wrong concept here in the first place - it's supposed 
to be a matter of cooperating projects trying to find good interfaces 
together.

Any new feature from the kernel that is meant to be of use to libcs is 
best designed in a way involving such cooperation (with multiple libcs).  
I concur with Zack's assessment in 
<https://sourceware.org/ml/libc-alpha/2018-11/msg00286.html> that a 
technical fix to process / communication issues cannot work here.  Any 
feature (e.g. syscall library) with a design coming solely from the kernel 
rather than a cooperative process is also likely to have an unsuitable 
design meaning it doesn't get used.  Once we have sufficient communication 
to design suitable interfaces *together*, "avoiding the need to 
communicate" becomes irrelevant as a design criterion anyway.

> After looking at the history of settid, signal multi-handler
> registration, and other proposed improvements running into the brick
> wall of glibc's API process, I think it's clear that requiring glibc
> signoff on new kernel interfaces would simply lead to stagnation. It's

That there was disagreement on some particular interface does not mean 
there are problems with the basic principle of working with libc 
maintainers (of multiple libcs, not just one!) to establish what the 
intended userspace C API to some new kernel interface should be, and to 
nail down the details of how the kernel interface is defined in the 
process.

(And as noted elsewhere, I think the main people objecting to generally 
having bindings for all non-obsolescent syscalls are no longer active in 
glibc.)

If the semantics of some proposed kernel interface, both at the syscall 
level and at the userspace C API level, are agreed e.g. by kernel and musl 
people, I'd think the API agreement from musl would be a good indication 
of the API also being suitable to add to glibc.  It's not necessary to get 
agreement from every libc on every API - but there should be agreement 
from *some* libc that is careful about API review.  If enough people with 
good sense about libc APIs have judged some API for a new syscall 
suitable, I expect other libcs can implement it even if it's not exactly 
the API they'd come up with themselves.

(I haven't seen enough comments on libc / kernel API design from people I 
know to be associated with bionic, uclibc-ng, etc., to judge if they also 
pay similarly careful attention to working out what a good C API design 
for some interface should be.  Note that there are musl people active on 
libc-alpha, which helps everyone arrive at a consensus on better C API 
designs.)

> The right answer is a move to an approximation of the BSD model and
> bring the primary interface layer in-house.

I could equally say we should take the kernel in-house and develop it to 
better support glibc - that if the kernel doesn't provide what we want, we 
should add the features to GNU Linux-libre and say that's the supported 
kernel for use with glibc.  It's an equally absurd statement in a context 
of multiple cooperating projects.

>  There's a lot of evidence that this model works.

There's a lot of evidence that the model of separately maintained Linux 
kernel and libc works (see: the number of devices using Linux kernels with 
a range of different libc implementations that meet different needs).

-- 
Joseph S. Myers
joseph@codesourcery.com