Fourth draft of the Y2038 design document

[Joseph Myers]

On Thu, 23 Jun 2016, Arnd Bergmann wrote:

> > I'd be a lot more comfortable with requiring new kernel headers to build 
> > and use glibc than with requiring a new kernel at runtime for 
> > _TIME_BITS=64 to work.  New kernel headers are one of the easiest things 
> > to use when building glibc, since we have the --with-headers option.  (In 
> > fact right now the headers requirement (3.2) is newer than the runtime 
> > requirement (2.6.32) on x86_64 / x86.)
> 
> Just for my understanding: do you mean requiring new headers specifically
> for building with _TIME_BITS=64 as I said, or would you change the minimum
> kernel header version for building glibc in general when we merge 64-bit
> time_t support?

My view would be changing the minimum for building glibc in general, 
rather than trying to make installed libc headers check the kernel headers 
version and give errors conditional on _TIME_BITS.  (I think we can trust 
distribution maintainers to set appropriate dependencies so that in this 
case glibc doesn't get used with old headers if built with new headers.)

> Fair enough. And this would also mean that we don't allow 32-bit
> time_t on future architectures ports that never had an upstream Linux
> kernel without 64-bit time_t interfaces, right?

I'd expect such future architectures to be in the case where _TIME_BITS=64 
does nothing, much like existing 64-bit architecture ports and NaCl.

> On a related note, is there still a plan to allow building a glibc
> with 32-bit time_t disabled? I asked for that to be included in the
> past, but I don't see it in the Albert's document now, so I'm guessing
> that it was intentionally removed again.

A given glibc port has a given set of existing ABIs, which can't be 
removed without changing the SONAME.  That doesn't rule out making some of 
the old ABIs into compat symbols and disallowing building new binaries 
with _TIME_BITS=32, but that would be several years down the line if done 
at all.

(I expect we'll want to change the default for _FILE_OFFSET_BITS well 
before changing the _TIME_BITS default.  For _FILE_OFFSET_BITS, patches 
were posted a while back, and eventually evidence that 
_FILE_OFFSET_BITS=64 is the API most widely used for building libraries 
where it matters on GNU/Linux distributions; those patches need 
resurrecting.)

-- 
Joseph S. Myers
joseph@codesourcery.com