This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] <bits/syscall.h>: Use an arch-independent system call list on Linux

On 04/06/2017 10:00 AM, Andreas Schwab wrote:
On Apr 05 2017, Florian Weimer <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]