This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fourth draft of the Y2038 design document
- From: Arnd Bergmann <arnd at arndb dot de>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org, Albert ARIBAUD <albert dot aribaud at 3adev dot fr>, Y2038 <y2038 at lists dot linaro dot org>
- Date: Wed, 22 Jun 2016 22:11:57 +0200
- Subject: Re: Fourth draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20160622005838 dot 60a95c44 dot albert dot aribaud at 3adev dot fr> <4435377 dot 8hJ2GQPYUg at wuerfel> <alpine dot DEB dot 2 dot 20 dot 1606221418100 dot 29819 at digraph dot polyomino dot org dot uk>
On Wednesday, June 22, 2016 2:30:10 PM CEST Joseph Myers wrote:
> On Wed, 22 Jun 2016, Arnd Bergmann wrote:
>
> > Regarding the "Support for non-Y2038-safe kernels" section, I'm not
> > sure if that can work at all: A kernel that does not have the appropriate
> > system calls will also not have the handlers for a lot of the ioctl
> > commands and possibly other interfaces that rely on a specific
> > structure layout. If we can instead enforce that __USE_TIME_BITS64
>
> Maybe it's hard for ioctls, but I see no reason it shouldn't work for
> applications using normal non-ioctl glibc interfaces, with runtime
> fallbacks in glibc such as have been used for plenty of previous kernel
> features.
>
> Of course eventually we remove support for the older kernels - when they
> are no longer on the list at https://www.kernel.org/category/releases.html
> unless something comes up like the issue with people expecting to use new
> glibc on old virtualization solutions only supporting 2.6.32 kernels - but
> it would be good for people and distributions to be using / testing
> _TIME_BITS=64 before they reach the point of ceasing to support any older
> kernels.
Testing is a good point, we crearly don't want to force people to
give up support for older kernels in their glibc binaries in order
to be able to build with _TIME_BITS=64.
At the same time I'd be worried about users building a binary
against a new libc with _TIME_BITS=64 and then running into data
corruption because they are accidentally executing the binaries on
kernels that interpret the some ABI differently.
We can avoid most of the problems if building with _TIME_BITS=64
has no effect unless both glibc and the kernel headers are new
enough to provide the definitions for 64-bit time_t. That way
we can at least ensure that calling an ioctl command or setsockopt
with an incompatible ABI will result in an error code rather than
wrong data.
Arnd