The eCos, QNX, ChorusOs irq handling API

[Valette Eric]

Till Straumann wrote:
>
>> But the section is usually  


> 
> 
> LOCK(pic)
	-1) Get current PIC Masks. Store it on the stack
>       0) Mask this vector's bit
> 
>>     1) Mask other lower priority interrupts by mapipulating PIC     masks
> 
> UNLOCK(pic)
> 
>>     2) execute the handler,
> 
> LOCK(pic)
> 
>>     3) Restore original pic masks

That is why I have added the -1)
> 
> UNLOCK(pic)
> 
>>
>> This cannot be guaranteed to be *ALWAYS* short...
>>
> 
> No, but you'd only mutex steps 1 and 3 individually (I've added
> the LOCK/UNLOCKs above). If the only
> permitted action for the handler is re-enabling its own vector,
> or the priorities below itself (the only thing that probably makes 
> sense) everything is fine (otherwise, the PIC driver has to manage
> a stack of masks tracking the ISR nesting level).
> Of course, the handler has to use an API
> call to do that it's not manipulating the PIC directly.

But my point is that if on a second proc sharing the PIC, you execute 
the same sequence but starting at stage 2) of the sequence on the first 
proc, because the interrupt is not currently masked, even with tyhe 
locks you will end up restoring a PIC value that is wrong because some 
interrupt will remain masked. Or did I miss something?

> It _is_ done immediately: by the Universe hardware - beyond software 
> control :-)

Great. BTW you did not answer about the possibility to mask the current 
opepnpic irq via a mask and issue the openpic acknowledge ASAP. I 
have'nt OPENPIC doc anymore but from memory I did not find means to do 
it. Maybe worth investaigating because as you pointed out, the code is 
suboptimal. You cannot find agains broken hardware API :-)

-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette at free.fr