Re: [PATCH] Linux: Add tables with system call numbers

[Florian Weimer <fweimer at redhat dot com>]

* Joseph Myers:

> Is there some automated process (a script included in the patch) that will 
> take a Linux kernel source tree and update all these headers with all new 
> syscalls in that Linux kernel version?  If not, there should be; otherwise 
> it would be excessively complicated to update for the new syscalls in a 
> new Linux kernel version.

I wanted to talk to you about this.  I'm open to suggestions.  I don't
know how you would like to handle this.

I find it a bit difficult to construct proper file system paths from the
architecture identifiers build-many-glibcs.py uses.  The existing
sysdeps hierarchy can express the syscall table sharing perfectly (no
two files are different), but it's not obvious where to put the table
based on the architecture.

Can you build with --keep failed once, after increasing the Linux
version in the global table?  The intent is that this causes the build
to fail if the kernel has unexpected __NR_ names and the tables need
updates (just like for the global name list).

I could write another output file which is actually a shell script and
which, when run, writes the new arch-syscall.h to the source tree.  (I
don't think a special merging procedure is required for this.)  As the
result of the build, we know the actual path of the arch-syscall.h file,
so that problem is easily solved.

The generated script would be located in a fixed location in the build
tree, and could be run like this:

for x in bmg/build/glibcs/*; do bash $x/misc/regenerate-arch-syscall.sh; done

For some types of changes, this will not work, of course.  For example,
if little-endian and big-endian syscall tables diverge where they are
now shared, an investigation will be needed how to express that split.
But I don't think we can avoid that.

Thanks,
Florian