Development Plan Proposal for Unifying Interrupt and PCI APIs

[Thomas Doerfler]

Hello,

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

I would say as a first statement: the hardware requires it, so 
the software must support this.

> 
> 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.

I do not agree: In OS-9, you could (can?) attach multiple 
interrupt handlers to each vector. When you attach (or register) 
a handler, you also specify a "polling priority", which 
determines, at which location it is placed in the "interrupt 
handler polling table" for this particular vector. With this, 
you can (at least in theory) predefine, which of the possible 
interrupt handlers will be called first.

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.
> 
> 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.

You can influence this with the position of the handlers in the 
polling chain. And, AFAIK each PCI device MUST have a means to 
disable its IRQ output, so even if two devices are on the same 
line, they can be disabled/reenabled individually.

> 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).

On many standard cards (e.g. Motorola PPC based VME cards) or in 
Compact PCI systems, you will end up in interrupt sharing again. 
I think it is not a good idea to make RTEMS ignore these 
systems.

> 
> 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.

Surely having a system with interrupt share is a nightmare, if 
hard realtime behaviour is needed, but I would strongly vote to 
support it in RTEMS. If you have a "proper" hardware, you won't 
need it and the overhead involved in RTEMS will be minimal. For 
systems with a shared interrupt hardware, supporting this scheme 
is vital.

Thomas Doerfler.

> 
> -- 
> Chris Caudle

--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler           Herbststrasse 8
D-82178 Puchheim          Germany
email:    Thomas.Doerfler at imd-systems.de
PGP public key available at: http://www.imd-
systems.de/pgp_keys.htm