This is the mail archive of the
mailing list for the glibc project.
Re: Official Linux system wrapper library?
On Sun, 11 Nov 2018, Florian Weimer wrote:
> The kernel does not know about TCB layout, so a lot of low-level
> threading aspects are defined by userspace.
> The kernel does not know about POSIX cancellation. Directly calling
> system calls breaks support for that.
Indeed. Where cancellation is involved, glibc needs to know exactly what
instructions might be calling a cancellable syscall and what instructions
are before or after the syscall (see Adhemerval's patches for bug 12683).
This involves an ABI that is not just specific to a particular libc, but
specific to a particular libc version. So it's inherently unsuitable to
put cancellable syscalls in libc_nonshared.a, as well as unsuitable to put
them in any kernel-provided library.
The interface for setting errno may also be libc-specific, for any
syscalls involving setting errno.
Syscalls often involve types in their interfaces such as off_t and struct
timespec. libcs may have multiple different variants of those types; the
variants available, and the ways of selecting them, are libc-specific and
libc-version-specific. So for any syscall for which the proper userspace
interface involves one of those types, wrappers for it are inherently
specific to a particular libc and libc version. (See e.g. how preadv2 and
pwritev2 syscalls also have preadv64v2 and pwritev64v2 APIs in glibc, with
appropriate redirections hased on __USE_FILE_OFFSET64, which is in turn
based on _FILE_OFFSET_BITS.)
There are many ABI variants that are relevant to glibc but not to the
kernel. Some of these involve ABI tagging of object files to indicate
which ABI variant an object is built for (and those that don't have such
tagging ought to have it), to prevent accidental linking of objects for
different ABIs. How to build objects for different userspace ABIs is not
something the kernel should need to know anything about; it's most
naturally dealt with at the level of building compiler multilibs and libc.
glibc deliberately avoids depending at compile time on the existence of
libgcc_s.so to facilitate bootstrap builds (a stripped glibc binary built
with a C-only static-only inhibit_libc GCC that was built without glibc
should be identical to the result of a longer alternating sequence of GCC
and glibc builds). I don't think any kernel-provided library would be any
better to depend on.
What one might suggest is that when new syscalls are added, kernel
developers should at least obtain agreement on linux-api from libc people
about what the userspace interface to the syscall should be. That means
the userspace-level types (such as off_t and struct timespec), and the
choice of error handling (returning error number or setting errno), and
the name of the header declaring the function, and the name of the
function, and how the syscall relates to thread cancellation, for example
- and whatever other issues may be raised.
Joseph S. Myers