This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]