On Fri, 2006-03-17 at 23:07 +0100, Roman Zippel wrote:
> > 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.
Serialization of the users does not help for protecting the timer queues
especially not on SMP.
Can you please give a real example how to simplify this. Nobody has any
objections to simplify locking when possible. But unproven claims in
repeated form do not help. After a while they just get annoying.
> > > 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.
I do not really understand what you want to achieve.
Timer bases are related to clock sources. You can switch the clock
source of the CLOCK_MONOTONIC timer base at any given time to a
different one which is not NTP adjusted. Where is the problem?
The timer base does not care about the underlying clock source at all.
All it knows of it is the function which reads the current time related
to this clock. When the underlying clock changes the way it generates
current time then the timer base does not care at all.
This is not a problem of hrtimers. Its a problem of the clock source
abstraction layer like John Stultz GTOD framework.
If you want to have timer bases with dynamic clock sources which can go
away then you have to take care of much more than locking. But I really
do not see a need for this.
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
