[EMAIL PROTECTED] wrote:
On Tue, 15 Feb 2005, Philippe Gerum wrote:
Additionally, this would mean that some dependency exists in some kernel
code between distinct interrupt sources. Given the asynchronous nature
of interrupts, I'd be interested to have a legitimate example of a
situation where a code would have enough knowledge to expect two or more
unpredictable events on a given timeline to operate properly. The only
situation which gets closer, but still different from the latter, is the
pckbd driver for x86, which happens to busy wait for a subsequent kbd
interrupt on top of its own ISR. But in this case, queuing would be
overkill since interrupts are of the same kind, counting IRQs is enough.
We had a similar OEM-suppplied driver... And this is exactly how we did it
- a list plus counters for each interrupt.
If it's similar to the kbd stuff, then it's already ok. If it's similar
in the sense that it relies on being able to get predictability from an
unpredictable flow of events, then I'd would preferably go for the old
UN*X mantra: don't have 99% of your users pay some expensive cost for a
"feature" in the critical path that only 1% need. IOW, the driver should
be fixed instead.
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany
_______________________________________________
Rtai-dev mailing list
[EMAIL PROTECTED]
https://mail.gna.org/listinfo/rtai-dev
--
Philippe.
