All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.