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

[Carlos O'Donell <carlos at redhat dot com>]

On 04/21/2017 08:26 AM, Andreas Schwab wrote:
> On Apr 21 2017, Florian Weimer <fweimer@redhat.com> wrote:
> 
>> Do you (and other distributions) build applications against these headers
>> as well, or are those only used for building glibc itself?
> 
> These are the kernel UAPI headers, so of course they are used by
> everything.

TLDR; This introduces changes which can break developer applications,
and the only benefit is to glibc.

The benefit to rebasing the kernel UAPI headers is that glibc will have 
an accurate list of SYS_ macros.

The disbenefit of the new kernel UAPI headers package is that application 
developers building applications must bear potentially new integration 
costs and header conflicts with their own headers (assume glibc does 
better header inclusion testing, and I have some patches for that).

My opinion is that the upstream kernel UAPI headers continue to change
without good management of the changes. I have seen at least 3 changes
which break header inclusion ordering and that would have caused application
build problems. None of the authors of those changes came to talk to us
about adding the right guards in glibc to prevent breakage. Worse there
have been discussions about deleting existing guards, that change would
break header inclusion order in one of the two directions, just to 
simplify libc-compat.h in the kernel (avoiding needing any libc-specific
knowledge). This does not seem conservative enough to me.

Are these problems passed on for the users to fix in those distributions
that track upstream kernel headers?

In the future I will continue to build my own builds with kernel master to
try catch all such changes, and add more tests to glibc to catch them too.

-- 
Cheers,
Carlos.