Re: [RFC v6 03/23] time: Add a timeval with a long tv_sec and tv_usec

[Arnd Bergmann <arnd at arndb dot de>]

On Wed, Jan 15, 2020 at 6:15 AM Alistair Francis <alistair23@gmail.com> wrote:
>
> On Tue, Jan 14, 2020 at 8:17 PM Lukasz Majewski <lukma@denx.de> wrote:
> >
> > Hi Alistair,
> >
> > > On y2038 safe 32-bit systems the Linux kernel expects itimerval to
> > > use a 32-bit time_t, even though the other time_t's are 64-bit. To
> > > address this let's add a timeval_long
> >                            ^^^^^^^^^^^^^ - I'm not so seasoned glibc
> >                            developer, but I think that the _long suffix
> >                            is a bit misleading.
> >
> >         Maybe it would be more readable to name it as struct
> >         __timeval32 ? In that way one can see from the outset that we
> >         operate on 32 bit values.
>
> It isn't explicitly 32-bit, it's just always a long which is why I
> went with long in the name instead.
>
> I'm happy to change the name, it doesn't really matter too much as
> it's only user internally.
>
> I'll wait to see what others think before changing it.

I think you can look at it either way: the Your timeval_long works fine
on both 32-bit and 64-bit architectures, but you really only need it
on 32-bit ones because on 64-bit architectures (except sparc64, which
has 32-bit suseconds_t !) this is the same as the default timeval
anyway.

In the kernel we actually ended up having both: there is a
"struct __kernel_old_timeval" that is part of the uapi headers
for defining structures based on the old type with no replacement
such as rusage and itimerval, and internally there is a "struct
old_timeval32" with two "int32_t" members that is used for
providing compatibility handlers for old interfaces that have a
64-bit replacement, so the same compatibility handler can be
used on native 32-bit kernels and on 64-bit kernels running
32-bit user space.

     Arnd