The eCos, QNX, ChorusOs irq handling API

[Valette Eric]

Sergei Organov wrote:
> 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. 

How does the eCos API manage it which is my point?

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

What I say is that an API that enables to disconnect a handler should 
have provision for a callBack to call the initial driver code, and also 
ask it politely to shut down the interrupt the way he wants... I do 
still think irqOff could be used for that purpose...


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

1) If tasks start manipulating the PIC because you expose this API, and 
are prempted by other tasks performing the same thing vevrything will be 
rapidly broken (To not even mention SMP problems with this API). You 
better disable the real cause of the interrupt (device) because the PIC 
are shared among all interrupts while the device is not.

2) What if I want to mask a set of interrupt via a masks (as most moderm 
PIC implement it)?

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

So each driver will then have to include the sequence :
	1) Get the current mask
	2) Apply a new mask than at least mask the current IRQ. BTW sometimes 
you want to mask more than one IRQ source so the proposed eCos API is 
not sufficient
	3) send an EOI
	4) reenable IRQ a processor level
	5) handle the hardware
	6) restore the original mask

Great. Do you think It cannot be factorized as already done on Ix86 and 
PPC? And do you really think you can avoid this sequence?

I would like to point out that any primitive that handle PIC masks 
called into an IRQ handler will prevent it to be SMP safe... Who care of 
SMP support? At least I do especially whem I'm designing a new API.

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

But wrong interface prevent to easilly write correct code :-) Never let 
the handler manage the PIC or average driver writer will make mistakes 
that will break the whole system... Managing the PICs means that any 
driver as an open door to harm other drivers. In the current ix86 and 
PPC code, the handler do not manipulate PIC and therefore the code is 
simpler to write : you do not need to read the PIC manual before 
actually starting to handle the hardware you really want to mange. Did 
you read the SIU/CPM manual, the OpenPIC specs, the 8259 manual? I did 
but if I can avoid driver writer to read it, I'm quite satisfied.

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

Code size for each handler is increased by sveral instructions so 
globally you increase the code size while making the writing of handler 
more difficult...

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

No but I though about it when designing it and I do say as author it 
reduced the size because each irq handler had the PIC manipulation 
sequence mentionned above... Prove me I'm wrong :-)

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

Frankly why are you pissing me of for such detail? irq_connect_data 
contains the relevant 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.

Again the cost is minimal : NB IRQ*sizeof word*2 and as pointed out, as 
all PIC manipulation is done by generic layer is remove code that needs 
to be writen in each handler... And more important is facilitate 
implementation of more sophisticated services like system debugging, irq 
monitoring, ...


-- 
    __
   /  `                   	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