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

[Florian Weimer <fweimer at redhat dot com>]

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