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

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 29 May 2019, Florian Weimer wrote:

> * 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.

It should be one command, reasonably efficient, that updates all the files 
for new syscalls (after possibly having changed one place in the source 
tree to give the new Linux kernel version number).

> 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).

(a) As with the global name list, there should be no such failures on a 
normal glibc build simply for building with a newer kernel version than 
the files were generated for, *unless* the kernel version number somewhere 
in the glibc source tree has been updated to say that version of glibc is 
meant to include all the syscalls from that kernel version - people should 
be able to build old glibc releases with new kernel headers without any 
resulting errors or test failures.  (I haven't checked whether this patch 
already implements that logic regarding version numbers.)

(b) A full build-many-glibcs.py build, let alone one with the "compilers" 
build stage (which is the one where kernel header installs happen), is 
excessively heavyweight for updating these lists.  It's something you 
might do *after* an update as part of testing it, not something that 
should need to be done both before and after the update.

What would seem more appropriate to me would be e.g. for 
build-many-glibcs.py to have a new "update-syscalls" option for what to 
do, which would require a previously built set of compilers (if they're 
part of what's needed for this process) and would build the Linux kernel 
headers only to extract syscall numbers from them.

A relevant subset of compiler / glibc configurations in 
build-many-glibcs.py would have an extra piece of information added to the 
script: the sysdeps path for the syscall list to update.  Running 
update-syscalls would then only need to build kernel headers for those 
configurations (or for the configurations named on the command line, if 
any - it should be possible to name configurations explicitly for the 
update, to allow for the case where different configurations need 
different compiler versions).

That seems like something that would do the update reasonably efficiently, 
since installing Linux kernel headers is fast, whereas rebuilding 
compilers and glibc isn't.

An ad hoc script for the update would also be fine, but if you need 
compilers for each configuration with a different syscall list, then 
integrating it in build-many-glibcs.py may be easier.

General note: if we move to using these lists in glibc, we should try to 
remove / avoid #ifdef conditionals on __NR_* in future where they are 
about whether the kernel headers are new enough, as opposed to whether a 
particular architecture has a particular syscall name.

-- 
Joseph S. Myers
joseph@codesourcery.com