linux-kernel - Re: CONFIG_RTC_HCTOSYS lost on x86 with ALWAYS_USE_PERSISTENT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20130425210231.GE31863@obsidianresearch.com>
Date:	Thu, 25 Apr 2013 15:02:31 -0600
From:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:	John Stultz <john.stultz@...aro.org>
Cc:	Alexander Holler <holler@...oftware.de>,
	Kay Sievers <kay@...y.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Feng Tang <feng.tang@...el.com>
Subject: Re: CONFIG_RTC_HCTOSYS lost on x86 with ALWAYS_USE_PERSISTENT_CLOCK
 changes?

On Thu, Apr 25, 2013 at 01:03:00PM -0700, John Stultz wrote:
> On 04/25/2013 11:33 AM, Jason Gunthorpe wrote:
> >John mentioned they might be kept for embedded - eg size reduction.
> >The issue with that idea is if you do not enable the class RTC
> >subsystem then there is no way for a small embedded userspace to set
> >the RTC. The /dev/rtc* device obviously goes away, but it also turns
> >out that that CONFIG_GENERIC_CMOS_UPDATE only works when combined with
> >a heavy weight userspace NTPD that runs the kernel PLL properly. The
> >kernel NTP code is enormously conservative and it is actually quite
> >hard to get it to write to the RTC. An RTC that cannot be set is
> >useless, so these days I feel CONFIG_RTC is pragmatically mandatory -
> >and my space constrained embedded systems do set it, for these
> >reasons.
> 
> So I mentioned that the size-reduciton focused folks might not like
> the generic rtc core over the persistent_clock code, but I'm not
> convinced that's a reason to keep the persistent clock code (which

What I mean is you can't actually choose to use persistent_clock over
rtc core, that is not a choice. The only choice these days it to omit
the user space interface to the RTC (eg rtc core). On some platforms
the RTC will still get *read* during boot via persisent_clock, but no
platform has a way for userspace to *set* via
persisent_clock. update_persisent_clock is not connected to userspace
anymore.

An unsettable RTC is useless, IMHO.

> I only noted it, because it has come up prior as a complaint when
> switching to the RTC core was proposed.

Sure, but, AFAIK, that was a general concern of /dev/rtc vs /dev/rtc0
- however since then we have lost /dev/rtc completely. That means
there is no longer any way to access the persistent_clock functions
from userspace.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/