This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Sixth draft of the Y2038 design document
- From: hpa at zytor dot com
- To: Arnd Bergmann <arnd at arndb dot de>, "Dmitry V. Levin" <ldv at altlinux dot org>
- Cc: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 15 Nov 2018 10:24:43 -0800
- Subject: Re: Sixth draft of the Y2038 design document
- References: <20170420152051.568f2050.albert.aribaud@3adev.fr> <20181115140441.GA2171@altlinux.org> <CAK8P3a0Gsqa8WTbALOUchRyEA7E2f3P1f=XQ8nD2xQaemfPpcQ@mail.gmail.com>
On November 15, 2018 6:39:03 AM PST, Arnd Bergmann <arnd@arndb.de> wrote:
>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
I vote for waitid64().
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.