Linux RTC
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
	rtc-linux@googlegroups.com,
	Alessandro Zummo <a.zummo@towertech.it>, Willy Tarreau <w@1wt.eu>,
	linux-kernel@vger.kernel.org
Subject: [rtc-linux] Re: [PATCH] rtc: Add an option to invalidate dates in 2038
Date: Mon, 22 Feb 2016 17:40:53 +0100	[thread overview]
Message-ID: <20160222164053.GQ2222@piout.net> (raw)
In-Reply-To: <2768647.1bFEcFDZRI@wuerfel>

On 22/02/2016 at 17:18:03 +0100, Arnd Bergmann wrote :
> > > IIRC, the problem is that user space passes in TIME_T_MAX and the kernel
> > > is considering that to be in the past because the clock is set beyond 2038.
> > > 
> > > I find it hard to blame user space for that, but I don't have a good
> > > idea for solving this either.
> > > 
> > > In case of systemd, it is literally the first thing that runs on the kernel
> > > after booting, so we could fall back to setting the time to some known
> > > working state (1970 or 2016 or something), but that would be a rather
> > > bad default policy once the system has been running for a while.
> > > 
> > 
> > Also, how would you know that it is an invalid time, some RTC doesn't
> > provide that information. 
> 
> What I meant was encountering a time past the 2038 date, which is invalid
> as seen from current 32-bit user space, but not necessarily from the
> kernel.
> 

I'm not completely sure how this would be different from my current patch...

> > One other workaround is to asked distributions
> > using systemd to stop using HCTOSYS so userspace would be responsible to
> > set the system time and in that case we won't have the 32/64 discrepancy.
> 
> I'm missing a bit of background here. This seems like a fairly useful
> piece of infrastructure for the majority of the use cases (working RTC)
> 
> How would the time get set when this is disabled? Is systemd able
> to read the rtc and write it back to the kernel? That could in fact
> be a nicer workaround for the problem, if it just does this before
> setting up the timerfd.
> 

I didn't check other distribution but debian and poky have
/etc/init.d/hwclock.sh that reads the rtc and sets the system time at
startup. It also saves the time to the RTC on shutdown.


-- 
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.

  reply	other threads:[~2016-02-22 16:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-20 19:10 [rtc-linux] [PATCH] rtc: Add an option to invalidate dates in 2038 Alexandre Belloni
2016-02-20 19:43 ` [rtc-linux] " One Thousand Gnomes
2016-02-20 20:47   ` Alexandre Belloni
2016-02-20 22:16     ` Arnd Bergmann
2016-02-20 23:17       ` Alexandre Belloni
2016-02-20 23:42         ` Alexandre Belloni
2016-02-21 12:40         ` One Thousand Gnomes
2016-02-22 13:00           ` Alexandre Belloni
2016-02-22 13:43             ` One Thousand Gnomes
2016-02-22 15:44               ` Arnd Bergmann
2016-02-22 15:56                 ` Alexandre Belloni
2016-02-22 16:18                   ` Arnd Bergmann
2016-02-22 16:40                     ` Alexandre Belloni [this message]
2016-02-22 16:41                     ` Austin S. Hemmelgarn
2016-02-22 16:58                       ` Alexandre Belloni

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=20160222164053.GQ2222@piout.net \
    --to=alexandre.belloni@free-electrons.com \
    --cc=a.zummo@towertech.it \
    --cc=arnd@arndb.de \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rtc-linux@googlegroups.com \
    --cc=w@1wt.eu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox