The eCos, QNX, ChorusOs irq handling API

[Valette Eric]

Sergei Organov wrote:

> That's a wrong reference, IMHO. Unlike eCos, RTEMS doesn't have special API
> for device drivers, so here is a better reference (besides, it points to the
> latest docs, not 2 years old ;-):
> 
> <http://sources.redhat.com/ecos/docs-latest/ref/ecos-ref.9.html#pgfId=1088792>


Thanks for pointing to the right document...

> The API seems to be complete and rather simple. Overall, that's roughly what
> I'd like to see in the RTEMS.

The APi is not simple I think and also not complete :

	1) While there is a way to get the previous handler for an irq (meaning 
you intend to replace it dynamically), there is no way to notify the 
previous driver to clean up the ressources it may have allocated to 
handle the interrupts (e.g tasks, memory, ...). Handled by irqOff 
routine calling is my API. If you think anyway the driver should 
coordinate, I would answer that for profiling or irq couting it is not 
necessary,
	2) There is no way for code outside a driver to stop interrupt for a 
while and then reenable them without having knowledge of all the 
devices. This type of functionnality is necessary for profilling, system 
debuggers, irq monitoring,
	3) not acknowledging the irq by generic layer means that a driver can 
break any form of irq priorities if the PIC must be acknowledged before 
issuing the next interrupt. And while it seems necessary to acknowledge 
explicitely, there is no API to mask the current IRQ at PIC level 
meaning that either you will have to also perform PIC manipulation 
before acknowledging the PIC to re-enable others interrupt without 
acessing the real harware as the hardware that caused the interrupt may 
still assert a high level for the Interrupt line. For me this clearly 
means a very fine way to increase the IRQ latency because of a bogus API,

Also relying on that is very dangerous as it is not SMP safe or can be 
broken by some kind of NMI handling,
	4) I do not see ways to share interrupts

> It seems that the next logical step is to remove on and off routines as well
> :-)

No. This wrong. Theses routines provides portability, enable advanced 
code to manipulate the hardware wthout knowing the details with very 
little cost.


1) Concerning the cost : it adds NB IRQ * sizeof word* 2 words. But 
avoid the duplication of the very same code in each handler to 
manipulate the PIC masks. One could mesure the data size of IRQ related 
data and code size on Intel before and after the implementation of the 
new IRQ, data size and code size would have probably decreased and 
decreased the more you have more handlers...


2) The code corresponding to the On/Off routine has to exist anyway as 
you need to program the hardware... It indeed force you need to cleanly 
isolate it, and export it so that other part of the code can use it,

3) May be usefull to other part of the system than the driver itself to 
disable the interrupt (e.g benchmark routine that disable all other IRQ 
but the current one, debugger that only enable the devices it use for 
inputs,  other drivers that hooks to do profilling and need to reenable 
the interrupts, ...). On sophisticated system, or system with a lot of 
already written drivers, you cannot assume you have the knowledge of 
each devices.

4)If really for some reasons you cannot write the On/Off routine, 
passing nop function brings you exactly to API you suggest.


> You definitely are free to follow whoever you wish, but I'd not adopt it for
> RTEMS interface unless you clearly explain what are the advantages of this
> on/off/isOn interface complication compared to the approaches the rest of the
> world takes. 

There is no approach the rest of the world takes as there is as many IRQ 
API as RTOS.

Now, I have provided you for hints of On/Off usage. Could you explain me 
how you intend to implement what I suggested (dynamic replacement of 
drivers, selective disabling of irq by code that has no hardware 
knowledge like profiling, debuggers) without having them? Or maybe you 
do not care because anyway you never wrote a system that can dynamically 
replace drivers and use expansive hardware to perform system debugging 
via jtag?


-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette at free.fr