On Mon, 2006-04-03 at 21:54 +0200, Roman Zippel wrote:
> Another general comment from an arch/driver specific perspective: right
> now everything is rather concentrated on getting the time, but AFAICT it's
> more common that the subsystem which is used to read the time is also used
> as timer (i.e. for the scheduler tick), this means the clocksource driver
> should also include the interrupt setup.
I don't think so. Coupling the clock sources to clock event sources is
wrong. In many systems the clock event source delivering the next event
interrupt - either periodic or per event programmed - is independend
from the clock source which is used to read the time.
Also we want to distribute multiple clock event sources for various
services. Hardwiring those into combos is counter productive.
> i386 is currently rather hardcoded to use the i8253 timer, but AFAIK it
> would be desirable to e.g. use HPET for that (especially for hrtimer).
> Something like TSC should internally use another clocksource to provide
> the timer interrupt.
This is exactly the result of such an artificial combo. "Use internally
something else." Thats fundamentally wrong and violates every basic rule
of abstraction.
> Anyway, i386 is quite a mess here right now and I can
> understand that you wanted to stay away from it with the generic
> gettimeofday infrastructure. :-)
He ? John addressed the clock source (timeofday) related problem in
x386. He never claimed that his timeofday code is solving the clock
event source problem. gettimeofday() exactly does what it says: it gets
the time of day. And it does it independend of any interrupt source in
the first place.
Clock event sources need their own independent abstraction layer, as one
can be found in my high resolution timer patch queue. There is
interaction between the timekeeping and the next event interrupt
programming, but it's important to keep them seperate.
How should a combo solution allow to add special hardware, which
provides only one of the services ? By using "something else
internally" ? No, thanks.
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]
