ISR Argument Proposal Request

[gregory.menke at gsfc.nasa.gov]

Joel Sherrill writes:
 > 
 > Till,
 > 
 > I think that we are all as much in agreement over this as we
 > will ever be.  Let's see if I can summarize and request that
 > you write up the API changes with a list of "key" area to 
 > change.
 > 
 > Some issues that must be resolved:
 > 
 >  + should rtems_interrupt_catch be backward compatable and
 >    this functionality have a new entry point?  I lean to yes.
 >  + should this feature be optional and conditionally compiled?
 >  
 > The development plan needs to have volunteers for each of 
 > the following:
 > 
 >   + generic change from table of handlers to table of 
 >     handlers/arguments
 >   + each port's irq handling
 >   + API changes to original interrupt API, ppc, x86, and ARM
 >   + documentation changes
 >   + any work break down I am missing?
 > 
 >   NOTE: When you change a port, I would consider that to include
 >   getting all the BSPs modified.  Everything should still build.
 >   I regularly build all BSPs so this is somethign I can provide
 >   feedback on.
 > 
 > We can't start this until we are confident all
 > the ports will get updated.

I can work on the mips side and test it on our hardware once theres
consensus on the implementation.

I would like to preserve the ability to pass a pointer to the stack
frame to the vector, preferably as an extra argument to the vector
call itself.  This is essential for some of our interrupt processing
and avoids unpleasant hacks.  In fact, we don't use the vector # at
all at present.

WRT backwards compatibility, as long as we can continue symbolically
refer to bsp-specific interrupt lines when calling
rtems_interrupt_catch, most any changes are fine with us.

Gregm