From: Andy Lutomirski <luto@kernel.org>
To: "Carlos O'Donell" <carlos@redhat.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
Daniel Colascione <dancol@google.com>,
LKML <linux-kernel@vger.kernel.org>,
Joel Fernandes <joelaf@google.com>,
Linux API <linux-api@vger.kernel.org>
Subject: Re: Official Linux system wrapper library?
Date: Sun, 11 Nov 2018 21:46:13 -0800 [thread overview]
Message-ID: <CALCETrWuW3f=c5V0W2CaLGD63MbbsYAeDwz04B+n7iRyQn7vQw@mail.gmail.com> (raw)
In-Reply-To: <cd4717c4-4950-7513-726d-2e1873aeceb5@redhat.com>
On Sun, Nov 11, 2018 at 6:24 PM Carlos O'Donell <carlos@redhat.com> wrote:
>
> On 11/10/18 2:20 PM, Greg KH wrote:
> > Also, what about the basic work of making sure our uapi header files can
> > actually be used untouched by a libc? That isn't the case these days as
> > the bionic maintainers like to keep reminding me. That might be a good
> > thing to do _before_ trying to add new things like syscall wrappers.
> I agree completely. There are many steps in the checklist to writing
> a new syscall, heck we should probably have a checklist!
>
> Socially the issue is difficult because the various communities only
> marginally share the same network of developers, care about different
> features, or the same features with different priorities.
>
> That doesn't mean we shouldn't try to integrate better. As was pointed
> out, various people from the userspace and toolchain communities are
> going to LPC to do just this.
>
if you all want my two cents, I think that we should approach this all
quite differently than trying to get glibc to add a wrapper for each
syscall. I think the kernel should contain a list or list of syscalls
along with parameter names, types, and numbers, and this should get
processed during the kernel build to produce a few different
artifacts:
- A machine-readable version of the same data in a stable format.
Tools like strace should be able to consume it.
- A library called, perhaps, libinux, or maybe a header-only library.
It should have a wrapper for *every* syscall, and they should be
namespaced. Instead of renameat2(), it should expose
linux_renameat2(). Ideally it would use the UAPI header types, but
void * wouldn't be so bad for pointers.
P.S. Does gcc even *have* the correct asm constraints to express
typeless syscalls? Ideally we'd want syscalls to have exactly the
same pointer escaping semantics as ordinary functions, so, if I do:
struct timeval tv;
/* typed expansion of linux_gettimeofday(&tv, NULL); */
asm volatile ("whatever" : "+m" (tv) : "D" (&tv));
it works. But if I want to use a generic wrapper that doesn't know
that the argument is a pointer, I do:
asm volatile ("whatever" :: "D" (&tv));
then gcc seems to not actually understand that the value pointed to by
&tv is modified by the syscall. glibc's syscall() function works
AFAICT because it's an external function, and gcc considers &tv to
have escaped and can't see the body of the syscall() function.
next prev parent reply other threads:[~2018-11-12 5:46 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 [this message]
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
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='CALCETrWuW3f=c5V0W2CaLGD63MbbsYAeDwz04B+n7iRyQn7vQw@mail.gmail.com' \
--to=luto@kernel.org \
--cc=carlos@redhat.com \
--cc=dancol@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=joelaf@google.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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).