Re: [patch 5/8] hrtimer remove state field

[Roman Zippel]

Hi,

On Thu, 16 Mar 2006, Thomas Gleixner wrote:

> > For example no current user restarts an active timer, which could be used
> > to simplify the locking.
> 
> How does this simplify the locking ? It just removes the
> hrtimer_cancel() call in hrtimer_start() and makes the
> switch_hrtimer_base() code a bit simpler.
> 
> The general locking rules would be still the same and I dont see
> increased flexibility at all.

Current users already do the serialize the calls into hrtimer themselves 
(stopping and restarting), which can make the locking even simpler.

> > If we tightened a bit what a user is allowed to 
> > do, we could gain flexibility on the other side, e.g. allow drivers to 
> > create timer sources or how to integrate cpu timer.
> 
> -ENOPARSE. Can you please explain what "allow drivers to create timer
> sources" means and why the above locking is in the way ?

For example dynamically attaching a timer_base to a clock source (e.g. to 
create a monotonic timer independent of NTP adjustments). Right now as 
soon as any timer_base is active it cannot be deconfigured again due to 
pointers to it from timers, so this would require different locking.

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/