Re: [patch 00/21] hrtimer - High-resolution timer subsystem

[Roman Zippel <zippel@linux-m68k.org>]

Hi,

On Wed, 14 Dec 2005, George Anzinger wrote:

> > > IMHO then, the result should have the same property, i.e. ABS_TIME.  Sort
> > > of
> > > like adding an offset to a relative address. The result is still relative.
> > 
> > 
> > If the result is relative, why should have a clock set any effect?
> > IMO the spec makes it quite clear that initial timer and the periodic timer
> > are two different types of the timer. The initial timer only specifies how
> > the periodic timer is started and the periodic timer itself is a "relative
> > time service".
> > 
> Well, I guess we will have to agree to disagree.

That's easy for you to say. :)
You don't think the current behaviour is wrong.

>  That which the interval is
> added to is an absolute time, so I, and others, take the result as absolute.
> At this point there really is no "conversion" to an absolute timer.  Once the
> timer initial time is absolute, everything derived from it, i.e. all intervals
> added to it, must be absolute.

With this argumentation, any relative timer could be treated this way, you 
have to base a relative timer on something.
While searching for more information I found the NetBSD code and they 
do exactly this, they just convert everything to absolute values and clock 
set affects all timers equally. Is this now more correct?

> For what its worth, I do think that the standards folks could have done a bit
> better here.  I, for example, would have liked to have seen a discussion about
> what to do with overrun in the face of clock setting.

Maybe they thought it wouldn't be necessary :), because a periodic is a 
relative timer and thus not affected...

bye, Roman
-
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/