From: Ingo Molnar <mingo@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>,
Tobias Waldekranz <tobias@waldekranz.com>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] timekeeping: handle epoch roll-over (2038) on 32-bit systems
Date: Thu, 20 Jun 2013 14:34:59 +0200 [thread overview]
Message-ID: <20130620123459.GA17359@gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1306072308040.24812@ionos>
* Thomas Gleixner <tglx@linutronix.de> wrote:
> On Mon, 3 Jun 2013, John Stultz wrote:
> > On 06/03/2013 07:34 AM, Thomas Gleixner wrote:
> > > Though even if we fix that we still need to twist our brains around
> > > the timespec/timeval based user space interfaces. That's going to be
> > > the way more interesting challenge.
> >
> > I'm curious if there are any there other ideas that folks are considering?
>
> Honestly, we have almost 25 years ahead of us to solve that. So why
> hurry? If Tobias thinks that his embedded system of today needs to
> survive 2038 without updating the kernel and all of userspace, then
> all I can do is wish him good luck. Albeit we should not waste 25
> years and run into another Y2K horror. :)
>
> The only solid solution is to implement a new set of syscalls (and
> there are not that many which are affected by this). The new syscalls
> should use a nanosecond based scalar time value and get rid of the
> timespec /timeval / time_t nonsense alltogether. That reduces the
> number of new syscalls significantly.
>
> That time value should be 64bit, also people might argue, that we are
> creating a new issue for the year 2554, i.e 541 years from now. I
> don't think we need to worry about that really. We have to leave our
> grand-grand-grand..grandchildren (~20 generations from now) a few
> unsolved problems!
>
> The evil plan to make this happen looks like this:
>
> 1) Convert the core code to u64 with a timespec based shadow
> infrastruture to avoid performance regressions in the first
> place.
>
> 2) Add new u64 based syscalls
>
> 3) Disable the timespec based shadow infrastructure five years
> from now to force all lazy buggers who ignored the new syscalls
> to fix their crap.
>
> 4) Deprecate the old syscalls 10 years from now
>
> 5) Remove the old syscalls 100 years from now so Linus won't hunt
> us for breaking userspace :)
50 years from now should be enough for most of us - beyond that there will
be no hunting, only haunting ... ;-)
Thanks,
Ingo
next prev parent reply other threads:[~2013-06-20 12:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-03 13:34 [PATCH] timekeeping: handle epoch roll-over (2038) on 32-bit systems Tobias Waldekranz
2013-06-03 14:34 ` Thomas Gleixner
2013-06-03 19:04 ` John Stultz
2013-06-07 21:53 ` Thomas Gleixner
2013-06-20 12:34 ` Ingo Molnar [this message]
2013-08-24 23:47 ` Michael Gilbert
2013-06-04 6:59 ` Tobias Waldekranz
2013-06-07 20:57 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130620123459.GA17359@gmail.com \
--to=mingo@kernel.org \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tobias@waldekranz.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.