[PATCH] <bits/syscall.h>: Use an arch-independent system call list on Linux
Florian Weimer
fweimer@redhat.com
Thu Apr 6 10:12:00 GMT 2017
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
More information about the Libc-alpha
mailing list