This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v7 0/3] y2038: Linux: Introduce __clock_settime64 function
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Alistair Francis <alistair23 at gmail dot com>
- Cc: Lukasz Majewski <lukma at denx dot de>, Zack Weinberg <zackw at panix dot com>, Arnd Bergmann <arnd at arndb dot de>, Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Florian Weimer <fweimer at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, Stepan Golosunov <stepan at golosunov dot pp dot ru>
- Date: Tue, 17 Sep 2019 00:44:29 +0000
- Subject: Re: [PATCH v7 0/3] y2038: Linux: Introduce __clock_settime64 function
- Ironport-sdr: MfhqgpSFXAd5nu42f3WEHfddbfwWoBH6tMr02hSZgD8JtRPPHuxMJetVVo6uT4gMbmqBfeWRfj ZNtSQpkeOAqPejd+XlO4EGYDaxdREvE2y/0xXdim3XpkODwW960NfOWJutBN7CyUlDOBbByLfq mQ8+796P4v+SnaJBrfxp6BES5dHCW/kLPkY3M6ZHOCe4qkAFf3YBwNeMmF4V/Z/tbaEUBOaB4T c9GiOxCT5i4yG9gR1ablOCZzeVrj708tWf7qb9GCxDRhfEO2NbH5/QShTMV6ziBl0GhScwZCge Zuc=
- Ironport-sdr: quPU9OFwN45seagFrGutd+mfIAoJ/W4lbon2WhiJLpRwr08pZyZJI6jCQibdHW9B/s5k2ZUhcp ULQTNnRXfsPTIfw7DMMjy78Cw/2bhOL2cRia5eK8BoZ7Z+CHX7HYUN8MapxEXvGbM3hPUy5FAL rlCVjUigiwxwZXJA2X816ryQ7wsasV/rpAPCtKqtlEV1o4DfzktgGHrhssUlEbKX7CbKQ3CJRH hK2/xF/DDMjxJp20/zgRxwetZuKOswwu8JywGUWy9tx1JI4Q2qJKkhF4+U1SqaEe22iyrite2n 3iI=
- References: <20190906145911.30207-1-lukma@denx.de> <CAKmqyKMdsVZg_ZS7fLTt23dy2vnZc1z85b_+8heiK-8UiqMx+g@mail.gmail.com> <alpine.DEB.2.21.1909062122220.30243@digraph.polyomino.org.uk> <CAKmqyKP=kmeJjcsDepetvsVrph3xJ7G8yQdNFNyX-wL2ZMtqmA@mail.gmail.com>
On Mon, 16 Sep 2019, Alistair Francis wrote:
> Would the correct fix be to add __TIMESIZE == 64 to the #if mentioned above?
Those other conditions imply __TIMESIZE == 64. So replacing the existing
conditions by __TIMESIZE == 64 might be correct, but not adding it while
leaving the existing (then redundant) conditions there as well.
I think you should replace the conditional by __TIMESIZE == 64 (if that
works), which I think should be safe for the reasons explained below.
There is a possibility that we end up needing two different internal names
instead of the present one, but I don't think that should block changing
the conditional at this point to make further progress unless that causes
problems with the existing patches on existing configurations.
The design for defining 64-bit-time functions with *64 names and then
remapping those names to the public ones via #define if __TIMESIZE == 64
implies that the type used in declaring / defining *64 functions needs to
be mapped to struct timespec if __TIMESIZE == 64.
But if you need to set padding explicitly to zero when passing 64-bit
timespecs into the kernel (the case of kernels 5.1.0 through 5.1.4, on
32-bit architectures for which those kernel versions had a corresponding
64-bit architecture with compat syscall support), you then need a type
with named padding (whereas the public struct timespec needs to have an
unnamed bit-field for the padding to stay compatible with existing sources
with { tv_sec, tv_nsec } initializers).
So this links into what things should look like at the API level inside
glibc for dealing with zeroing padding, if we do that at all. However,
unless we fix x32 to use "long int" for tv_nsec we don't need to deal with
zeroing padding for any existing system with __TIMESIZE == 64 (and I don't
think it's likely to be relevant for future 32-bit ports that use
__TIMESIZE == 64 either, because the kernel issue is only for compat
syscalls for 32-bit binaries under 64-bit kernels, which I don't think are
relevant to any 32-bit architectures supported in 5.1 kernels but not yet
in glibc).
--
Joseph S. Myers
joseph@codesourcery.com