Development Plan Proposal for Unifying Interrupt and PCI APIs

[Chris Caudle]

On Saturday 23 October 2004 02:03 am, Eric Valette wrote:
>3) Probably interrupt sharing as PCI more ore less requires it nowadays.. 

Interrupt sharing has always been part of the PCI specification, although 
individual hardware implementations did not always take advantage of it.

If you allow interrupt sharing, you have to allow chaining of interrupt 
handlers, such that if an interrupt is signaled, the first handler is 
notified, and after that handler is finished, it must check the chain to see 
if any other handlers are registered for that same interrupt, and if so, pass 
along the notification to the next in the chain.

My personal opinion is that a real-time OS is justified in not supporting 
interrupt chaining, because you lose some ability to control the priority of 
particular hardware devices.  E.g. any two devices which share an interrupt 
will always be enabled or disabled together, and the first handler in the 
interrupt handler chain will always run first, even if the second handler 
should have higher priority.
PCI came from the Intel world originally, and desktop PC chipsets sometimes 
allowed interrupt sharing because of limitations in the number of inputs to 
the interrupt handling hardware, but I don't think the server chipsets 
typically used interrupt sharing.  I know that I try to never share 
interrupts on the embedded hardware I design (IBM PowerPC based).

My conclusion is that interrupt sharing might be nice to have as an option, 
but it would be used so infrequently in a real time system that the absence 
would not likely be missed.

-- 
Chris Caudle