ISR Argument Proposal Request

[Till Straumann]

Eric Norum wrote:
> 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*)).

Just an implementation detail: you could also think of the table being 
an array of pointers:

typedef struct {
     void   (*hdl)(ISRArg *parg);
     ISRArg  *arg;
     /* more items as needed by the API */
} ConnectDataRec, *ConnectData;

ConnectData isrTable[NUM_VECTORS] = {0,};

ISR installation would then allocate a structure and attach it to the
correspondent vector's table slot. On many architectures, the
extra deref step needed is not more expensive (if not cheaper) than
the 'vector * sizeof(ConnectDataRec)' computation needed accessing
a table of structs. OTOH, the dispatcher would have to perform an 
additional NULL pointer check

( if (isrTable[vec] && isrTable[vec]->hdl)
       isrTbl[vec]->hdl(isrTbl[vec]->arg); )

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

I repeat my mantra here: providing the arg is so cheap (space + runtime)
that the efforts of maintaining #ifdef branches is not justified.

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

Great :-)

-- Till

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