This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: 32-bit time_t inside itimerval
- From: Arnd Bergmann <arnd at arndb dot de>
- To: Lukasz Majewski <lukma at denx dot de>
- Cc: Alistair Francis <alistair23 at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>, Alistair Francis <alistair dot francis at wdc dot com>
- Date: Thu, 2 Jan 2020 13:28:20 +0100
- Subject: Re: 32-bit time_t inside itimerval
- References: <CAKmqyKPki9K3JwYT4zn7JaAZHFW8UO7ztS2D=US3ccnTd-KAwA@mail.gmail.com> <CAK8P3a0KR3-_DCYob0VH3BWjDNxEbz9Qt-ygtSuVFDC6PRL8Fw@mail.gmail.com> <CAKmqyKMHF2okhU6W7OgQiNX+AeXUjm9YagVK2dczUe=nrgC=Eg@mail.gmail.com> <CAK8P3a13k=4fpUvtq2wG12KNZm9mSYn1pWma9UBVuYO0+BGq+g@mail.gmail.com> <CAKmqyKODSj2dNGTTKnkM-QSwL2CWMYpRTPJhVmiotcFjt4q7Qg@mail.gmail.com> <CAK8P3a3t9c0248OFnSHD-dwH7kZTv6nrCum-kszULdP4Eqbd0g@mail.gmail.com> <CAKmqyKMtZTaQVP-x0fLr3Uo_u5p0dbPo8fR4-b9Yey4hSRSudg@mail.gmail.com> <CAK8P3a0zbcTMr0fQB35E9Y9r0DUS9-W4h9z1zOv+coKiH56HZg@mail.gmail.com> <20200102130836.77dfed5e@jawa>
On Thu, Jan 2, 2020 at 1:08 PM Lukasz Majewski <lukma@denx.de> wrote:
> > On Mon, Dec 30, 2019 at 10:22 PM Alistair Francis
> > <alistair23@gmail.com> wrote:
> > > On Mon, Dec 30, 2019 at 12:11 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > I don't think it's
> > fundamentally different from the other system calls that he has
> > converted already to work with time64 callers.
>
> I'm not aware of any RV32 specifics, but it seems to me that it would
> be appropriate to use the 64 bit version of struct __itimerspec64 in
> glibc - as for example in the conversion patch from [1].
What I mean is that rv32 otherwise does not convert between time32
and time64 interfaces because it always uses the time64 version,
so unlike the others, there is probably no helper to convert between
the timeval formats either.
> As it was already mentioned - those calls set the time to be
> decremented and do not operate on "absolute" time values.
> Hence, I think that it would be good enough (for now?) to use 32 bit
> API wrapped into 64 bit internal glibc values and just return errors
> when somebody wants to set timer relative expiration time to overflow
> time_t on 32 bit archs (arm,rv32).
Yes, that's the idea. The kernel already limits the range to 64-bit
nanoseconds because of its timer implementation, so truncating it
to 32-bit seconds does not change the behavior either.
> Arnd, am I correct that the struct itimerval to __kernel_old_itimerval
> conversion patch can be found here [2]?
Yes, that's right. This patch only changes the in-kernel implementation
as a step to removing the timeval definition from the kernel's uapi
headers, it does not change the behavior at all.
Arnd