Interrupt vector sharing

gregory.menke at gsfc.nasa.gov gregory.menke at gsfc.nasa.gov
Thu Mar 13 17:07:58 UTC 2003


I've been thinking a bit about how to handle the shared interrupt
issue.  It seems to me the existing powerpc/shared irq handling code
could be augmented to include a new function;

int BSP_install_rtems_shared_irq_handler
                 (const rtems_irq_connect_data* irq)

which lets the user install a series of handlers on a given vector.
Internally, the vector table is still the same, but the
rtems_irq_connect_data type gains a pointer to support a linked list
connecting all the handlers on each vector.  The dispatch code will
then run down the list, calling each handler.

By adding this single new function (and tweaking the existing irq
table management), existing vector allocation semantics can be
preserved- meaning a vector assigned via the old single hander
function won't allow shared vectors to be added.  Then, drivers can be
individually migrated to shared vectors.

Vector removal would be extended in the obvious way, so I think its a
pretty small change that doesn't perturb irq.c too much- at least on
the ppc.

This doesn't work towards integrating the vector infrastructure
between ppc and x86, but I think pending something like that showing
up, its a good incremental improvement.  I think it makes the
proliferation of devices on pci based RTEMS hosts essentially
feasible, which is only possible now with some very hardware-specific
userspace coding.

Unless there are strong objections, I think I'll give the
modifications a try.

Thanks,

Greg Menke




More information about the users mailing list