Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Arnd Bergmann <arnd at arndb dot de>]

On Tue, Jun 25, 2019 at 2:10 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Arnd Bergmann:
>
> > The kernel system call waitid() is a superset of glibc's wait4() and
> > waitid(), it has an extra rusage argument.
> >
> > Originally, my plan was to replace kernel's waitid() with
> > a waitid_time64() that takes an updated rusage structure,
> > but that never happened.
> >
> > I still left wait4() commented out since it should not be
> > needed when the kernel has waitid(). I have an implementation
> > of wait4() based on waitid() that I did for musl and tested
> > successfully with ltp, see [1].
> > Unless I did something very wrong there, you should be able
> > to use something like this in glibc.
> >
> > Similar coversions of timeval have to be done in getrusage(),
> > getitimer() and setitimer(), all of which expect a 32-bit
> > timeval couting elapsed time (so no overflow in y2038).
> > These need to be converted to the 64-bit timeval in the
> > public glibc interface.
>
> Does this means that RV32 will use a 32-bit struct timeval in those
> system calls?  Even if everything else 64-bit?

Correct. Only those four (all deprecated but still used) system calls,
as we could not agree on a new interface before 5.1, and there
is no urgency for deployment when they can be emulated.

I agree this is ugly, sorry for having dropped the mess into your
area instead of fixing it in the kernel.

        Arnd