Messages in this thread | | | Subject | Re: [PATCH 0/5] clocksource patches | From | Thomas Gleixner <> | Date | Wed, 05 Apr 2006 13:22:47 +0200 |
| |
Roman,
> Thomas, I would really appreciate if you actually started to argue your > point instead of just disagreeing with me every time. I have no problem to > admit that I'm wrong, but it takes a bit more than you just saying it is > so.
I on my side would appreciate, if you would stop to take every line I write as a personal offense.
> For example above you bascially only state that your clock event source > is superior and the correct way of doing this without any explanation why > (and the "No, thanks." doesn't exactly imply that you're even interested > in alternatives).
The question arises, who is not interested in alternatives. You are well aware about the efforts others made, but you don't even think about working together with them. Do you really expect people to jump on your train, when you entirely ignore their work and efforts and just propose your own view of the world?
I did nowhere say that I'm not interested in alternative solutions. You interpret it into my words for whatever reason.
Your way to rip out a single statement of its context and making your argument on that is simply annoying.
Thats the original quote: > How should a combo solution allow to add special hardware, which > provides only one of the services ? By using "something else > internally" ? No, thanks.
It is entirely clear, that "No thanks" is related to "something else internally".
Thats the point I made further up in my first reply. It was your proposal to combine clock sources and clock events. This works nice where both are in the same hardware device, but its not a compulsory argument for a combined abstraction layer. You said that in case there is one element missing (e.g. TSC has no clock event source) it should internally use "something else".
That's excatly the point I'm referring to. Do you think that "Use something else" is a real good and convincing technical argument? No, such a statement is simply the evidence that your design is flawed.
I assume we agree that we want abstraction of clock soures (read time) and clock event sources (periodic / next event interrupts).
Why are those seperate items ?
Looking at the various hardware implementations there are three types of devices:
1. Read only devices (e.g. TSC) 2. Next interrupt only devices (e.g. various timer implementations on SoC CPUs) 3. Devices which combine both functions
Building an abstraction layer which handles all device types requires either
- that e.g. a read only device needs to be combined with a next interrupt device in some way. This introduces artifical combos of functionality which can and should be handled completely seperate.
or
- to handle all the corner cases where a device has to be handled which only provides one of the functionalies. Also the selection of different combinations of devices will introduce extra handling code.
Futhermore the functionalites of clock sources and clock event source can be used completely independent. In case of a periodic event there is no interaction with the clock source at all. The readout of the clock source is independent of any kind of event.
So we have two functional domains, which provide a high level interface:
The clock source abstraction provides: - gettimeofday() - getmonotonic() - settimeofday() - clock skew adjustment functions()
The clock event source abstraction provides: - setup periodic events() - setup one shot events() - associate services (function to call on an event) to a clock event source
This is a clear seperation and there is no combined functionality.
The availability of devices which combine both functions is not changing the clear functional seperation of clock sources and clock event sources at all.
Programming one shot events might need information from the clock source layer e.g. to calculate the delta to the next event, but it does not need this information on a low level base. The information is read from the high level interface. Moving this to the low level interfaces would enforce particular combinations of clock sources and clock event sources and remove the flexibility to use arbitrary combinations on a best fit selection.
Back to your questions:
> Why? In order to program a clock event you have to be able to read the > clock somehow. In many systems it's the same hardware.
Yes, it is the same hardware. It is not the same level of abstraction.
The next event is defined by a absolute time in human units (i.e. nanoseconds). The delta to the next event is calculated by
delta = next_event - now
Then delta is converted to the time units of the underlying hardware device.
You might argue, that you also can convert the next_event time to the time units of the underlying hardware first and then caclulate the delta for the next event interrupt hardware.
This is only true, when those devices are combined and it results in different handling of the same problem for different combinations of hardware or even restricts the possible combinations depending on the implementation details. Thats why I said it violates the basic rule of abstraction.
> Why and what "basic rule of abstraction"?
Whats abstraction ? The generic way to access a functional domain to allow users of the functional domain to be hardware agnostic.
As I showed above there are two functional domains: clock sources and clock event sources
The high level interfaces of the functional domains use an hardware independent representation of time, i.e. human time units (nano seconds). Any interaction between the functional domains also uses the hardware independent representation.
This is the basic guarantee, that such abstraction layers are flexible and of general use.
Interaction or interdependencies of functional domains are not a reason to combine them into one "handle it all" domain.
tglx
- 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/
| |