On 21/02/2016 at 12:40:20 +0000, One Thousand Gnomes wrote :

quoted

It doesn't change anything for 64-bit systems, I've excluded them by
using "depends on !64BIT". Right now, it doesn't change anything for
32-bit systems because either way, they will fail in 2038.

Which realistically won't actually matter because in 22 years time nobody
will be able to find a 32bit system in common use. If you look at x86
platforms today a Pentium Pro is already a collectors item. All of todays
locked down half-maintained embedded and phone devices will be at best
the digital equivalent of toxic waste if connected to anything.

The current 32 bit systems are not only phones. I'm not concerned by
those, they have an average 18 month live and the manufacturers are
already switching to 64 bit.
But there are long lived products like cars, parking ticket machines,
insulin pumps, automated external defibrillators, home automation
controllers, point of sales, etc... Some of those may still be in use in
22 years.

Or maybe we want to ensure that there is a Y2038 bug, that can be a good
retirement plan for the whole IT industry ;)

quoted

Won't we have to recompile every application to support 64-bit time on
32-bit system anyway? That will be a good time to remove that option.

How will you know when everyone has ? There's no "autodetect which
distribution I am running" feature.

I have the hope that the distribution maintainers know how to configure
a kernel and will ship a kernel with that option unset once they
switched to a 64 bit time userspace.

quoted

If the distribution don't recompile to support a 64-bit time, then the
32-bit systems will break in 2038 anyway and they will absolutely
require my patch or something along those lines to still boot using
systemd.

I disagree. Systemd has a serious robustness bug. Patch systemd to handle
timerd going off early and to take appropriate recovery action.

If you fix the systemd bug you'll also deal with a load of other weird
cornercases like 32bit guests on a 64bit host that accidentally ended up
post 2038, and every other freaky rtc failure.

Actually, I agree with Lennart that this is definitively a kernel bug
that has to be fixed. systemd is not the only affected application, any
user of timerfd is failing (actually, the first report I got was not
related to systemd at all).

I can also agree that systemd could be a bit more robust there but
you'll have to convince Lennart...


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.