The eCos, QNX, ChorusOs irq handling API

[Till Straumann]

Valette Eric wrote:
> till wrote:
> 


-- snip --

> 
>> Sure, but if you have to manipulate the masks you have to assert 
>> mutual exclusion
>> which means that you cannot handle interrupts (that critical section 
>> better be short).
> 
> 
> But the section is usually  

LOCK(pic)
       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
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.

-- snip --


>> Of course, bitmask manipulation (i.e. 'disable(vector)' / 
>> 'enable(vector)') has to be SMP safe.
>> BTW: one example of a driver who needs to do that is the tundra 
>> universe PCI-VME bridge.
>> It encorporates a "PIC" itself and hence wants to re-enable it's PCI 
>> IRQ at the OpenPIC ASAP
>> (to support VME interrupt priorities in software)
> 
> 
> Yes same for ISA inetrrupt. Browsing the code to answer greg question I 
> was wondering why you did not acknloledge the VME request immediately as 
> I have done on ISA :-)
> 

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

-- Till