Re: 32-bit time_t inside itimerval

[Alistair Francis <alistair23 at gmail dot com>]

On Mon, Dec 30, 2019 at 12:11 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Dec 30, 2019 at 8:57 PM Alistair Francis <alistair23@gmail.com> wrote:
> > On Mon, Dec 30, 2019 at 2:02 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Sat, Dec 21, 2019 at 6:19 PM Alistair Francis <alistair23@gmail.com> wrote:
> > > > For the glibc people, can we do something like this?
> > > >
> > > >  1. Add a __old_timeval struct used by the itimerval and rusage structs
> > > >  2. Make __old_timeval use __old_time_t that is always a long (no
> > > > matter what time_t really is)
> > >
> > > If you have linux-5.1 kernel headers, there is already __kernel_old_timeval
> > > that is defined specifically for this purpose. Not sure if you can use those
> > > given the state of the kernel headers overall.
> > >
> > > > Then the question becomes do we expose __old_timeval (with 32-bit
> > > > time_t) or the real timeval (64-bit time_t) to callers of the
> > > > functions?
> > >
> > > I would think this has to be the actual timeval, there is no point in
> > > changing the API now.
> >
> > Yeah, agreed. I have updated the RV32 port to internally convert
> > between 32/64-bit.
>
> Any chance of making this the default implementation for 32-bit
> rather than RV32 specific? The code should be the same for any
> time64 user space regardless of the architecture.

I was thinking about this.

I don't know of a good way to make it apply only to 32-bit archs with
a 64-bit time_t.This could actually just apply to all 32-bit archs.
That way ones that are 64-bit time_t are covered and ones that aren't
will just do an extra conversion with no effect.

Making it 32-bit in general seems reasonable to me, I just have to
figure out a way to test it though.

Alistair

>
>        Arnd