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