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: Alistair Francis <alistair23 at gmail dot com>
- To: Arnd Bergmann <arnd at arndb dot de>
- Cc: Lukasz Majewski <lukma at denx dot de>, GNU C Library <libc-alpha at sourceware dot org>, Alistair Francis <alistair dot francis at wdc dot com>
- Date: Sat, 4 Jan 2020 10:03:01 -0800
- 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> <CAK8P3a1bwfpnXztxBELem7yqEj74kKeqoZaOoYdCv-=K9EWPgw@mail.gmail.com>
On Thu, Jan 2, 2020 at 4:28 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> 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.
I have some patches prepared that will convert a 64-bit time_t to
32-bit for the required syscalls. It's generic for 32-bit archs, but
will only apply when __TIMESIZE == 64.
I'll send an RFC out with the RV32 patches soon and then send patches
when the 2.32 merge window opens up.
Alistair
>
> > 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