From: John Stultz
Date: Thu Apr 25 2013 - 16:03:12 EST

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

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at