[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




Sergei Organov wrote:
> 
> 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.

No.  I just missed the application perspective. 

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

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