Timothy Normand Miller wrote:
I wouldn't want to say that this discussion is off-topic;
Actually, this discussion has become useless since it is now based on
Paul Brook engaging in what I believe is called "hit and run" or "petty
flogging" in rhetoric. Unfortunately such substitutes for useful
discussions tend to start on mailing lists.
interrupts are hardware-related after all. But I think the
discussion is a bit noisy, because there are plenty of primary
resources where one can learn how peripherals, PCs, and kernels
handle interrupts.
Yes, this is based on hardware. Things were said about PC hardware that
are not true. Now that I have done research to establish that what I
originally said (that PCI CAN have more than 4 shared interrupts)
additional issues have been raised. And so it goes.
I would recommend consulting those first and then asking questions
about the parts that you don't understand. Some of you may benefit
from doing some reading on how ISRs need to be constructed for
various kernels, like Linux, NT, Solaris, *BSD, etc. Particularly for
Linux and the BSDs, there is plenty of documentation online.
A goggle search failed to turn up the needed information on exactly how
the 2.6.current Linux Kernel handles shared interrupts. I think that I
know how 2.4 does it. It polls ISRs and if their device has raised the
interrupt it services it. This can result in serious latency issues.
IIUC, the new Kernel 2.6.x has made improvements in this (e.g.
preemption of the Kernel).
Still, the best response will always be RT servicing of separate (in
hardware) interrupts.
At first look, it appears to me that the service ISR could cause latency
problems with the sync interrupt if they share the same interrupt. This
is the real issue that needs to be discussed.
--
JRT
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
