This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] <bits/syscall.h>: Use an arch-independent system call list on Linux
- From: Florian Weimer <fweimer at redhat dot com>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 6 Apr 2017 10:52:39 +0200
- Subject: Re: [PATCH] <bits/syscall.h>: Use an arch-independent system call list on Linux
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 617E480F7C
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 617E480F7C
- References: <email@example.com> <firstname.lastname@example.org>
On 04/06/2017 10:00 AM, Andreas Schwab wrote:
On Apr 05 2017, Florian Weimer <email@example.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
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