[Ksummit-discuss] [CORE TOPIC] Dealing with 2038
Josh Triplett
josh at joshtriplett.org
Tue May 6 02:21:59 UTC 2014
On Mon, May 05, 2014 at 07:12:54PM -0700, H. Peter Anvin wrote:
> On 05/05/2014 01:53 PM, josh at 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
More information about the Ksummit-discuss
mailing list