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

[Joel Sherrill]

Till Straumann wrote:
> 
> 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.)

No arguments from me on any of those.

> 7) Provide an abstraction layer/framework for PICs, so PIC drivers can
>     be re-used on different BSPs.

This may be a restatement of (7) but I want to make sure that we don't
end
up with implementations which duplicate the complex code required to
accept
an ISR and save state.  Although not perfect, the mips model which is to 
have an outer portion save state and then call the BSP or CPU model
specific PIC handler that actually vectors the handler to avoid 
duplication of complex code like has happened on the PowerPC.  It is
difficult
to maintain.

I wouldn't mind seeing the implementation either call the PIC vectoring
code as a subroutine or be broken into "prologue" and "epilogue" files
which
are concatenated with a "PIC vectoring" file to do the BSP/PIC specific 
dirty work.

I know it is an implementation detail but I don't like duplication and 
I especially don't like duplicating code like the ISR handling code. 
I am sure Till is tired of looking at all the various versions of the
same PPC assembly code by now. :)

And don't forget, we have an ARM volunteer as well.

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

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