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

[Alistair Francis <alistair23 at gmail dot com>]

On Tue, Jun 25, 2019 at 5:01 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Jun 25, 2019 at 1:07 PM Florian Weimer <fweimer@redhat.com> wrote:
> >
> > * Zack Weinberg:
> >
> > > On Mon, Jun 24, 2019 at 8:12 PM Alistair Francis
> > > <alistair.francis@wdc.com> wrote:
> > >>
> > >> If the waitid syscall is avaliable let's use that as waitpid
> > >> and wait4 aren't always avaliable (they aren't avaliable on RV32).
> > >
> > > wait4 does something that can't be done any other way (retrieve
> > > resource usage information), RV32 should have it.
> >
> > I think the problem is that the kernel provides wait4 under a different
> > name because struct rusage has two fields of struct timeval.
> >
> > I think this needs to be covered by the syscall renaming mechanism, to
> > get a working wait4, and not changes to wait.
>
> 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.

Thanks for that, I still see hangs though when I port that to glibc.

Alistair

>
> 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.
>
>        Arnd
>
> [1] https://git.linaro.org/people/arnd/musl-y2038.git/tree/src/linux/wait4.c