Re: [Ksummit-discuss] [CORE TOPIC] Dealing with 2038

[Grant Likely <grant.likely@secretlab.ca>]

On Tue, 6 May 2014 08:57:41 -0400, Theodore Ts'o <tytso@mit.edu> wrote:
> On Mon, May 05, 2014 at 07:21:59PM -0700, Josh Triplett wrote:
> > 
> > 64-bit off_t support seems like a similar issue; all the kernel
> > interfaces support 64-bit off_t, and glibc has #defines for
> > 64-bit off_t, but a large number of userspace programs don't bother to
> > define them.
> > 
> > That seems like the right path to transition time_t as well.
> 
> It's actually quite different, because there off_t isn't used in
> userspace libraries or data structures nearly as much as time_t.  It's
> not that terrible if you have some libraries which are compiled with
> 64-bit loff_t (note the different type) and some userspace programs
> which aren't.  But the problems if some libraries want to use a 64-bit
> time_t and some programs are still only able to support a 32-bit
> time_t are much more trickly.
> 
> I suspect the only real way of dealing with the problem for 32-bit
> architectures is to consider doing a major version bump for all shared
> libraries, and for a while, 32-bit distributions might have to ship
> two versions of all of the more popular shared libraries.
> 
> It might be easier for x86 to simply say, "suck it up", if you care,
> you should use x32 ABI.  However, I believe the original concern was
> that there might still be 32-bit x86 chips still out there in 2038,
> and x32 won't solve that problem, unfortunately.

And not just x86. There will be a very long tail of 32-bit embedded platforms
that will continue to be produced in huge quantities because they are
cheap. Tim's cereal box freebie Linux machine isn't far fetched.

g.