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

[josh@joshtriplett.org]

On Tue, May 06, 2014 at 04:19:59PM -0400, Theodore Ts'o wrote:
> On Tue, May 06, 2014 at 08:20:47PM +0200, Arnd Bergmann wrote:
> > Medical equipment (and I assume military, which is often in the same
> > category) is probably a big thing. I remember we had a big discussion
> > about a product at a former employer when a customer asked for support
> > beyond 2038. I think we ended up saying that the hardware is fine but
> > no supported distro would handle this.
> 
> The question for the kernel summit is what sort of solutions can we
> suggest where we as kernel developers could help provide a solution
> for this problem?
> 
> If the answer is "the kernel is fine (or could be trivially made
> fine)" but the problems are all at the glibc and/or distro level, then
> it's a problem, but I'm not sure we'd be able to make progress on
> solving it in this venue.

I don't think it's entirely trivial to make the kernel fine.  Two topics
that *do* make sense for Kernel Summit:

- How do we fix existing ABIs while making it minimally painful to
  transition existing userspace to the new ABI?  Should we just
  introduce a replacement for every system call that includes a time_t
  and deprecate the old ones, or should we introduce some more
  systematic migration mechanism?

- Can the kernel do anything to make the transition easier for libc or
  other userspace programs?

One possible approach to that second point that might be worth exploring
independently, though I'd expect it to prove controversial:

- Could we move some of the userspace compatibility code out of the
  kernel and into low-level userspace shipped with the kernel?


- Josh Triplett