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

  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.

I would have liked to address this by phasing out the SYS_* macros, but 
this suggestion was not received favorably during a previous discussion.

An ideal solution would generate the SYS_* macros when the glibc 
development package is installed, based on the already-installed kernel 
headers.  Our RPM version does not support delayed script execution, so 
there is significant risk that we end up with a dependency loop, due to 
which the generation step could fail.

So I'm proposing the attached patch as an alternative.  It uses a list 
of system call names and generates a <bits/syscall.h> file from that 
which has items of the form

#ifdef __NR_write
# define SYS_write __NR_write
#endif

The idea is to define only those SYS_ macros which actually exist in the 
kernel headers as __NR_ macros.  Therefore, we only need a single system 
call list across all architectures, and the generated header file is no 
longer architecture-specific, either.  The -dM-based macro extraction 
remains as a (much simplified) test case.  It fails if the kernel 
headers contain __NR_ macros not currently listed in the glibc source tree.

I think the increased predictability of glibc builds might be worth it 
upstream as well.  The cost is that we now have to update the list 
periodically, but that can be done when the kernel version embedded in 
scripts/build-many-glibcs.py is increased.

The included list of system call names is based on the currently 
building build-many-glibcs.py targets (that is, hppa and coldfire are 
missing).  We can easily adjust it once we get more buildable architectures.

Comments?

Thanks,
Florian
  

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?  With the uapi
separation the kernel headers are pretty much independent of the kernel.

Andreas.
  

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?

> With the uapi
> separation the kernel headers are pretty much independent of the kernel.

The system call list is generated in an architecture-specific manner.  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.  It's also unclear how to convince 
kernel maintainers to accept such a change (and think you'll have to 
convince each architecture maintainer).

If the SYS_ macros come from the kernel side, we'd need some sort of 
two-way handshake anyway (glibc tells the kernel that it's prepared to 
accept SYS_ macros, the kernel tells glibc it has defined SYS_ macros, 
and which point glibc does not do its own thing with the SYS_ macros). 
So an incremental conversion looks possible.

I think that if we really need both sets of macros, the __NR_ and SYS_ 
macros should come from the same source.  But that seems to be difficult 
to achieve.

Thanks,
Florian
  

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.

> 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.

> 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.

Andreas.
  

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
  

On Apr 06 2017, Florian Weimer <fweimer@redhat.com> wrote:

> 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.

I don't know why you are talking about SYS_.  All that the kernel
defines are __NR_.  The SYS_ defines are pure glibc stuff.

> Not sure if we are talking about the same thing.  Our kernel-headers
> package comes from the kernel sources, 3.10 era.

Consider splitting it out, they are really independent.  Then you can
update the kernel headers without touching the kernel.

Andreas.
  

On 04/06/2017 12:07 PM, Andreas Schwab wrote:
> On Apr 06 2017, Florian Weimer <fweimer@redhat.com> wrote:
>
>> 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.
>
> I don't know why you are talking about SYS_.  All that the kernel
> defines are __NR_.  The SYS_ defines are pure glibc stuff.

The separation is what causes problems because there is no way to tell 
the C preprocessor to export all __NR_* macros as SYS_* macros, too.

As a result, current glibc has this elaborate dance at built where it 
runs “gcc -E -dM” (with varying additional parameters to get the 
lib/libx32/lib64 variants).  I want to get rid of that because it means 
that if you upgrade the kernel headers after building glibc, the SYS_* 
and __NR_* macros drift apart.

>> Not sure if we are talking about the same thing.  Our kernel-headers
>> package comes from the kernel sources, 3.10 era.
>
> Consider splitting it out, they are really independent.  Then you can
> update the kernel headers without touching the kernel.

But I'd still have the issue that the kernel headers contain only the 
__NR_* macros, not the SYS_* macros.

If you think that SYS_* macros should remain glibc business, then I 
think the patch I posted is the right approach to simplify independent 
kernel header updates (whether they come from a separate package, or 
directly from the upstream sources).

Thanks,
Florian
  

On Apr 06 2017, Florian Weimer <fweimer@redhat.com> wrote:

