[PATCH 00/26] Linux cleanups enabled by built-in system call tables

[Florian Weimer]

* Lukasz Majewski:

>> This series cleans up various quirks in the Linux implementation
>> related to historic lack of system call numbers in several places.
>
> I'm wondering if those "system call tables" are generated from headers
> from contemporary Linux (e.g. 5.5) or the oldest supported by glibc
> (3.2)?

We are keeping them up-to-date with the latest released kernel headers.

> Moreover, I thought that the
>
> #ifdef __NR_foo_syscall__ define was to prevent from mismatch between
> newest glibc build with old linux kernel headers and running under yet
> another kernel.

It is very common that new system call numbers are backported.  This
happens even in upstream stable kernel series.  We expect that the glibc
sources are written in such a way that the __NR_* #ifdefs only cover the
availability of the number itself.  They are not treated as a proxy for
anything else (such as availability of types in headers or individual
header files).

I've posted a patch series that should clarify this: it removes historic
#ifdefs which are no longer needed under the new model:

  <https://www.sourceware.org/ml/libc-alpha/2020-02/msg00214.html>

> Is there any documentation regarding this new "approach"/"feature" with
> those "system call tables"?

I'm not sure what needs to be documented.  Only two things should have
changed:

* It is no longer necessary to write these #ifdefs.

* If one compiles glibc with older UAPI headers, you still get a full
  glibc with all features, as far is that possible.  Previously, some
  parts could be stubbed out (e.g., return ENOSYS unconditionally even
  if the kernel supports the feature).  Now, this only happens if Linux
  has not published required system call numbers.

Thanks,
Florian