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: extending wait4(2) or waitid(2) linux syscall


On Thu, Nov 15, 2018 at 06:39:03AM -0800, Arnd Bergmann wrote:
> On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin wrote:
> > On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
[...]
> > > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=146
> > Is there any rationale for marking wait4 as an obsolete API?
> 
> In the *kernel* syscall API, wait4(2) is obsoleted by waitid(2), which is
> a strict superset of its functionality.
> 
> In the libc API, this is different, as wait4() does not have a replacement
> that is exposed to user space directly. I expect glibc to implement
> wait4() on top of the kernel's waitid().
> 
> There has not been a final decision on which variant of waitid() that would
> be. The easiest option would be to not change it at all: new architectures
> (rv32, csky, nanomips/p32, ...) would keep exposing the traditional
> waitid() in Linux, with its 32-bit time_t based rusage structure, but drop the
> wait4(). glibc then has to convert between the kernel's rusage and the
> user space rusage indefinitely.
> 
> Alternatively, we can create a new version like waitid2() that uses
> 64-bit time_t in some form, either the exact same rusage that we
> use on 64-bit architectures and x32, or using a new set of arguments
> to include further improvements.

In strace, we have two use cases that require an extended version
of wait4(2) or waitid(2) syscall.  From your response I understand that
you'd recommend extending waitid(2) rather than wait4(2), is it correct?

These two use cases were mentioned in my talk yesterday at LPC 2018,
here is a brief summary.

1. strace needs a race-free invocation of wait4(2) or waitid(2)
with a different signal mask, this cannot be achieved without
an extended version of syscall, similar to pselect6(2) extension
over select(2) and ppoll(2) extension over poll(2).

Signal mask specification in linux requires two parameters:
"const sigset_t *sigmask" and "size_t sigsetsize".
Creating pwait6(2) as an extension of wait4(2) with two arguments
is straightforward.
Creating pwaitid(2) as an extension of waitid(2) that already has 5
arguments would require an indirection similar to pselect6(2).

2. The time precision provided by struct rusage returned by wait4(2) and
waitid(2) is too low for syscall time counting (strace -c) nowadays, this
can be observing by running in a row a simple command like "strace -c pwd".

The fix is to return a more appropriate structure than struct rusage
by the new pwait6(2)/pwaitid(2) syscall mentioned above, where
struct timeval is replaced with struct timespec or even struct timespec64.


-- 
ldv

Attachment: signature.asc
Description: PGP signature


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