Sixth draft of the Y2038 design document

[hpa@zytor.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.