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

[Theodore Ts'o <tytso@mit.edu>]

On Tue, May 06, 2014 at 01:33:37PM -0700, josh@joshtriplett.org wrote:
> 
> 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?

It might be useful if someone were to do a bit of homework first.  How
many system calls (and there will be some ioctl's too, but system
calls will probably be the hard part) that are using a 32-bit time_t
(including struct timeval and struct timespec) or clock_t?  Can
someone produce a list so we know how many interfaces we're talking
about here?

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

My experience is that mailing list discussions (like this one) are
better at this kind of brain-storming than the actual face-to-face
summit meeting.  Summit meetings are good for weighing tradeoffs
between different possible solutions, but in general, things go much
more smoothly if someone has done some homework and outlined a few
possible proposals (even if they are strawman proposals) to prime the
discussion.

So I'm not just picking on this topic, but in general --- if we have
topics of the form, "we should bell the cat", the program committee
will be more likely to consider it a good use of everyone's time if
there is evidence that some potential technologies for applying the
bell to the cat (and how to handle minor problems like the cat's teeth
and claws) have been considered raised ahead of time.  (And of course,
if someone sends a patch making the whole discussion moot, that's even
better.  :-)

Cheers,

						- Ted