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

[Josh Triplett <josh@joshtriplett.org>]

On Mon, May 05, 2014 at 07:12:54PM -0700, H. Peter Anvin wrote:
> On 05/05/2014 01:53 PM, josh@joshtriplett.org wrote:
> > 
> > I would be interested in this, not just because of time_t itself, but as
> > a general pattern for "how can we transition away from an old and broken
> > ABI".  Whether by introducing new system calls, new personalities,
> > seccomp filters, or other mechanisms, we should have some ways to start
> > such transitions and to smooth them out.  Sure, we never break
> > userspace, but that just means we need an appropriate
> > CONFIG_OLD_AND_BUSTED option for as long as people still need the old
> > ABI.
> > 
> 
> There is absolutely nothing new here... we have dealt with these kinds
> of transitions for most of Linux' existence.
> 
> However, time_t is a particularly nontrivial issue, because it is not
> just a matter of changing the kernel ABI but a *lot* of user space ABIs
> also contain this type.  The kernel/glibc interfaces are pretty well set
> up to handle this properly these days, but I have very little hope that
> all the user space libraries will properly handle having two versions of
> a bunch of APIs with different version numbers.

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.

- Josh Triplett