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



Eric.

OK. I believe this is a much better way to continue.
I'd like as many people as possible state their desired requirements
for the new IRQ API like Eric did below.

Please, don't comment on Eric's requirements but just list
your own requirements in a prioritized order. Once I have an idea
of the spectrum of requirements, I can come up with a proposal
which can then be commented on.

Keep your postings to this thread short, please. Again, I'd like
to see wishlists on this thread, NOT a discussion.

Thanks
-- Till

PS: my own list is very similar to Eric's but differs in some points:


0) short interrupt latency (Eric's 1.).
1) The generic core of the new API must be supported by ALL BSPs
2) easy to use for driver writers. PIC/EOI should be hidden from
    the driver writer (Eric's 2.).
3) API must provide for a user argument being passed to ISR
4) API spec should define the state the BSP must provide to the user
    ISR (Eric's 3.).
5) API provides a call to selectively enable/disable a interrupt
    line (Eric's 5.).
6) Interrupt line properties (priority, level, ...) should be
    configurable (Eric's 2.)
7) Provide an abstraction layer/framework for PICs, so PIC drivers can
    be re-used on different BSPs.

Valette Eric wrote:

> Till, I have requested this several times and most of this rather 
> lenghty technical, flame prone discussions would not have existed if the 
> requirement has been expressed from the beginning. Just to clean up in 
> front of my door :  I expressed the requirement when designing the new 
> API in 98. The irq.h does even still contain many rationale for the API. 
> Now, as ever, it can be enhanced but at least take time to see the 
> merits of the current implementation before reinventing the wheel.
> 
> If we do not take a methodological approach for making the job, I will 
> simply shut up and let you guys do the work and latter support it. I 
> have indeed provided support for my API for 5 years :-) And anyway, 
> whatever you define, I'm able to recode my own implementation without 
> needing help.
> 
> PS : my own set of requirements by importance order :
> 
>     0) Interrupt latency should be keep to minimal and should not rely 
> on *each* handler to perform specific actions (e.g EOI),
>     1) There should be a way to mask a set of interrupt when a 
> particular interrupt occurs) via a BSP dependent and *reconfigurable* 
> means. Individual IRQ priorities having no meaning on most processor (e. 
> Intel, PPC, ARM), a table defining priorities one way or other should be 
> used. This table can be static (as on PPC) or better dynamic as on Intel,
>     2) It should be as simple as possible to write drivers and in 
> particular, it should not require knowledge of anything except the 
> target hardware itself and its memory/IO mapping (understand I do not 
> want to have to know about the PIC's specificities)
>     3) API documentation should clearly define in what state the handler 
> is called (what should have been done by the BSP generic irq code before 
> the handler is called) and what primitive a ISR handler is allowed to 
> call. In particular we must define what has been done on warious PICs 
> and what has to be performed by the handler itself,
>     4) We have a strategy concerning interrupt sharing. The hability to 
> get the previous handler connected is implemented as the minimalistic 
> way of sharing...
>     5) The API, should provide a mean for generic code to mask selective 
> IRQ without knowing the detail of the hardware,
>     6) disconnecting a handler should call a callback routine inside 
> initial driver code,
> 
> -- eric
> 
> 
> 
>