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

[Florian Weimer <fw@deneb.enyo.de>]

* Joseph Myers:

> I do not object to bounding the SYS_* API exported by glibc to a set of 
> system calls known to that glibc version.
>
> I do object to having a test we know will fail when someone builds glibc 
> with a newer set of kernel headers than that version of glibc.  That is, I 
> think the test should allow extra __NR_* if the kernel headers have a 
> newer (major.minor) version number than the kernel version listed in 
> syscall-names.list.  That way, the test is still effective in development 
> as long as people update the kernel number when adding syscalls to the 
> file or doing other new-kernel-version updates, without causing spurious 
> failures for people building past release versions / branches of glibc.

Hmm.  The way the patch currently works, a missing built-in system
call name is actually a user-visible bug because they won't get the
SYS_* macro they expect (based on the kernel headers).  This is why I
made it a test failure.

If we don't want that, I need to resurrect the old magic list
generation and use its results to augment the built-in list.  The test
can remain as-is, but it will no longer fail.

A compromise would be to assume that for mixed-mode architectures
(e.g., i386/x86-64/x32), the set of missing system calls is the same
across all architectures, then we could still leave out the
complicated list generation logic.

> I'd expect LC_ALL=C to have to be set when running the various awk scripts 
> (at least those depending in any way on the ordering of the syscall list).

Right, that needs to be fixed.