The eCos, QNX, ChorusOs irq handling API

[Joel Sherrill]

Valette Eric wrote:
> 
> 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...

Eric's right on this one.  Managing the processor's view of interrupt
enable/disable on a per thread basis is independent of any interrupt
installation or PIC handling.

I really do believe that an API with a core of basic interrupt 
services that are CPU independent is possible and useful.  This
is not to say that there might be a 2nd tier of the API that 
only a subset of systems support.  Or that an "ISR handler"
structure might have required and optional fields.  But having
a common base level of services is good.

I think Till is about ready to drop a more proposal on us so
it would be unfair to say much until we all review it.

> --
>     __
>    /  `                         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

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985