Re: 32-bit time_t inside itimerval

[Arnd Bergmann <arnd at arndb dot de>]

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.

       Arnd