Interrupt vector sharing

[gregory.menke at gsfc.nasa.gov]

Chris Johns writes:
 > gregory.menke at gsfc.nasa.gov wrote:
 > 
 > > 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)
 > 
 > What about "BSP_install_rtems_add_handler" ?

The routine already in place for single handler vectors is

int BSP_install_rtems_irq_handler  (const rtems_irq_connect_data* irq)



 > 
 > This is what Solaris's DDI uses. See:
 > 
 >   http://docs.sun.com/db/doc/801-6680-9F/6i11r903r?a=view
 > 
 > If shared ints are not supported, only allow one addition and return an error if more 
 > are made.

I was creating the function name to be analgous to the one already
there.  I wouldn't be opposed to simply converting the existing
function to support shared vectors, however the existing api implies a
single handler per vector and I didn't want to violate that
assumption.
 
 > 
 > Why is BSP_* used ?
 > 
 > Would CPU_* have been a better prefix to use ?

BSP_* is used so it matches the existing vector API.  At some point
we'll have an integrated vectoring api, so the names will change anyhow.

 
 > > Unless there are strong objections, I think I'll give the
 > > modifications a try.
 > 
 > I am not objecting, just tring to keep the growth of new functions for specific cases 
 > when maybe one could be used.

The set of routines this function would be implemented in is 

lib/libbsp/powerpc/shared/irq/irq.c

which gives all the shared powerpc bsp's their irq support.  If I
understand things correctly, at least some of the i386 bsp's have a
very similar api.  This really needs to be integrated at some point...

Gregm