Development Plan Proposal for Unifying Interrupt and PCI APIs

[Chris Caudle]

On Saturday 23 October 2004 01:34 pm, Thomas Doerfler wrote:
> Each interrupt handler must do a very quick check, whether its 
> hardware device has raised the interrupt or not. If the related 
> hardware device did not raise the interrupt, the handler 
> terminates with a certain return code. And only in this case, 
> the OS goes further on to poll the next handlers.

You have to be careful of starvation of the secondary devices in certain race 
conditions.

Take the case where a device is generating interrupts very quickly, and a 
device sharing that interrupt line generating interrupts more slowly.

If the first device handler services the interrupt, then returns with the code 
which says an interrupt was serviced, and so the next handler is not polled.
If the second device is actually generating an interrupt, the interrupt 
handler will be called again.  If in the intervening span of time, the first 
device also signals an interrupt again, the first device will again be 
serviced, and the second device will not.

That may be desired behavior, but it needs to be documented very clearly.

-- 
Chris Caudle