On Wed, Sep 11, 2019 at 09:54:23PM +0200, Florian Weimer wrote: > * Carlos O'Donell: > > > On 9/11/19 3:08 PM, Florian Weimer wrote: > >> * Carlos O'Donell: > >> > >>> It would be easier to merge the patch set if it were just an unconditional > >>> registration like we do for set_robust_list(). > >> > >> Note that this depends on the in-tree system call numbers list, which I > >> still need to finish according to Joseph's specifications. > > > > Which work is this? Do you have a URL reference to WIP? > > <https://sourceware.org/ml/libc-alpha/2019-05/msg00630.html> > <https://sourceware.org/ml/libc-alpha/2019-06/msg00015.html> > > I think realistically this is needed for the Y2038 work as well if we > want to support building glibc with older kernel headers. “glibc 2..31 > will have Y2038 support and rseq support, but only if it runs on a > current and it happens to have been built against sufficiently recent > kernel headers” is a bit difficult to explain. The current kernel part > is easy enough to understand, but the impact of the kernel headers on > the feature set has always been tough to explain. Especially if you > factor in vendor kernels with system call backports. I'm in favor of in-tree syscall numbers list. If you don't want O(n) per-arch work, though, you could just define the 'base number' for each arch and use the fact that all the new syscalls share a common numbering (i.e. base + constant depending only on syscall). I think including the list with glibc is more robust though, and would eliminate the need to check for definitions of older (pre-unification) syscalls glibc wants to use. Rich
