The eCos, QNX, ChorusOs irq handling API

[Valette Eric]

Sergei Organov wrote:

> Anyway, the registration could be as simple as direct map between interrupt
> number and required function pointer(s), I think.

I would set a set of function pointers...

> BTW, couldn't all this [optionally] be handled using already proposed void*
> argument?

I do not thinks so the void* is a handle that contains data specific to 
the driver itself. It is not supposed to conatin at least required fields...


>>They cannot has there will be separate call to set the mask and restore it
>>later on. If you prevent any PIC access during this sequence, then you
>>cannot handle any other interrupts???
> 
> 
> So in your generic isr management code there is no such code? If so, why a
> driver will need such a code?

I do not follow you : the generic actual PPC and Ix86 code contains this 
seqeunce. No handler codes contains it. If handler codes contains this 
sequence they cannot be SMP safe without preventing interrupts to occurs 
on all processors during the complete sequence.

> 
> 
>>>>2) What if I want to mask a set of interrupt via a masks (as most moderm
>>>>  PIC implement it)?
>>>
>>>With this particular API it obviously requires multiple calls to the
>>>routine.
>>
>>>While I think it's rarely needed and thus multiple calls could be
>>>acceptable, I see two solution for this problem:
>>>1. Design API that accepts bit masks.
>>>2. Let BSPs provide specific optimized routines for more advanced hardware
>>>   management.
>>>I personally prefer (2).
>>
>>First I think applying bit masks is the only way to implement the notion of
>>IRQ priority on many PICs. Therefore applying masks is mandatory contrary to
>>what you suggest...
> 
> 
> If they are mandatory, they are mandatory only for those PICs. I thought we
> are talking about generic APIs here.

If generic API does not provide way to implement irq prorities, then 
most drivers will not use the generic API when they need such feature...

> 
> 
>>Now, the masks are totally PIC dependent and so even if you provide an API,
>>any usage inside a drivers will be surrounded by a zillion of ifdefs one for
>>each PIC... And also when there are cascaded hardware 5openPic + 8259, SIU
>>+CPM), there are several masks that should be applyied at diffrent time
>>isnide the handler routine...
> 
> 
> If there is no way to make a set of useful routines to simplify handling of
> such complicated architectures (or BSP writer is too lazy to carefully design
> the BSP), then BSP writer is still allowed to implement ISR handling the way
> you suggest -- I don't see any problem here.

I simply say that irq_mask (irq_set) is not implementable as a single 
function call because part of the mask should be set at different time 
of the interrupt processing.


> In fact no other interrupt will occur before RTEMS returns to an interrupted
> thread as I didn't even re-enable IRQs at processor level. I can't believe you
> don't know there are designs that don't use nested ISRs at all.

I'm jus saying that for such design, an API is superfluous.

-- eric