The eCos, QNX, ChorusOs irq handling API => resent message has been trcunacted due to a linux crash

[gregory.menke at gsfc.nasa.gov]

Valette Eric writes:
 > So I propose to do the following :
 > 
 > 	1) Express a first set of requirements with the help of the maximum users,
 > 	2) Clean them up via pondering priorities,
 > 	3) Propose only then an API,
 > 	4) See how the API does fullfill the requirements,. If we find 
 > impossibilities, then either remove the requirement, let is open to BSP 
 > specific implementations, and at least clerly document the limitation of 
 > the API,
 > 	5) Check that the proposed API is at least implementable on mpc8XX, 
 > Intel, motorola shared and 68K and MIPS as we have people ready to test it,

I think this is the right approach.

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

And I'll add that if whatever the api ends up being is wonderful and
complete, yet is too much more complicated than the existing PPC
interrupt handling, I don't think we will have improved much- and I
for one won't be highly motivated to retrofit it onto our slow MIPS
platform.

I'll augment Eric's requirements with mine;

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

- This is of top importance for me.  I'll also add that the latency
  variablity should be kept as small as possible.

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

- An interrupt priority table is important for us.  Right now the MIPS
  bsp's will have to code their own isr vectoring routine, which is a
  very miserable approach to arranging priorities.  Our interrupts
  tend to be fixed once defined, so dynamic features aren't as
  important.

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

- This is not of prime importance for us, but we don't do high-level
  drivers either.  Our isr's tend to be directly associated with
  particular gizmos whos interrupt re-arming is something special in
  any case.

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

- I think this is critical if we're implementing something like an
  abstract isr/exception handling scheme.


 >      4) We have a strategy concerning interrupt sharing. The hability to 
 > get the previous handler connected is implemented as the minimalistic 
 > way of sharing...

- We don't use sharing, but I think reasonably supporting it is
  essential.  Once stuff like USB drivers start showing up in RTEMS,
  this will be very handy.

 >      5) The API, should provide a mean for generic code to mask 
 > selective IRQ without knowing the detail of the hardware,

- We wouldn't use this much, but I could see how its useful- and
  maintaining an abstract interface to hardware as obnoxious as PIC's
  tend to be will be extremely helpful.

 >      6) disconnecting a handler should call a callback routine inside 
 > initial driver code,

- I think this will be useful in future.


If I had to choose 3 requirements I most need they would be;

- Minimal and consistent latency
- Interrupt priority table (at least static, preferably dynamic)
- Interrupt sharing (via some kind of isr chaining feature)

and would list the rest as desirable.


Gregm