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

[Florian Weimer <fw at deneb dot enyo dot de>]

* Andreas Schwab:

> On Apr 22 2017, Florian Weimer <fw@deneb.enyo.de> wrote:
>
>> 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.
>
> Which your patch won't rectify.

It does, if we pick up the upstream (rc) system call list at the time
we build glibc for the point release.  At that point, we have all
potential system calls to backport.

>> 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.
>
> In which way does the macro not work?

I was mistaken.  As described, it will work.  But if we only backport
the the system call additions to the UAPI headers used by the
applications, this

#ifdef SYS_getrandom
  return syscall (SYS_getrandom, buf, len, 0);
#else
  errno = ENOSYS;
  return -1;
#endif

could fail with an error that __NR_getrandom is undefined.

I was confused because I find the notion to rebase to the upstream
kernel headers in a point release a bit preposterous.