Re: Fourth draft of the Y2038 design document

[Arnd Bergmann <arnd at arndb dot de>]

On Thursday, June 23, 2016 2:32:50 PM CEST Joseph Myers wrote:
> 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.)

Ok, thanks for clarifying.

> > 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.

Ok.

> > 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.

Ok, got it.

> (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.)

I think the two flags are somewhat different from a user perspective:

_FILE_OFFSET_BITS=64 is generally a good idea and is required for some
applications, while others are fine without it. In contrast, _TIME_BITS=64
has zero benefit for most users of 32-bit machines, but for those people
that need it, it is essential that /all/ user space is built with that
option.

I would also guess that it's harder distros to do a gradual migration
for time_t than it is for off_t because there are more libraries that
expose interfaces with time_t and those libraries do not all use
symbol versioning but would get a silent ABI break from rebuilding
with _TIME_BITS=64.

I expect that most distros will not turn _TIME_BITS=64 at all because
it's easier to just stop supporting 32-bit binaries at some point
in the next 20 years, while the ones that plan to keep supporting them
will not do a gradual migration but instead force a rebuild of all
binaries at the same time.

For the second use case, a changed SONAME would make sense too, but
I understand this is not something you'd introduce lightly, and
it's clear from your explanation that you wouldn't add this for
the first version.

Is there a policy about what justifies such an ABI break? I.e. is it
possible to add a build-time configuration flag later that disables
32-bit time_t support for an existing architecture while setting
a different SONAME, assuming there is sufficient user interest for
this feature? I see a couple of different options that change SONAME
on https://sourceware.org/glibc/wiki/ABIList, but those are all
for fundamental incompatibilities, not for voluntary ABI breaks.

	Arnd