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

[Sergei Organov]

Joel Sherrill <joel.sherrill at OARcorp.com> writes:
> 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.

I agree with your comments but they don't contradict with my list ;-)

I've intentionally built the list from the point of view of applications *I
care about* as I think that is what Till have asked us to do. Please note how
priority jumps at one point in the list. The applications I care about don't
use the features starting from (250) and I doubt they ever will -- thus low
priorities. If I were asked to build a list from the point of view of an RTEMS
designer, I'd change the priorities in the list significantly.

The resulting list is useless alone, but I believe Till will be able to
effectively merge lists got from different people to get to the most optimal
solution.

I'm sorry if initial lack of explanations caused a confusion.

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

Also totally agree.

-- 
Sergei.