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] [thread-next>] [day] [month] [year] [list]

Message-ID: <51798BF4.5020602@linaro.org>
Date:	Thu, 25 Apr 2013 13:03:00 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
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 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 isn't trivial 
size-wise itself). Instead either we can shrink the rtc core for those 
restricted uses or let them compile out the rtc core all together and 
let them manage time initialization completely in userland.

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

thanks
-john

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