lkml.org 
[lkml]   [2006]   [Mar]   [17]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 17 Mar 2006 23:07:50 +0100 (CET)
FromRoman Zippel <>
SubjectRe: [patch 5/8] hrtimer remove state field
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@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: 2006-03-17 23:14    [from the cache]
©2003-2008