The eCos, QNX, ChorusOs irq handling API

[gregory.menke at gsfc.nasa.gov]

Valette Eric writes:
 > gregory.menke at gsfc.nasa.gov wrote:
 > 
 > > I would prefer to keep the semantics of setting a vector and then
 > > allowing the interrupt itself to be disabled- the RTEMS task interrupt
 > > level provides a means of controlling the set of enabled interrupts on
 > > a per task basis.  Its not been useful to me yet, but I'd hate to
 > > loose functionality in an enhancement.
 > 
 > I'm not sure I understand what you mean. If processor IRQ enabling level 
 > is part of a SR and saved as part of the context switch, fine. However, 
 > allowing such things, makes it very difficult to guaranty any interrupt 
 > latency... Besides, I do not see what in the current new API prevents 
 > that...
 > 

It sounds like I may have misinterpreted your statement above.  I was
interpolating the "disabled irq" to be analagous to the interrupt
level as applied to the MIPS, which is done via SR as you suggest.  If
you don't see a conflict, I have no problems...

Gregm