From: Joseph Myers <joseph@codesourcery.com>
To: Daniel Colascione <dancol@google.com>
Cc: Florian Weimer <fweimer@redhat.com>,
Zack Weinberg <zackw@panix.com>,
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Joel Fernandes <joelaf@google.com>,
Linux API <linux-api@vger.kernel.org>, Willy Tarreau <w@1wt.eu>,
Vlastimil Babka <vbabka@suse.cz>,
Carlos O'Donell <carlos@redhat.com>,
GNU C Library <libc-alpha@sourceware.org>
Subject: Re: Official Linux system wrapper library?
Date: Mon, 12 Nov 2018 23:26:58 +0000 [thread overview]
Message-ID: <alpine.DEB.2.21.1811122313000.18130@digraph.polyomino.org.uk> (raw)
In-Reply-To: <CAKOZueuM=3pxuXaJU4v571daWFCTJ1LYO-ApD6MrD7313RNYfQ@mail.gmail.com>
On Mon, 12 Nov 2018, Daniel Colascione wrote:
> I initially wanted to put the APIs in libc. I still do. But that's
> proving to be impractical, for the reasons we're discussing on this
> thread.
Well, your proposed APIs didn't attract consensus among libc developers.
> > (I can imagine *other* parts of the toolchain being involved, if e.g. you
> > want to have a good way of checking "is the address of the instruction
> > causing this signal in this library?" that works with static as well as
> > dynamic linking - for dynamic linking, I expect something could be done
> > using libc_nonshared and __dso_handle to identify code in the library
> > calling some registering function. And indeed there might also be new
> > kernel interfaces that help improve signal handling.)
>
> Again: you're blocking a practical solution for the sake of some
> elegant theoretical implementation that will never arrive, and so the
I'm not - I'm observing various areas that might be open to improvements
related to signal handling, not saying improvements in one area are a
prerequisite to improvements in another. I'm exploring the problem and
solution space, and collectively exploring the problem and solution space
is an important part of trying to work out where there might be useful
future improvements related to the general issue of signal handling.
Exploring the problem and solution space can include coming to the
conclusion that an idea that seems obvious is in fact a bad idea, or in
fact orthogonal to other ideas that are independently useful - those
things are still useful in yielding a better rationale for taking a given
approach.
> > In the absence of consensus for adding such a new API for signals to
> > glibc, it's unlikely one would get consensus for glibc to depend on some
> > other library providing such an API either.
>
> glibc would continue using an unsupported legacy system call
> interfaces in lieu of a supported low-level interface library?
The Linux kernel supports the interfaces that people actually use, on the
principle of not breaking userspace, not the interfaces that someone would
like to declare to be the supported ones. We'd use the interfaces that
seem suitable for use by glibc, and direct syscalls seem more suitable to
me than any kernel-provided userspace library.
Naturally a library invented in the kernel on the basis of not liking what
libc people are doing or not doing is unlikely to be suitable for use by
libc (and use together with libc of anything in it that interferes with
libc functionality such as sigaction might be explicitly discouraged by
libc maintainers, just as e.g. direct use of clone can be discouraged) -
whereas interfaces developed collaboratively with libc implementations and
getting consensus from those users are more likely to be of use to libc
implementations.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2018-11-12 23:27 UTC|newest]
Thread overview: 99+ 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:40 ` Florian Weimer
2018-11-11 10:30 ` 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 12:07 ` Florian Weimer
2018-11-11 10:53 ` Michael Kerrisk (man-pages)
2018-11-11 11:02 ` Florian Weimer
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 11:46 ` Florian Weimer
2018-11-11 12:09 ` Willy Tarreau
2018-11-12 12:25 ` Florian Weimer
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
2018-11-14 12:03 ` Adam Borowski
2018-11-14 12:10 ` Florian Weimer
2018-11-14 12:10 ` Florian Weimer
2018-11-16 21:24 ` Alan Cox
2018-11-11 11:09 ` Florian Weimer
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 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: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 [this message]
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-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 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 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 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.1811122313000.18130@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 \
--cc=zackw@panix.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.