Re: [Xenomai-core] [RFC] support for sharing IRQs

[Jan Kiszka <kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 3612 bytes --]

Philippe Gerum wrote:
> Dmitry Adamushko wrote:
>> On Monday 31 October 2005 16:04, you wrote:
>>
>>> Dmitry Adamushko wrote:
>>>
>>>> It seems to me now, that some parts of the hal will be involved
>>>> (rthal_irq_request/release()) since the nucleus itself doesn't keep
>>>> track
>>>> of registered irqs.
>>>
>>> That's true. And it also raises another question to me: why do we have
>>> those two different IRQ models?
>>>
>>> The HAL only one handler per IRQ which get called with the triggering
>>> IRQ number. That handler will call the nucleus with an attached cookie.
>>> And on the other side is the nucleus which works with a xnintr_t per
>>> IRQ. The xnintr_irq_handler() deals with things like re-enabling IRQs,
>>> rescheduling, etc.
>>>
>>> I'm asking as this abstraction adds one trampoline call (at HAL level),
>>> thus may lead to more I-cache misses. Isn't it worth considering some
>>> HAL mechanisms based on more #defines and static inlines in this regard?
>>
>>
>> Let's take a look at what we have got currently:
>>
>> [1]     ipipe_domain::irqs[IPIPE_NR_IRQS]    [ADEOS-IPIPE]
>>
>> the handler is defined as void (*handler)(unsigned irq);
>>
>> in our case, this is rthal_irq_trampoline() [2] , but can be different
>> for some other cases;
>>
>> [2]     rthal_irq_trampoline()                [HAL]
>>
>> struct rthal_realtime_irq[IPIPE_NR_IRQS]
>>
>> the handler is defined as void (*handler)(unsigned irq, void *cookie);
>>
>> this one normally does a simple thing, just calls xnintr_irq_handler()
>> [3] as you have mentioned before.
>>
>> [3]     xnintr_irq_handler()                [nucleus]
>>  
>> this routine calls a certain user's ISR as well as handles some
>> nucleus-specific chores (re-scheduling, etc.)
>>
>> [4]    user's ISR                        [user driver]
>>
>> does user-specific things
>>
>> Well, [3] is necessary anyway since some nucleus-related chores must
>> be done and this is a correct layer for that (e.g. [2] knows nothing
>> about scheduling).
>>
>> What can be theoretically merged is [1] + [2] (errr... I said
>> theoretically, it's still not the case to kill me for just having said
>> that :o). To this end, ipipe_domain should be extended in order to
>> contain all the fields of [2]::struct rthal_realtime_irq (at least,
>> handler(irq, cookie) + cookie).
>> btw, ipipe_domain::irqs may even contain a pointer to the slightly
>> modified
> 
> This would mean changing a core Adeos prototype, though.
> 
> xnintr_t structure (which is really e.g. a circular list) that may be
> passed
>> as "cockie" to the xnintr_irq_handler().
>>
>> The analogy is irq_desc_t vs. irqaction structures in Linux.
>>
>> This way, xnintr_irq_handler() can be called from adeos-ipipe layer
>> directly without the [2] layer.
>>
>> But that change looks quite invasive to me so far since
>> ipipe_domain::irqs::handler(irq - with a single parameter) is used all
>> over the map.
>>
> 
> I'd really prefer making one invasive change early in the process of
> addressing the issue than several kludges later to work around
> structural shortcomings, so no problem, go wild, I'm all ears.
> 

Oh, we have green light for some /real/ changes! ;)

Well, one advantage of a cookie inside the ipipe patch is that also the
data locality would increase, especially for the trivial case of only
one handler being installed. Then we would be able to handle down the
user's xnintr_t structure, and that one would already make it into the
caches by adeos traversing the pipe...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]