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

[Florian Weimer]

* Andreas Schwab:

> On Apr 21 2017, Florian Weimer <fw@deneb.enyo.de> wrote:
>
>> The downside is that you get SYS_ macros for system calls which are
>> not implemented in the distribution kernel. 
>
> I don't understand.  Didn't you say the system call has been backported?

Yes, we seem to have a misunderstanding.  If I understand you, you say
some distributions are doing this on a stable branch:

  * Backport a system call to the actual kernel package.
  * Backport the system call addition to the kernel headers package.
    (changing the UAPI headers used by glibc and applications).
  * Rebuild glibc to generate the SYS_ macro list.

This does not work for some distributions because the order is like
this:

  * Rebuild glibc for a point release.
  * Backport a system call to the actual kernel package.
 (* Backport the system call addition to the kernel headers package.)

Whether the last step happens or not is immaterial in this context.
You won't get the SYS_ macro with this build order.

What could work is this:

 (* Backport system calls to the kernel package.)
  * Rebase the kernel headers package to the latest upstream version
    (changing the UAPI headers used by glibc and applications).
 (* Backport more system calls to the kernel package.)
  * Rebuild glibc to generate SYS_ macro list.
 (* Backport even more system calls to the kernel package.)

This way, the glibc build would provide a full SYS_ macro list,
assuming that the kernel backporting does not overtake upstream (which
seems unlikely).  However, some of the SYS_ macros will not work
because the distribution kernel will lake the correspondign __NR_
macros.