> On Sep 30, 2019, at 12:41 AM, Alexandre Belloni
> <[email protected]> wrote:
>
> My opinion is that distributions should stop relying on HCTOSYS and do
> the RTC read from userspace. This is especially important because
> distros are hardcoding rtc0 as the RTC to read from which is most likely
> to not be the correct one on any embedded device.
>
> This is not Lennart's opinion though:
> https://lkml.org/lkml/2019/8/14/248
>
> He later dismisses your use case in:
> https://lkml.org/lkml/2019/8/14/454
>
> "I'd argue that in the vast majority of cases the person building the
> kernel for a device knows very well which RTC is connected to the
> device they are interested in, and should just build that driver in,
> and don't bother with userspace complexity, later userspace module
> loading or anything like that."
>
> --
> Alexandre Belloni, Bootlin
Lennart’s argument fails, however, if you are on a machine like the Raspberry
Pi where the hardware clock (and its driver) are provided (or not) by the
end-user (or the supplier who sold them the clock) In that case, there’s no way
for the kernel to know at compile time what clock is installed.
Another case where this argument falls down is the Cubox-iPro which has two
hardware clocks. The first, labeled /dev/rtc0 by the Debian kernel, is
accurate as long as the power is up, but it has no battery backup, so when the
power fails they clock fails as well. The second, labeled /dev/rtc1 by Debian,
has an optional battery backup, so it can (but may not depending on whether the
battery is installed) ride thru a power failure. It’s a user option whether to
install the battery, so again, not something the kernel can know at compile
time.
Rick
