RFC: new RTEMS IRQ requirements (was: The eCos, QNX, ChorusOs irq handling API)

[Joel Sherrill]

Sergei Organov wrote:
> 
> Here is my list of requirements. The numbers in brackets are priorities (0 is
> the highest).
> 
> 1.  (0)   ISR attach.
> 2.  (1)   Interrupt line enable/disable.
> 3.  (2)   Small IRQ management overhead.
> 4.  (2)   Short ISR latency.
> 5.  (3)   Specification of the state the user ISR is invoked at.
> 6.  (4)   IRQ ID and/or user argument being passed to user ISR.
> 7.  (5)   Universal IRQ ID (or call it "vector" or "symbolic name").
> 8.  (250) ISR detach.
> 9.  (251) Interrupt priorities management.
> 10. (252) Ability to implement drivers in a BSP-independent manner.
> 11. (253) Ability to implement re-usable [P]IC managers.
> 12. (254) IRQ ID being passed to user ISR separately from user argument.

I think your requirement 10 is more important than you are giving it
credit for.  Reusing device drivers across BSPs and CPU families is
important to reducing the effort required to build new BSPs and to
reduce maintainenance for RTEMS as a whole.  The performance is the
libchip drivers is better than you might expect.  The DEC driver in
particular has been compared on both x86 and PowerPC targets to other
OSes on the same hardware and always performs near the hardware limits.

There are other approaches to BSP independent device drivers but the
bottom line is that every time someone duplicates code to manage a 
particular chip, the maintenance goes up, risk of bugs being duplicated
goes up, and the pain of making enhancements across the board goes up.

> --
> Sergei.

-- 
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