> As a result, current glibc has this elaborate dance at built where it runs
> “gcc -E -dM” (with varying additional parameters to get the
> lib/libx32/lib64 variants).  I want to get rid of that because it means
> that if you upgrade the kernel headers after building glibc, the SYS_* and
> __NR_* macros drift apart.

You have to rebuild glibc anyway if new syscalls come along, so there
isn't much difference.

Andreas.
  

On 04/06/2017 02:29 PM, Andreas Schwab wrote:
> On Apr 06 2017, Florian Weimer <fweimer@redhat.com> wrote:
>
>> As a result, current glibc has this elaborate dance at built where it runs
>> “gcc -E -dM” (with varying additional parameters to get the
>> lib/libx32/lib64 variants).  I want to get rid of that because it means
>> that if you upgrade the kernel headers after building glibc, the SYS_* and
>> __NR_* macros drift apart.
>
> You have to rebuild glibc anyway if new syscalls come along, so there
> isn't much difference.

Yes, but if glibc carries an explicit list, we can schedule the glibc 
rebuild before the kernel build.  If we do that with a recent enough 
upstream kernel, we do not even need to know at that point which system 
calls will actually backported.  The required SYS_* macros will simply 
appear if the kernel headers add the __NR_* macro.

Thanks,
Florian
  

On Apr 06 2017, Florian Weimer <fweimer@redhat.com> wrote:

> Yes, but if glibc carries an explicit list, we can schedule the glibc
> rebuild before the kernel build.

You can do the same with an updated kernel headers package.

Andreas.
  

On 04/06/2017 02:49 PM, Andreas Schwab wrote:
> On Apr 06 2017, Florian Weimer <fweimer@redhat.com> wrote:
>
>> Yes, but if glibc carries an explicit list, we can schedule the glibc
>> rebuild before the kernel build.
>
> You can do the same with an updated kernel headers package.

But the uapi kernel headers aren't separate upstream, and until they 
are, the proposed new approach to SYS_* generation may be superior.

Unless everyone else but us generates their own separate kernel-headers 
package, that is. :-/

Thanks,
Florian
  

On Apr 06 2017, Florian Weimer <fweimer@redhat.com> wrote:

> But the uapi kernel headers aren't separate upstream, and until they are,
> the proposed new approach to SYS_* generation may be superior.
>
> Unless everyone else but us generates their own separate kernel-headers
> package, that is. :-/

Here is a script that does that.  It basically just runs make
headers_install_all, and the result is put in a tarball.

https://build.opensuse.org/package/view_file/Base:System/linux-glibc-devel/install_all.sh?expand=1

Andreas.
  

On 04/06/2017 03:44 PM, Andreas Schwab wrote:
> On Apr 06 2017, Florian Weimer <fweimer@redhat.com> wrote:
>
>> But the uapi kernel headers aren't separate upstream, and until they are,
>> the proposed new approach to SYS_* generation may be superior.
>>
>> Unless everyone else but us generates their own separate kernel-headers
>> package, that is. :-/
>
> Here is a script that does that.  It basically just runs make
> headers_install_all, and the result is put in a tarball.
>
> https://build.opensuse.org/package/view_file/Base:System/linux-glibc-devel/install_all.sh?expand=1

Thanks, I will take that under consideration.

Further comments from anyone else?

Florian
  

On Thu, Apr 06, 2017 at 04:22:40PM +0200, Florian Weimer wrote:
> On 04/06/2017 03:44 PM, Andreas Schwab wrote:
> > On Apr 06 2017, Florian Weimer <fweimer@redhat.com> wrote:
> >
> >> But the uapi kernel headers aren't separate upstream, and until they are,
> >> the proposed new approach to SYS_* generation may be superior.
> >>
> >> Unless everyone else but us generates their own separate kernel-headers
> >> package, that is. :-/
> >
> > Here is a script that does that.  It basically just runs make
> > headers_install_all, and the result is put in a tarball.
> >
> > https://build.opensuse.org/package/view_file/Base:System/linux-glibc-devel/install_all.sh?expand=1
> 
> Thanks, I will take that under consideration.
> 
> Further comments from anyone else?

