From: Florian Weimer <fweimer@redhat.com>
To: Andreas Schwab <schwab@suse.de>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH] <bits/syscall.h>: Use an arch-independent system call list on Linux
Date: Thu, 06 Apr 2017 08:52:00 -0000 [thread overview]
Message-ID: <5c65bab1-dc89-ec35-c3a9-a38a9be0e060@redhat.com> (raw)
In-Reply-To: <mvmr316dkzb.fsf@suse.de>
On 04/06/2017 10:00 AM, Andreas Schwab wrote:
> On Apr 05 2017, Florian Weimer <fweimer@redhat.com> wrote:
>
>> Downstream, we have the problem that we need to deliver our glibc packages
>> before the kernel team finishes backporting system calls. This means that
>> the final glibc build before a release does not contain all the SYS_*
>> macros supported by the kernel headers.
>
> Why can't you just patch the kernel headers package?
Wasn't this rejected on this list because that would lead to a namespace
violation?
> With the uapi
> separation the kernel headers are pretty much independent of the kernel.
The system call list is generated in an architecture-specific manner. I
looked into this, most architectures use some construct which is rather
impenetrable. It's also very brittle in the sense that you can easily
change the userspace ABI by accident, and nothing in the kernel build
will tell you that you just did. It's also unclear how to convince
kernel maintainers to accept such a change (and think you'll have to
convince each architecture maintainer).
If the SYS_ macros come from the kernel side, we'd need some sort of
two-way handshake anyway (glibc tells the kernel that it's prepared to
accept SYS_ macros, the kernel tells glibc it has defined SYS_ macros,
and which point glibc does not do its own thing with the SYS_ macros).
So an incremental conversion looks possible.
I think that if we really need both sets of macros, the __NR_ and SYS_
macros should come from the same source. But that seems to be difficult
to achieve.
Thanks,
Florian
next prev parent reply other threads:[~2017-04-06 8:52 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-05 19:40 Florian Weimer
2017-04-06 8:00 ` Andreas Schwab
2017-04-06 8:52 ` Florian Weimer [this message]
2017-04-06 9:03 ` Andreas Schwab
2017-04-06 9:47 ` Florian Weimer
2017-04-06 10:07 ` Andreas Schwab
2017-04-06 10:12 ` Florian Weimer
2017-04-06 12:29 ` Andreas Schwab
2017-04-06 12:32 ` Florian Weimer
2017-04-06 12:49 ` Andreas Schwab
2017-04-06 13:24 ` Florian Weimer
2017-04-06 13:44 ` Andreas Schwab
2017-04-06 14:22 ` Florian Weimer
2017-04-06 14:37 ` Dmitry V. Levin
2017-04-21 10:06 ` Florian Weimer
2017-04-21 12:27 ` Andreas Schwab
2017-04-21 12:37 ` Florian Weimer
2017-04-21 18:31 ` Carlos O'Donell
2017-04-21 18:02 ` Andreas Schwab
2017-04-21 18:46 ` Florian Weimer
2017-04-21 19:08 ` Andreas Schwab
2017-04-21 19:15 ` Florian Weimer
2017-04-21 19:34 ` Andreas Schwab
2017-04-21 19:37 ` Florian Weimer
2017-04-21 19:40 ` Andreas Schwab
2017-04-21 19:57 ` Florian Weimer
2017-04-22 9:38 ` Andreas Schwab
2017-04-22 11:59 ` Florian Weimer
2017-04-22 13:45 ` Andreas Schwab
2017-04-22 14:22 ` Florian Weimer
2017-04-22 15:08 ` Andreas Schwab
2017-04-22 15:27 ` Florian Weimer
2017-04-22 15:37 ` Andreas Schwab
2017-04-22 15:51 ` Florian Weimer
2017-04-22 17:27 ` Andreas Schwab
2017-08-24 14:35 ` Carlos O'Donell
2017-08-24 15:15 ` Joseph Myers
2017-08-24 16:08 ` Carlos O'Donell
2017-08-24 18:49 ` Florian Weimer
2017-08-24 20:28 ` Joseph Myers
2017-08-25 14:30 ` Florian Weimer
2017-08-25 15:40 ` Joseph Myers
2017-08-25 15:57 ` Florian Weimer
2017-08-28 11:36 ` Joseph Myers
2017-08-28 12:35 ` Florian Weimer
2017-08-28 12:43 ` Joseph Myers
2017-04-23 0:35 ` synchronizing kernel UAPI and libc headers Dmitry V. Levin
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=5c65bab1-dc89-ec35-c3a9-a38a9be0e060@redhat.com \
--to=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=schwab@suse.de \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).