This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fourth draft of the Y2038 design document

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]