We also build kernel headers separately from the kernel, see
http://git.altlinux.org/gears/g/..git?p=glibc-kernheaders.git;a=blob;f=glibc-kernheaders.spec
  

On 04/06/2017 04:37 PM, Dmitry V. Levin wrote:
> On Thu, Apr 06, 2017 at 04:22:40PM +0200, Florian Weimer wrote:
>> On 04/06/2017 03:44 PM, Andreas Schwab wrote:
>>> On Apr 06 2017, Florian Weimer <fweimer@redhat.com> wrote:
>>>
>>>> But the uapi kernel headers aren't separate upstream, and until they are,
>>>> the proposed new approach to SYS_* generation may be superior.
>>>>
>>>> Unless everyone else but us generates their own separate kernel-headers
>>>> package, that is. :-/
>>>
>>> Here is a script that does that.  It basically just runs make
>>> headers_install_all, and the result is put in a tarball.
>>>
>>> https://build.opensuse.org/package/view_file/Base:System/linux-glibc-devel/install_all.sh?expand=1
>>
>> Thanks, I will take that under consideration.
>>
>> Further comments from anyone else?
> 
> We also build kernel headers separately from the kernel, see
> http://git.altlinux.org/gears/g/..git?p=glibc-kernheaders.git;a=blob;f=glibc-kernheaders.spec

Do you (and other distributions) build applications against these 
headers as well, or are those only used for building glibc itself?

Thanks,
Florian
  

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.

Andreas.
  

On 04/21/2017 02:26 PM, 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.

Do you rebase the UAPI headers to the latest kernel release even after a 
release of the distribution, as part of regular maintenance?

If not, how do you get SYS_ macros for the system calls you backport 
into your stable kernel?

Thanks,
Florian
  

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.
  

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.

Andreas.
  

* 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.
  

On Apr 21 2017, Florian Weimer <fw@deneb.enyo.de> wrote:

> My proposal aims to avoid a build order depedency between the
> backports landing in the distribution kernel, and a glibc rebuild.

What do you gain over a UAPI headers update in line with the glibc
rebuild?

Andreas.
  

* Andreas Schwab:

> On Apr 21 2017, Florian Weimer <fw@deneb.enyo.de> wrote:
>
>> My proposal aims to avoid a build order depedency between the
>> backports landing in the distribution kernel, and a glibc rebuild.
>
> What do you gain over a UAPI headers update in line with the glibc
> rebuild?

We don't have to maintain a kernel package ourselves, or align our
delivery schedule with the kernel team.
  

On Apr 21 2017, Florian Weimer <fw@deneb.enyo.de> wrote:

> * Andreas Schwab:
>
>> On Apr 21 2017, Florian Weimer <fw@deneb.enyo.de> wrote:
>>
>>> My proposal aims to avoid a build order depedency between the
>>> backports landing in the distribution kernel, and a glibc rebuild.
>>
>> What do you gain over a UAPI headers update in line with the glibc
>> rebuild?
>
> We don't have to maintain a kernel package ourselves, or align our
> delivery schedule with the kernel team.

The kernel UAPI package is independent of the kernel.

Andreas.
  

* Andreas Schwab:

> On Apr 21 2017, Florian Weimer <fw@deneb.enyo.de> wrote:
>
>> * Andreas Schwab:
>>
>>> On Apr 21 2017, Florian Weimer <fw@deneb.enyo.de> wrote:
>>>
>>>> My proposal aims to avoid a build order depedency between the
>>>> backports landing in the distribution kernel, and a glibc rebuild.
>>>
>>> What do you gain over a UAPI headers update in line with the glibc
>>> rebuild?
>>
>> We don't have to maintain a kernel package ourselves, or align our
>> delivery schedule with the kernel team.
>
> The kernel UAPI package is independent of the kernel.

Well, yes, but that's another kernel package to maintain.

And we don't want to push an UAPI headers update in a point release,
so we wouldn't want to replace the other UAPI header package anyway.
The latter would still be used to build applications.
  

