All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dmitry V. Levin" <ldv@altlinux.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Albert ARIBAUD <albert.aribaud@3adev.fr>,
	"H. Peter Anvin" <hpa@zytor.com>,
	GNU C Library <libc-alpha@sourceware.org>,
	linux-api@vger.kernel.org
Subject: Re: extending wait4(2) or waitid(2) linux syscall
Date: Thu, 15 Nov 2018 18:30:11 +0300	[thread overview]
Message-ID: <20181115153008.GC2171@altlinux.org> (raw)
In-Reply-To: <CAK8P3a0Gsqa8WTbALOUchRyEA7E2f3P1f=XQ8nD2xQaemfPpcQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2682 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

       reply	other threads:[~2018-11-15 15:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170420152051.568f2050.albert.aribaud@3adev.fr>
     [not found] ` <20181115140441.GA2171@altlinux.org>
     [not found]   ` <CAK8P3a0Gsqa8WTbALOUchRyEA7E2f3P1f=XQ8nD2xQaemfPpcQ@mail.gmail.com>
2018-11-15 15:30     ` Dmitry V. Levin [this message]
2018-11-15 15:37       ` extending wait4(2) or waitid(2) linux syscall hpa
2018-11-16  7:14         ` Arnd Bergmann
2018-11-16 10:26           ` Florian Weimer
2018-11-16 15:17             ` Arnd Bergmann
2018-11-16 16:03               ` Paul Eggert
2018-11-16 18:46           ` hpa
2018-11-16 18:48           ` hpa
2018-11-16  7:12       ` Arnd Bergmann
2018-11-16 12:42       ` Dave Martin
2018-11-16 13:40         ` Florian Weimer
2018-11-16 14:26           ` Dave Martin
2018-11-17  1:50       ` Arnd Bergmann
2018-11-26 15:18         ` Florian Weimer
2018-11-26 17:15           ` Arnd Bergmann
2018-11-26 17:27             ` Daniel Colascione
2018-11-28  9:31             ` Florian Weimer
2018-11-28  9:36               ` Christian Brauner
2018-11-28  9:41                 ` Florian Weimer
2018-11-28 18:50                   ` Daniel Colascione

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181115153008.GC2171@altlinux.org \
    --to=ldv@altlinux.org \
    --cc=albert.aribaud@3adev.fr \
    --cc=arnd@arndb.de \
    --cc=hpa@zytor.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-api@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.