How to mask IRQ

Thomas Doerfler Thomas.Doerfler at
Tue May 31 17:34:11 UTC 2005


I had a look into the mbx8xx BSP irq handler code as an example. At a
first glance I would say, that no API extension would be needed to
achive your functionality, but the current implementation would need
some modifications.

You already have the two calls:

int BSP_install_rtems_irq_handler  (const rtems_irq_connect_data* irq);
int BSP_remove_rtems_irq_handler  (const rtems_irq_connect_data* irq);


int BSP_get_current_rtems_irq_handler	(rtems_irq_connect_data* irq);

Currently, I think, it is not yet safe to call
"BSP_remove_rtems_irq_handler" from an ISR, but I think with some
careful tinkering it could be made safe.

Would this be ok for your requirements?


leonp at schrieb:
> On Tuesday, 31 בMay 2005 16:17, Thomas Doerfler wrote:

>>I think the initial request from Leon should be considered, to extend
>>the "new exception processing" API with some means to disable/enable
>>certain interrupt controller inputs either from application level (well,
>>we already have that, I think) or from within an interrupt handler. IMHO
>> it would be nice if any interrupt handler can enable/disable the
>>request input of any other interrupt source, therefore I would recommend
>>not to use a special return value to manage this, but function calls to
>>manage this.
>>Any comments?
> I also think in your stream. And I also should like to have some API function 
> to do this. The only reason that I suggested the return code is, that 
> functions will require intermediate variable, which in turn requires very 
> carefull attitude as it may be changed/restored in two nested calls, while 
> the return value seems to be simple and safe.
> Thanks.

IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler           Herbststrasse 8
D-82178 Puchheim          Germany
email:    Thomas.Doerfler at
PGP public key available at:

More information about the users mailing list