On Apr 21 2017, Florian Weimer <fw@deneb.enyo.de> wrote:

> And we don't want to push an UAPI headers update in a point release,
> so we wouldn't want to replace the other UAPI header package anyway.

Don't do that then.

Andreas.
  

* Andreas Schwab:

> On Apr 21 2017, Florian Weimer <fw@deneb.enyo.de> wrote:
>
>> And we don't want to push an UAPI headers update in a point release,
>> so we wouldn't want to replace the other UAPI header package anyway.
>
> Don't do that then.

What do you propose, then?  Build a custom UAPI header package with
the most recent upstream system call list, but otherwise with the
contents for the kernel version for the distribution release branch?

The downside is that you get SYS_ macros for system calls which are
not implemented in the distribution kernel.  (Quite a few, arguably
broken, applications use #ifdefs instead of run-time checking.)
  

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?

Andreas.
  

* 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.
  

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.

> 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?

Andreas.
  

* 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.
  

On Apr 22 2017, Florian Weimer <fw@deneb.enyo.de> wrote:

> 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.

Why?  That's defined by the UAPI headers.

Andreas.
  

* Andreas Schwab:

> On Apr 22 2017, Florian Weimer <fw@deneb.enyo.de> wrote:
>
>> 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.
>
> Why?  That's defined by the UAPI headers.

I meant: If we do not rebase the UAPI headers (but backport changes as
needed), while still building glibc against the current upstream
headers (to get a complete SYS_ macro list before the backporting
happens).
  

On Apr 22 2017, Florian Weimer <fw@deneb.enyo.de> wrote:

> I meant: If we do not rebase the UAPI headers (but backport changes as
> needed), while still building glibc against the current upstream
> headers (to get a complete SYS_ macro list before the backporting
> happens).

Why would you want to build a package against something that isn't part
of the distribution?

Andreas.
  

* Andreas Schwab:

> On Apr 22 2017, Florian Weimer <fw@deneb.enyo.de> wrote:
>
>> I meant: If we do not rebase the UAPI headers (but backport changes as
>> needed), while still building glibc against the current upstream
>> headers (to get a complete SYS_ macro list before the backporting
>> happens).
>
> Why would you want to build a package against something that isn't part
> of the distribution?

I don't follow.  It would be an internal build dependency, like LLVM
for Mesa (in some distributions).  It would be shipped like any other
build dependency.

I have these two constraints:

a) I need to build glibc before the kernel backporting finishes.
b) I can't rebase UAPI headers to the latest upstream.

I'm under the impression you are suggesting to build glibc against a
special set of UAPI headers which aren't used by the application.
That will lead to the too aggressive SYS_ macro generation.
  

On Apr 22 2017, Florian Weimer <fw@deneb.enyo.de> wrote:

> I have these two constraints:
>
> a) I need to build glibc before the kernel backporting finishes.
> b) I can't rebase UAPI headers to the latest upstream.

Just add the patches you need and you are done.

Andreas.
  

On Fri, Apr 21, 2017 at 11:16:26AM -0400, Carlos O'Donell wrote:
> 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.

Unfortunately, there seems to be no good working synchronization mechanism
proposed yet.  The procedure described in
https://sourceware.org/glibc/wiki/Synchronizing_Headers has severe
problems on the kernel side.  Even with headers that were synchronized
several years ago we have unsolved inclusion issues like this:

$ gcc -xc -c -o/dev/null - <<EOF
#include <linux/in.h>
#include <netinet/in.h>
#include <linux/in6.h> 
EOF

or this:

$ gcc -xc -c -o/dev/null - <<EOF
#include <linux/xattr.h>
#include <netinet/in.h>
#include <linux/in6.h> 
EOF

See also https://sourceware.org/ml/libc-alpha/2017-04/msg00157.html

It's hard to expect that kernel folks would be adding new guards
if already added guards are so fragile.
  

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?
  

I do not object to bounding the SYS_* API exported by glibc to a set of 
system calls known to that glibc version.

