lkml.org 
[lkml]   [2013]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/3] rtc: rtc-hid-sensor-time; add option hctosys to set time at boot
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


\
 
 \ /
  Last update: 2013-04-25 09:21    [W:0.367 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site