From: Joseph Myers <joseph@codesourcery.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: Willy Tarreau <w@1wt.eu>,
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
Daniel Colascione <dancol@google.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Joel Fernandes <joelaf@google.com>,
Linux API <linux-api@vger.kernel.org>,
Vlastimil Babka <vbabka@suse.cz>,
Carlos O'Donell <carlos@redhat.com>,
"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>
Subject: Re: Official Linux system wrapper library?
Date: Mon, 12 Nov 2018 16:59:54 +0000 [thread overview]
Message-ID: <alpine.DEB.2.21.1811121647310.6607@digraph.polyomino.org.uk> (raw)
In-Reply-To: <87zhufvntw.fsf@oldenburg.str.redhat.com>
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
joseph@codesourcery.com
next prev parent reply other threads:[~2018-11-12 17:00 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-10 18:52 Official Linux system wrapper library? Daniel Colascione
2018-11-10 19:01 ` Willy Tarreau
2018-11-10 19:06 ` Daniel Colascione
2018-11-10 19:33 ` Willy Tarreau
2018-11-10 19:20 ` Greg KH
2018-11-10 19:58 ` Vlastimil Babka
2018-11-12 2:03 ` Carlos O'Donell
2018-11-12 2:24 ` Carlos O'Donell
2018-11-12 2:36 ` Greg KH
2018-11-12 16:08 ` Jonathan Corbet
2018-11-12 20:03 ` Greg KH
2018-12-09 4:38 ` Randy Dunlap
2018-12-10 16:27 ` Jonathan Corbet
2018-12-10 17:39 ` Carlos O'Donell
2018-12-10 23:32 ` Randy Dunlap
2018-11-12 5:46 ` Andy Lutomirski
2018-11-11 6:55 ` Michael Kerrisk (man-pages)
2018-11-11 8:17 ` Willy Tarreau
2018-11-11 8:25 ` Daniel Colascione
2018-11-11 10:40 ` Florian Weimer
2018-11-11 10:30 ` Florian Weimer
2018-11-11 11:02 ` Willy Tarreau
2018-11-11 12:07 ` Florian Weimer
2018-11-11 10:53 ` Michael Kerrisk (man-pages)
2018-11-11 11:02 ` Florian Weimer
2018-11-12 16:43 ` Joseph Myers
2018-11-13 15:15 ` Carlos O'Donell
2018-11-11 11:11 ` Willy Tarreau
2018-11-11 11:46 ` Florian Weimer
2018-11-11 12:09 ` Willy Tarreau
2018-11-12 12:25 ` Florian Weimer
2018-11-12 17:36 ` Joseph Myers
2018-11-12 17:53 ` Greg KH
2018-11-12 18:09 ` Joseph Myers
2018-11-12 18:14 ` Randy Dunlap
2018-11-12 16:59 ` Joseph Myers [this message]
2018-11-14 12:03 ` Adam Borowski
2018-11-14 12:10 ` Florian Weimer
2018-11-16 21:24 ` Alan Cox
2018-11-11 11:09 ` Florian Weimer
2018-11-11 14:22 ` Daniel Colascione
2018-11-12 1:44 ` Paul Eggert
2018-11-12 8:11 ` Florian Weimer
2018-11-12 13:19 ` Daniel Colascione
2018-11-12 17:24 ` Zack Weinberg
2018-11-12 18:28 ` Daniel Colascione
2018-11-12 19:11 ` Florian Weimer
2018-11-12 19:26 ` Daniel Colascione
2018-11-12 22:51 ` Joseph Myers
2018-11-12 23:10 ` Daniel Colascione
2018-11-12 23:26 ` Joseph Myers
2018-11-12 22:34 ` Joseph Myers
2018-11-13 19:39 ` Dave Martin
2018-11-13 20:58 ` Andy Lutomirski
2018-11-14 10:54 ` Dave Martin
2018-11-14 11:40 ` Florian Weimer
2018-11-15 10:33 ` Dave Martin
2018-11-14 11:58 ` Szabolcs Nagy
2018-11-14 14:46 ` Andy Lutomirski
2018-11-14 15:07 ` Florian Weimer
2018-11-14 17:40 ` Joseph Myers
2018-11-14 18:13 ` Paul Eggert
2018-11-14 14:58 ` Carlos O'Donell
2018-11-14 17:15 ` Arnd Bergmann
2018-11-14 18:30 ` Joseph Myers
2018-11-14 15:40 ` Daniel Colascione
2018-11-14 18:15 ` Joseph Myers
2018-11-14 18:35 ` Daniel Colascione
2018-11-14 18:47 ` Joseph Myers
2018-11-15 5:30 ` Theodore Y. Ts'o
2018-11-15 16:29 ` Joseph Myers
2018-11-15 17:08 ` Theodore Y. Ts'o
2018-11-15 17:14 ` Joseph Myers
2018-11-15 21:00 ` Carlos O'Donell
2018-11-15 20:34 ` Carlos O'Donell
2018-11-23 13:34 ` Florian Weimer
2018-11-23 14:11 ` David Newall
2018-11-23 15:23 ` Szabolcs Nagy
2018-11-24 3:41 ` David Newall
2018-11-28 13:18 ` David Laight
2018-11-23 20:15 ` Daniel Colascione
2018-11-23 23:19 ` Dmitry V. Levin
2018-11-12 12:45 ` Szabolcs Nagy
2018-11-12 14:35 ` Theodore Y. Ts'o
2018-11-12 14:40 ` Daniel Colascione
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.1811121647310.6607@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=carlos@redhat.com \
--cc=dancol@google.com \
--cc=fweimer@redhat.com \
--cc=joelaf@google.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=vbabka@suse.cz \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).