Re: [PATCH] timekeeping: handle epoch roll-over (2038) on 32-bit systems

[Thomas Gleixner <tglx@linutronix.de>]

Tobias,

On Tue, 4 Jun 2013, Tobias Waldekranz wrote:
> On Mon, Jun 03, 2013 at 04:34:25PM +0200, Thomas Gleixner wrote:
> > Just "fixing" some random parts of the code in a "make it work
> > somehow" way is a pointless exercise IMO.
> > 
> Now hold on, it is hardly random. On an ARM system, the kernel will
> completely hang. I would think that many users would like to avoid
> that. In addition this behavior is rather new, hrtimer_interrupt used
> to source its time from ktime_get which avoids this issue. The change
> was introduced in:
> 
> 5baefd6d84163443215f4a99f6a20f054ef11236
> 
> I understand that you would like a solution to the broader issue. But
> for some users (embedded especially) having a system that continues to
> operate 25 years from now is an issue today.
> 
> As for "make it work somehow", modifying the current time calculation
> to work in the same way as in ktime_get does seem to be a reasonable
> way to go IMO.

No, it's not. You are "fixing" something which is not fixable by
definition. There is no rule to prevent similar borkage tomorrow.

You are just band aiding a singular instance of a massive problem
which has an already known root cause.

If you really care about your system working in 25 years from now with
the kernel of today then you rather should sit down and fix it proper.

Your "fix" merily allows the system to boot, but its broken beyond
repair aside of that. So what's the point?

If we do not tackle the underlying issues, then your machine will be
rendered completely useless with or without your patch. It's that
simple. So don't try to sell me a bandaid hack as a reasonable way to
go.

Thanks,

	tglx