I do object to having a test we know will fail when someone builds glibc 
with a newer set of kernel headers than that version of glibc.  That is, I 
think the test should allow extra __NR_* if the kernel headers have a 
newer (major.minor) version number than the kernel version listed in 
syscall-names.list.  That way, the test is still effective in development 
as long as people update the kernel number when adding syscalls to the 
file or doing other new-kernel-version updates, without causing spurious 
failures for people building past release versions / branches of glibc.

I'd expect LC_ALL=C to have to be set when running the various awk scripts 
(at least those depending in any way on the ordering of the syscall list).
  

On 08/24/2017 11:15 AM, Joseph Myers wrote:
> I do not object to bounding the SYS_* API exported by glibc to a set of 
> system calls known to that glibc version.

Thanks for your input.

> I do object to having a test we know will fail when someone builds glibc 
> with a newer set of kernel headers than that version of glibc.  That is, I 
> think the test should allow extra __NR_* if the kernel headers have a 
> newer (major.minor) version number than the kernel version listed in 
> syscall-names.list.  That way, the test is still effective in development 
> as long as people update the kernel number when adding syscalls to the 
> file or doing other new-kernel-version updates, without causing spurious 
> failures for people building past release versions / branches of glibc.

This is a valuable comment. I agree, that sounds like a good position.

> I'd expect LC_ALL=C to have to be set when running the various awk scripts 
> (at least those depending in any way on the ordering of the syscall list).

OK.

I am interested in hearing Andreas' position, and if my clarification
made our distro position clearer, and if he objects to the change.
  

* Joseph Myers:

> I do not object to bounding the SYS_* API exported by glibc to a set of 
> system calls known to that glibc version.
>
> I do object to having a test we know will fail when someone builds glibc 
> with a newer set of kernel headers than that version of glibc.  That is, I 
> think the test should allow extra __NR_* if the kernel headers have a 
> newer (major.minor) version number than the kernel version listed in 
> syscall-names.list.  That way, the test is still effective in development 
> as long as people update the kernel number when adding syscalls to the 
> file or doing other new-kernel-version updates, without causing spurious 
> failures for people building past release versions / branches of glibc.

Hmm.  The way the patch currently works, a missing built-in system
call name is actually a user-visible bug because they won't get the
SYS_* macro they expect (based on the kernel headers).  This is why I
made it a test failure.

If we don't want that, I need to resurrect the old magic list
generation and use its results to augment the built-in list.  The test
can remain as-is, but it will no longer fail.

A compromise would be to assume that for mixed-mode architectures
(e.g., i386/x86-64/x32), the set of missing system calls is the same
across all architectures, then we could still leave out the
complicated list generation logic.

> I'd expect LC_ALL=C to have to be set when running the various awk scripts 
> (at least those depending in any way on the ordering of the syscall list).

Right, that needs to be fixed.
  

On Thu, 24 Aug 2017, Florian Weimer wrote:

> * Joseph Myers:
> 
> > I do not object to bounding the SYS_* API exported by glibc to a set of 
> > system calls known to that glibc version.
> >
> > I do object to having a test we know will fail when someone builds glibc 
> > with a newer set of kernel headers than that version of glibc.  That is, I 
> > think the test should allow extra __NR_* if the kernel headers have a 
> > newer (major.minor) version number than the kernel version listed in 
> > syscall-names.list.  That way, the test is still effective in development 
> > as long as people update the kernel number when adding syscalls to the 
> > file or doing other new-kernel-version updates, without causing spurious 
> > failures for people building past release versions / branches of glibc.
> 
> Hmm.  The way the patch currently works, a missing built-in system
> call name is actually a user-visible bug because they won't get the
> SYS_* macro they expect (based on the kernel headers).  This is why I
> made it a test failure.

I don't see it as a user-visible bug - I see it as a deliberate change of 
the SYS_* API from "what's in the kernel headers with which glibc was 
built" to "what syscalls the glibc source tree knows about that are also 
in the kernel headers with which glibc is used".

> If we don't want that, I need to resurrect the old magic list
> generation and use its results to augment the built-in list.  The test
> can remain as-is, but it will no longer fail.

I think a key benefit of the patch is that it gets rid of that magic list 
generation.