This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v4 1/2] y2038: linux: Provide __timerfd_gettime64 implementation
- From: Florian Weimer <fweimer at redhat dot com>
- To: Lukasz Majewski <lukma at denx dot de>
- Cc: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Joseph Myers <joseph at codesourcery dot com>, Paul Eggert <eggert at cs dot ucla dot edu>, Andreas Schwab <schwab at suse dot de>, Alistair Francis <alistair23 at gmail dot com>, Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh at gotplt dot org>, Florian Weimer <fw at deneb dot enyo dot de>, Zack Weinberg <zackw at panix dot com>, Carlos O'Donell <carlos at redhat dot com>
- Date: Tue, 07 Jan 2020 13:49:46 +0100
- Subject: Re: [PATCH v4 1/2] y2038: linux: Provide __timerfd_gettime64 implementation
- References: <20200106121742.1628-1-lukma@denx.de> <ea1ea005-6dee-f8dd-f205-d0a47a952904@linaro.org> <20200107102752.396f7f6f@jawa>
* Lukasz Majewski:
> Only Linux version >= 5.1 supports 64 bit time on archs with __WORDSIZE
> = 32. I do guess (but I may be wrong here) that the arch-syscall is
> supposed to reflect the exact syscalls provided by kernel headers used
> for building (to help with validation of Y2038 patches).
The tables are supposed to be complete in the sense that they include
all system calls which
(a) have a system call number assigned in some recent kernel version,
and
(b) are actually used during the glibc build in some way.
The intent is that you can build glibc against older kernel headers (say
Linux 4.18) and still get the exact same system call profile as you
would get when building against Linux 5.3 (or Linux 4.18 with random
system call backports).
As Adhemerval pointed out, (a) can be problematic in the sense that
system call numbers could be added late on some architectures. This
only matters if their existence actually affects the glibc build, as per
(b). But if it does, we would have to update the tables.
Thanks,
Florian