This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 3/6] y2038: Introduce struct __timeval64 - new internal glibc type
- From: Arnd Bergmann <arnd at arndb dot de>
- To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: Lukasz Majewski <lukma at denx dot de>, Alistair Francis <alistair23 at gmail dot com>, Joseph Myers <joseph at codesourcery dot com>, Paul Eggert <eggert at cs dot ucla dot edu>, Samuel Thibault <samuel dot thibault at ens-lyon dot org>, 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 <fweimer at redhat dot com>, Florian Weimer <fw at deneb dot enyo dot de>, Zack Weinberg <zackw at panix dot com>, "Carlos O'Donell" <carlos at redhat dot com>, Andreas Schwab <schwab at suse dot de>
- Date: Mon, 20 Jan 2020 20:09:29 +0100
- Subject: Re: [PATCH 3/6] y2038: Introduce struct __timeval64 - new internal glibc type
- References: <20200118072047.23071-1-lukma@denx.de> <20200118072047.23071-4-lukma@denx.de> <CAKmqyKPD=_3LZ+YBEn53ZuoPo0hq_vdAFTMHdmPwo5Q795Wekw@mail.gmail.com> <CAK8P3a0F0nrUjrWSzrfC3ZwJdC9keQhrORWJN2Uy78OEr-WFcA@mail.gmail.com> <20200119162212.111f29b2@jawa> <CAK8P3a1pTO8xnn9yEFK=NBstPyEU9i0SDPhUdnx1SgOC_gYeJg@mail.gmail.com> <20200119223038.07beb885@jawa> <20200120133407.7536463b@jawa> <CAK8P3a30Xcda0a61x2S-cdsCB8TXa9Njpa3QP_Mw5Ko2XyVOqg@mail.gmail.com> <2e030d9b-35cb-f454-26f2-d86238153f7f@linaro.org>
On Mon, Jan 20, 2020 at 5:46 PM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> On 20/01/2020 10:00, Arnd Bergmann wrote:
> > On Mon, Jan 20, 2020 at 1:34 PM Lukasz Majewski <lukma@denx.de> wrote:
> >>>> On Sun, Jan 19, 2020 at 4:22 PM Lukasz Majewski <lukma@denx.de>
> >>>> wrote:
> >>>>>> On Sat, Jan 18, 2020 at 11:48 PM Alistair Francis <alistair23@gmail.com> wrote:
> >>>>
> >>>> It would certainly help if this could be consistent across
> >>>> architectures and libraries.
> >>>
> >>> Ok. Thanks for the input.
> >>
> >> Would it be OK to have:
> >>
> >> struct __timeval64
> >> {
> >> __time64_t tv_sec; /* Seconds */
> >> __int64_t tv_usec; /* Microseconds */
> >> };
> >
> > This would not work if you pass it into a kernel interface that expects
> > a 32-bit suseconds_t on sparc64, but it should work as an internal
> > type on all 32-bit architectures.
> >
> >> I would prefer to avoid changing typedef of suseconds_t as it may
> >> affect struct timeval related operations.
> >>
> >> Using explicitly __int64_t for tv_usec seems better option, isn't it?
> >
> > Maybe a __suseconds64_t that happens to be 32-bit wide on sparc64?
>
> If timeval64 kernel ABI expects tv_usec being a different type depending
> of the architecture, it is an indication we should parametrize with a
> __suseconds64_t.
>
> As a side note, why tv_usec for timeval64 is a 64-bit value? Is it
> related to some alignment constraint?
I think it's mostly for simplicity: we do need the microseconds to be
in the low bytes for compatibility with the 64-bit syscalls in the
kernel, so it's either a 64-bit microseconds value or the same
conditional padding that exists in timespec, with an extra special
case for sparc64.
The 64-bit case is slightly simpler for the few kernel interfaces that
take a timeval as input and then can avoid conditionally zeroing out
the upper 32 bits before checking the lower 32 bits again 1000000.
I think that is only needed for clock_adjtimex, VIDIOC_QBUF and
PPSETTIME though, everything else only passes a timeval
to user space.
Arnd