This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Linux: Add tables with system call numbers
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Mon, 3 Jun 2019 15:27:23 +0000
- Subject: Re: [PATCH] Linux: Add tables with system call numbers
- References: <87o93mqlhj.fsf@oldenburg2.str.redhat.com> <alpine.DEB.2.21.1905282247180.27415@digraph.polyomino.org.uk> <877ea9re8x.fsf@oldenburg2.str.redhat.com> <alpine.DEB.2.21.1905301536560.13569@digraph.polyomino.org.uk> <87v9xqkc3u.fsf@oldenburg2.str.redhat.com>
On Fri, 31 May 2019, Florian Weimer wrote:
> > What would seem more appropriate to me would be e.g. for
> > build-many-glibcs.py to have a new "update-syscalls" option for what to
> > do, which would require a previously built set of compilers (if they're
> > part of what's needed for this process) and would build the Linux kernel
> > headers only to extract syscall numbers from them.
>
> I tried to implement an “update-syscall-lists” with the patch below. It
> needs the compilers stage completed, and it configures glibc, to be able
> to run the “make update-syscall-lists”, but it does not require a full
> build/check cycle.
I think the key thing is that it should work with the compilers stage
completed *with an older kernel headers version*. That is, it should
build the kernel headers itself (install them somewhere other than in the
compiler installation, configure glibc using --with-headers= pointing to
that location). Building kernel headers and configuring glibc are both
fast; building compilers isn't.
A full compilers rebuild is (a) slow, (b) something you might want to do
*after* such a change as part of testing the use of new kernel headers,
not before, (c) something you might not want to do at all with new kernel
headers for now, as long as the fds_bits/val namespace issue remains
unresolved and so compilers using Linux 5.0 headers are useful for testing
glibc but compilers using any newer version are not useful for testing
glibc.
--
Joseph S. Myers
joseph@codesourcery.com