Re: [PATCH 3/3] rtc: rtc-hid-sensor-time; add option hctosys to set time at boot

[Alexander Holler <holler@ahsoftware.de>]

Am 24.04.2013 23:14, schrieb Andrew Morton:
> On Tue, 23 Apr 2013 17:47:20 +0200 Alexander Holler <holler@ahsoftware.de> wrote:
>
>>>>> "time_was_set_once" and have choosen one day just in case something
>>>>> needs really long to boot (e.g. because of some lengthy fsck or whatever
>>>>> else).
>>>>>
>>>>> A solution to both problems might be to change the logic for hctosys
>>>>> completly to read the time when the first RTC device appears (or when
>>>>> the device mentioned in CONFIG_RTC_HCTOSYS_DEVICE appears). But that
>>>>> would require a change to hctosys or the RTC subsystem, which would
>>>>> involve more patches and discussion. As rtc-hid-sensor-time currently
>>>>> seems to be the only RTC with the above problems, I've gone the easy
>>>>> route and only modified this driver.
>>>>
>>>> Oh, damn. I've forgotten my example above with NTP. In that case setting
>>>> the time when the first RTC appears doesn't work.
>>>
>>> So a general solution might be to set the system time when the first RTC
>>> (or the one mentioned in CONFIG_RTC_HCTOSYS_DEVICE) appears AND nothing
>>> else did set the time before.
>>
>> To extend that idea a bit further, I think an option timewait (similiar
>> to rootwait) would be a nice to have.
>>
>> If just time wouldn't be that rare ... ;)
>
> Yes, some sort of notifier callout when the CONFIG_RTC_HCTOSYS_DEVICE
> device is registered seems appropriate.  I didn't understand why that
> is problematic for NTP.
>
> Getting all the lifetime/reference stuff right will be tricky :( Can't
> shut down or unload a driver when it is on that notification list.
>
> And it assumes that the CONFIG_RTC_HCTOSYS_DEVICE driver is all ready
> to go when it registers itself.  Hopefully that is true, but they
> should be reviewed.
>
> Adding the timewait thing sounds unpleasant - how to reliably tune the
> interval for all possible users of your distro?  We should aim to make
> things synchronous, deterministic and
> stuff-happens-in-the-correct-order.
>
> It all sounds like a moderate amount of work, but it would be great
> to be able to fix this for all drivers, not just hid-sensor-time.  That's
> assuming that other drivers have the same issue - perhaps they don't,
> but perhaps things can go wrong if the module loading order is wrong?
>

I've added John Stultz to cc as he seems to work on a similiar problem 
(to not set the time twice on resume).

I'm not sure what you meant with the notifiers, but wouldn't be a 
function which sets the time if nothing else did that before a solution?

I think about something like that (not real code):

static bool timeWasSet; // = 0

int setTimeIfNotSet(time, devicename)
{
   if (timeWasSet || (devicename && CONFIG_RTC_HCTOSYS_DEVICE && 
devicename != CONFIG_RTC_HCTOSYS_DEVICE )
     return -1;

   timeWasSet = 1;
   do_settimeofday(time);
   return 0;
}

That "timewait" kernel option I mentioned above then would be easy too:

void timewait(void)
{
   while (!timeWasSet)
     sleepOrSimiliar();
}

That setTimeIfNotSet() function could be called by the RTC subsystem 
whenever a new RTC will be registered and CONFIG_RTC_HCTOSYS is enabled 
(or on resume).
In regard to the persistent_clocks on x86 I know almost nothing. I 
didn't even knew they do exist before I've seen a discussion about 
HCTOSYS yesterday. I thought the RTC_CMOS driver is responsible for the 
time on x86. ;) Therfor I can't say anything about how things do work there.

Whats missing above is something which sets timeWasSet to 1 if userland 
(NTP or similiar) does set the time. That could be done always (in 
do_settimeofday) or e.g. by using a function pointer to 
do_settimeofday() which first points to a function which sets timeWasSet 
and later on points to do_settimeofday() directly.

Maybe it's all silly (I'm missing the big overview over time in the 
kernel), but thats what first entered my mind while thinking about how 
to avoid changing a time by an HID device if it was already set by 
userland/NTP or another clock (besides that trick in testing for system 
date < 1970-01-02 I've then used in my patch because it was easy to 
implement while not doing changes to timekeeping itself).

Regards,

Alexander