This is the mail archive of the
mailing list for the glibc project.
Re: Second draft of the Y2038 design document
- From: Arnd Bergmann <arnd at arndb dot de>
- To: libc-alpha at sourceware dot org
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- Date: Fri, 29 Jan 2016 00:21:08 +0100
- Subject: Re: Second draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20160128204114 dot 6c7dbbf7 dot albert dot aribaud at 3adev dot fr> <56AA8465 dot 5040803 at cs dot ucla dot edu>
On Thursday 28 January 2016 13:13:09 Paul Eggert wrote:
> Some typos: "1901-12-13 19:55:13 UTC" should be "1901-12-13 20:45:52
> UTC". "sentive" should be "sensitive". "20338" should be "2038". "Thins"
> should be "This".
> I don't see why functions like 'time' and 'gettimeofday' should be
> allowed to misbehave on 64-bit hosts after 2038. They should just work.
> Glibc should not worry about 64-bit kernels without 64-bit time support.
> Any such kernels should just get fixed before 2038 rolls around.
> Why are struct rusage, getrusage, etc. Y2038-sensitive? They hold
> intervals, not absolute times.
It can theoretically still overflow, though not at the same time:
If you have a large NUMA system with thousands of CPUs and an HPC
workload running on all of them for a couple of months at a time,
the field will overflow.
getrusage is also an example of a class of interfaces that need to
be addressed in one way or another because they contain a time_t
member in a structure, so any user space program that sees the
current definition of struct rusage but uses a 64-bit time_t will
disagree on the layout with the old kernel system call. Other
interfaces in this class are clock_getres, pselect, ppoll,
io_getevents, recvmmsg, semtimedop, rt_sigtimedwait,
sched_rr_get_interval, and sysinfo, along with many ioctl commands.
There is no overflow in them, but we have to either add a
replacement interface, or redefine the API to pass a 'long' instead
of 'time_t' to keep binary compatibility.
My current patch set for the kernel syscalls uses a structure
with all 64-bit members, so we can share the implementation between
the new 32-bit system call in compat mode with the existing native
64-bit system call. I'm not particularly attached to that solution,
it's just one of multiple ways to do this and I had to pick one.