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 12:07 PM, Andreas Schwab wrote:
> On Apr 06 2017, Florian Weimer <fweimer@redhat.com> wrote:
>
> > 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.
>
> I don't know why you are talking about SYS_.  All that the kernel
> defines are __NR_.  The SYS_ defines are pure glibc stuff.

The separation is what causes problems because there is no way to tell 
the C preprocessor to export all __NR_* macros as SYS_* macros, too.

As a result, current glibc has this elaborate dance at built where it 
runs “gcc -E -dM” (with varying additional parameters to get the 
lib/libx32/lib64 variants).  I want to get rid of that because it means 
that if you upgrade the kernel headers after building glibc, the SYS_* 
and __NR_* macros drift apart.

> > Not sure if we are talking about the same thing.  Our kernel-headers
> > package comes from the kernel sources, 3.10 era.
>
> Consider splitting it out, they are really independent.  Then you can
> update the kernel headers without touching the kernel.

But I'd still have the issue that the kernel headers contain only the 
__NR_* macros, not the SYS_* macros.

If you think that SYS_* macros should remain glibc business, then I 
think the patch I posted is the right approach to simplify independent 
kernel header updates (whether they come from a separate package, or 
directly from the upstream sources).

Thanks,
Florian