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 02:46 PM, Florian Weimer wrote:
> * Andreas Schwab:
> 
>> On Apr 21 2017, Carlos O'Donell <carlos@redhat.com> wrote:
>>
>>> TLDR; This introduces changes which can break developer applications,
>>> and the only benefit is to glibc.
>>
>> I don't understand.  You cannot build anything without the kernel UAPI
>> headers.
> 
> I think we have to freeze the kernel headers along a distribution
> release branch, and update them only insofar we backport things to
> this distribution release branch.
> 
> My proposal aims to avoid a build order depedency between the
> backports landing in the distribution kernel, and a glibc rebuild.
> For point releases, glibc and kernel may be developed on different
> schedules, and if the glibc build uses my proposed patch, it can use
> the upstream system call list as a superset of what's going to be
> backportable for the next point release.
 
We never reached consensus on this thread.

I'm including Joseph here because he often does the Linux upstream
updates and will have an opinion here on this dependency.

Patch is here:
https://sourceware.org/ml/libc-alpha/2017-04/msg00082.html

Restating the problem:
=====================

The current glibc builds have a dependency on recent kernel headers
in order to generate an updated bits/syscall.h.

This means downstream distributions need a frozen kernel headers
package *before* glibc can be built.

In many downstream distributions this is not the case, glibc is built
and frozen for a release, and then the kernel is finally built. This
means that new syscalls may not appear in bits/syscall.h unless glibc
is rebuilt with the newer kernel's headers.

In theory the UAPI headers from the latest GA kernel could be used and
that would solve this problem, but now you are *forcing* downstream
distributions to adopt these new UAPI headers, and any consequences they
bring.

Alternatively you could patch old UAPI headers with the backported
syscalls, but the distro might not know exactly what will bi included in
the kernel release until after glibc is built. Again a coordination and
compilation ordering problem.

In order to give flexibility to downstream distributions *and* decouple
the glibc build from the kernel's syscall list, the patch proposes the
following:

- That glibc maintain an arch-independent syscall list.

- That glibc use that list to generate bits/syscall.h.

This releases downstream distros from having to use the latest UAPI
headers, and still gives them the flexibility to build glibc before
the kernel or kernel headers are built.

Consensus
=========

This issue has come up again in the downstream distributions that
I support.

Andreas,

My summary of your position is this:

* Patch the kernel headers package first, then build glibc, and you
  won't have this problem.

This position presupposes:

* A kernel to create the kernel headers package, but such a kernel
  may not be ready when you freeze glibc early for distro testing.

or

* Use the upstream kernel. Which may break other things with poorly
  tested UAPI header changes.

Your suggestion, while being valid, excludes other downstream
development models. The only thing that really matters here is
that we can generate bits/syscall.h without needing to have all
the other kernel stuff ready.

Florian,

Your position is this:

* Having glibc contain a syscall list decouples glibc's syscall.h
  generation from the kernel. This means distributions can more flexibly
  adopt build orders, and updates that meet their requirements.

Andreas, Florian,

Do we have any strong technical objection to this patch?

For example, is this duplication of a syscall list mean that we need to
keep it up to date in glibc? Yes, just like we keep all the other kernel
stuff up to date when we update from released kernels.

In fact I believe this list will be one day replaced with a unified
linux syscall data file that we can use to generate the syscall wrappers
from, and which other packages will also use [1].

In summary:

Andreas: Do you have a sustained opposition to decoupling glibc from the
         need to have an updated kernel headers in order to generate an
         updated bits/syscall.h?

Pro: Allows downstream distributions the flexibility to order their builds
     as they need to. Doesn't require them to use upstream linux kernel
     headers.

Cons: Glibc has to maintain a global list of syscalls, along with all the
      other kernel pieces it maintains.

Comments?

-- 
Cheers,
Carlos.

[1] "Formal description of system call interface"
https://lkml.org/lkml/2016/11/6/126