The eCos, QNX, ChorusOs irq handling API

[Sergei Organov]

Valette Eric <eric.valette at free.fr> writes:
> Sergei Organov wrote:
> 
[...]
> > 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,

So the driver API should be designed to manage it. As you correctly mentioned
yourself, IRQ is only one resource a driver may need, so putting a routine that
would handle cleanup of driver resources in IRQ API is just plain wrong. What
if a driver doesn't need IRQs at all?

Let's focus on IRQ API for now, OK?

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

Why? cyg_interrupt_mask(vector) will do.

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

A driver could break anything no matter if acknowledge is performed by the
generic layer or not. Anyway, if BSP writer decides to ack irqs in the generic
layer, he can make interface 'cyg_interrupt_acknowledge(vector)' routine to be
a no-op.

>          And while it seems necessary to acknowledge explicitely, there is
>          no API to mask the current IRQ at PIC level

I believe cyg_interrupt_mask()/cyg_interrupt_unmask() are exactly for this
purpose, so the rest of your sentence below makes no sense.

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

Anyway, it's up to BSP writer to select particular implementation. We are
talking about interfaces here.

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

Once again, the question is not if these routine provide all you've mentioned
in the above sentence. The question is why do you think they do this any better
than other approaches that cost less.

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

I'm trying to convince you that one can avoid the duplication using usual
routines. There is no reason to store pointers to routines and call them
through these pointers. It only increases the cost, not decreases it, I
believe.

>    One could mesure the data size of IRQ related data and code size on
>    Intel before and after the implementation of the new IRQ,

Did you?

>    data size and code size would have probably decreased and decreased the
>    more you have more handlers...

This could be the case only if previous code was rather bad, I'm afraid.

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

The code has to exist, but why it should be called through
p->on(irq_connect_data)/p->off(irq_connect_data) instead of
on(irq_number)/off(irq_number)? What's an advantage? 

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

Once again, where is advantage of
p->on(irq_connect_data)/p->off(irq_connect_data)
as compared to
on(irq_number)/off(irq_number)?

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

I can write them. I just still see no reason why addresses of these routines
should be passed to the interrupt attach code. And if they shouldn't be
passed, then their appearance (interface) would be different.

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

I wrote "approaches", not "approach", and I meant that none of the approaches
but youth uses on/off/isOn interface.

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

Once again, where is advantage of
p->on(irq_connect_data)/p->off(irq_connect_data)
as compared to
on(irq_number)/off(irq_number)?

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

My primary goal is to minimize overhead for really small systems. What I've
wrote and what I haven't has nothing to do with the issues we discuss.

-- 
Sergei.