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 11:03 AM, Andreas Schwab wrote:
> On Apr 06 2017, Florian Weimer <fweimer@redhat.com> wrote:
>
> > 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?
>
> I don't understand.  The kernel uapi headers fully respect namespace,
> at least those used by glibc.

I think the argument was that __NR_* should come from the kernel, and 
SYS_* should come from glibc, and that the kernel has no business 
defining SYS_* macros, purely based on namespace concerns.

> > The system call list is generated in an architecture-specific manner.
>
> Sure, but the commits that add the syscalls are easily separable.  All
> you need is to update the files underneath asm/unistd.h, which are
> pretty regular.

Not sure if we are talking about the same thing.  Our kernel-headers 
package comes from the kernel sources, 3.10 era.  Maybe you have 
frozen/explicit <asm/unistd.h> header in the sources.  We don't, we only 
have what upstream offers, which is … quite dynamic and heavily 
automated on some architectures.

> > 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.
>
> You only need to patch the kernel headers package, which is hopefully
> separate from the kernel.

Well, I see how this can simplify things.  This is not the case for us. 
I don't know the rationale behind the tight integration with the kernel 
package.  I'll ask around.

Anyway, I think for those who don't have separately maintained uapi 
headers (because they are building from upstream kernel sources), I 
think the relaxing of the build order requirement my proposed patch 
provides is still valuable.

Thanks,
Florian