On 05/21/2013 04:15 PM, Alexander Holler wrote:Am 22.05.2013 00:02, schrieb John Stultz:
Like Andrew, I think this feels particularly hacky.
Why exactly is late_init too early? (I'm unfamiliar with the
rtc-hid-sensor-time driver)
Currently it can be an USB device (and maybe Bluetooth or even i2c in
the future, depends on hid-sensor-hub). That has some implications:
(1) Initialization might need longer (or happens later) than
late_init, even if everything is linked into the kernel (same problem
as with a boot from USB-storage)
(2) It might not even be available at boot, but it should work if a
user plugs it in afterwards.
(3) To accomplish (2) it should set the system time (by default) IFF
nothing else did set the time.
That "nothing else" in (3) is for security reasons, because no
plugable HID device should be able to change the system time by default.
The check if something else did set the system time can't be
accomplished only by the RTC subsystem because userspace, network or
whatever else is able to set the system time most likely doesn't use
the RTC subsystem (or hctosys).
E.g. one of those setups could be:
boot
hctosys (fails because of no RTC)
ntpdate/rdate/date < whatever
load modules (rtc-hid-sensor-time)
If we would use a flag in the hctosys module then rtc-hid-sensor-time
would be able to change the time (in the setup above).
Using a module option which is by default off doesn't help too. Users
(or even distros) which would turn it on, might forget it and systems
would be at risk if no HID clock will be found at boot (but later
plugged in by some blackhat).
A flag in the time subsystem itself would do the trick. Such a flag
might help with the problem if the RTC subsystem or the persistent
clock code did set the time too. You've mentioned in another thread
that you had to solve such a problem, but I'm not aware how you did that.
Implementation could be as easy as a bool "time_set_at_least_once" in
the timer subsystem itself (e.g. in do_settimeofday() and whatever
similiar is available).
If it were to be done this way, it would be good to have the RTC layer
check when RTC devices are registered and call the internal hctosys
functionality then (rather then just at late_init). Do you want to try
to rework the patch in this way?
I'm not totally sure I'd agree that it would be better over leaving it
to userspace, but if we're going to go with an in-kernel policy for
this, then it seems like a better approach then the current patch.