Re: Second draft of the Y2038 design document

[Arnd Bergmann <arnd at arndb dot de>]

On Thursday 28 January 2016 20:41:14 Albert ARIBAUD wrote:
> Hi all, and a happy New Year while we're still in January.
> 
> I have produced a second draft of what will eventually become the Y2038
> design document:
> 
> https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=55
> 
> Hopefully, all comments from previous round have been taken 
> Questions, notes, comments, corrections can be appended to the document
> and/or discussed here.

Thanks a lot for the update!

I hope to follow up on the kernel side with new patches soon. For now,
the most important unsolved question is how the kernel headers should
interface with libc for the added structures and interfaces.

First of all, for interfaces in which the kernel needs to behave
differently based on the time_t definition, there needs to be a
macro that the kernel headers can check for, so the user side can
pass the right constants. One example would be asm/socket.h setting

#if (_TIME_BITS != 64) || (__BITS_PER_LONG != 32)
#define SO_TIMESTAMP            29
#else
#define SO_TIMESTAMP            53
#endif

so an application can ask for either an 8-byte timeval or a 16-byte
timeval to be copied into the buffer.

Should the kernel rely on the glibc-specific "_TIME_BITS" for this,
or do we define some other macro that the kernel can test for?
There are probably a few dozen such interfaces, mostly ioctl commands
that predate the _IOR/_IOW macros.


A second point is the definition of new data structures. My current
set of headers define additional __kernel_time64_t, __kernel_timespec,
__kernel_rusage, __kernel_stat, __kernel_timex, and __kernel_itimerspec.
This convention is not used today for structure, but is consistent
with the typedefs we have for other things (__kernel_off_t,
__kernel_time_t, ...) and avoids namespace conflicts. In all the above
examples, the new structure is identical between 32-bit and 64-bit
architectures. [background: this lets us have a common syscall
implementation for 64-bit and new 32-bit interfaces, while the
existing 32-bit interfaces are now handled through the optional
"compat" layer that is again shared between 32-bit and 64-bit
kernels and handles old 32-bit user space].

Does this work ok for glibc?


	Arnd