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

[Florian Weimer]

On 04/06/2017 11:03 AM, Andreas Schwab wrote:
> On Apr 06 2017, Florian Weimer <fweimer@redhat.com> wrote:
>
>> On 04/06/2017 10:00 AM, Andreas Schwab wrote:
>>> On Apr 05 2017, Florian Weimer <fweimer@redhat.com> wrote:
>>>
>>>> Downstream, we have the problem that we need to deliver our glibc packages
>>>> before the kernel team finishes backporting system calls.  This means that
>>>> the final glibc build before a release does not contain all the SYS_*
>>>> macros supported by the kernel headers.
>>>
>>> Why can't you just patch the kernel headers package?
>>
>> Wasn't this rejected on this list because that would lead to a namespace
>> violation?
>
> I don't understand.  The kernel uapi headers fully respect namespace,
> at least those used by glibc.

I think the argument was that __NR_* should come from the kernel, and 
SYS_* should come from glibc, and that the kernel has no business 
defining SYS_* macros, purely based on namespace concerns.

>> The system call list is generated in an architecture-specific manner.
>
> Sure, but the commits that add the syscalls are easily separable.  All
> you need is to update the files underneath asm/unistd.h, which are
> pretty regular.

Not sure if we are talking about the same thing.  Our kernel-headers 
package comes from the kernel sources, 3.10 era.  Maybe you have 
frozen/explicit <asm/unistd.h> header in the sources.  We don't, we only 
have what upstream offers, which is Â… quite dynamic and heavily 
automated on some architectures.

>> I looked into this, most architectures use some construct which is
>> rather impenetrable.  It's also very brittle in the sense that you can
>> easily change the userspace ABI by accident, and nothing in the kernel
>> build will tell you that you just did.
>
> You only need to patch the kernel headers package, which is hopefully
> separate from the kernel.

Well, I see how this can simplify things.  This is not the case for us. 
I don't know the rationale behind the tight integration with the kernel 
package.  I'll ask around.

Anyway, I think for those who don't have separately maintained uapi 
headers (because they are building from upstream kernel sources), I 
think the relaxing of the build order requirement my proposed patch 
provides is still valuable.

Thanks,
Florian