Re: Sixth draft of the Y2038 design document

[Arnd Bergmann <arnd at arndb dot de>]

On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin <ldv@altlinux.org> wrote:
>
> Hi,
>
> On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
> > Hi all,
> >
> > I have produced a sixth draft of what will eventually become the Y2038
> > design document:
> >
> > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=146
> >
> > Relative to the previous draft:
> >
> >  * Precisions re padding in struct timespec was added.
> >
> >  * Better separation of APIs and implementations; notably, developed
> >    the distinction between API types and implementation types.
> >
> >  * Cleaned up API tables (e.g., removed argument names and left types
> >    only).
> >
> >  * Also developed on implementation vs kernel types (e.g., struct
> >    timespec conversion between GLIB padded versions and kernel non-
> >    padded versions.
> >
> > As always, comments welcome.
>
> 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.

        Arnd