lkml.org 
[lkml]   [2005]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 00/21] hrtimer - High-resolution timer subsystem
Nicolas Mailhot wrote:
> On Mer 14 décembre 2005 00:38, George Anzinger wrote:
>
>>Nicolas Mailhot wrote:
>>
>>>"This is your interpretation and I disagree.
>>>
>>>If I set up a timer with a 24 hour interval, which should go off
>>>everyday at 6:00 AM, then I expect that this timer does this even when
>>>the clock is set e.g. by daylight saving. I think, that this is a
>>>completely valid interpretation and makes a lot of sense from a
>>>practical point of view. The existing implementation does it that way
>>>already, so why do we want to change this ?"
>>
>>I think that there is a miss understanding here. The kernel timers,
>>at this time, do not know or care about daylight savings time. This
>>is not really a clock set but a time zone change which does not
>>intrude on the kernels notion of time (that being, more or less UTC).
>
>
> Probably. I freely admit I didn't follow the whole discussion. But the
> example quoted strongly hinted at fudging timers in case of DST, which
> would be very bad if done systematically and not on explicit user request.
>
> What I meant to write is "do not assume any random clock adjustement
> should change timer duration". Some people want it, others definitely
> don't.
>
> I case of kernel code legal time should be pretty much irrelevant, so if
> 24h timers are adjusted so they still go of at the same legal hour, that
> would be a bug IMHO.

I am not quite sure what you are asking for here, but, as things set
today, the kernels notion of time starts with a set time somewhere
around boot up, be it from RT clock hardware or, possibly some script
that quires some other system to find the time (NTP or otherwise).
This time is then kept up to date by timer ticks which are assumed to
have some fixed duration with, possibly, small drift corrections via
NTP code. And then there is the random settimeofday, which the kernel
has to assume is "needed" and correct.

On top of this the POSIX clocks and timers code implements clocks
which read the current time and a system relative time called
monotonic time. We, by convention, roll the monotonic time and uptime
together, and, assuming that the NTP corrections are telling us
something about our "rock", we correct both the monotonic time and the
time of day as per the NTP requests.

Timers are then built on top of these clocks in two ways, again, as
per the POSIX standard: 1) the relative timer, and 2) the absolute
timer. For the relative timer, the specified expiry time is defined
to be _now_ plus the given interval. For the absolute timer the
expiry time is defined as that time when the given clock reaches the
requested time.

The only thing in here that might relate to your "legal" hour is that
we adjust (via NTP) the clocks so that they, supposedly, run at the
NBS (or is it the Naval Observatory) rate, give or take a small,
hopefully, well defined error.
>

--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-12-15 02:14    [W:0.052 / U:0.704 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site