![]() | |||||||||||||
Messages in this thread |
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 | |||||||||||||