ISR Argument Proposal Request

[Eric Norum]

Joel Sherrill wrote:
> 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?

I'm pretty hesitant about conditional compilation.  There are an awful lot of 
configuration time decisions already.  Complicating the process further is 
just going to increase the confusion among new users.   The argument for 
providing a way to turn off the feature is pretty strong since the feature 
costs an extra 1k of memory bloat on M68k architectures (256*sizeof(void*)).
I'm dithering here, but at the moment I guess I'd argue for 'conditional, but 
default is to include'.  (Sort of like the Canadian Prime Minister who stated, 
''Conscription if necessary, but not necessarily conscription.'')

>  
> 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 do the M68k assembler changes if no one else can be found.
Also, I think this has been decided already, but if we're going to open up the 
code and make these changes I vote for a 'void *' argument to interrupt handlers.

-- 
Eric Norum                                 norume at aps.anl.gov
Advanced Photon Source                     Phone: (630) 252-2793
Argonne National Laboratory