The eCos, QNX, ChorusOs irq handling API

[Valette Eric]

Valette Eric wrote:

> 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

I forgot : no provision for defining priorities among interrupts ...


-- eric