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

[Jan Kiszka <kiszka@domain.hid>]

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

Dmitry Adamushko wrote:
> On Tuesday 01 November 2005 12:58, you wrote:
> 
>>> 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.
>>
> 
> If we only want to get rid of the trampoline-thing then [2] + [3] would work 
> out (btw, I have sent a message this morning where I tried to provide even 
> some pseudo-code :) 
> 
> But if we want to (think that we may) gain the adventage of having a more 
> flexible irq-related support from the ipipe layer, then yep, those changes 
> might look worthy. I thought that this way, we would even get rid of another 
> per-irq (rthal_realtime_irq) array in hal/generic.c, maybe even from 
> rthal_linux_irq too. The sole one is provided by the ipipe_domain structure 
> and a set of generic interfaces e.g. via system.h so that the HAL or another 
> layer may get access of it.
> 
> e.g.
> 
> the "cookie" remains opaque for the ipipe but when requested by 
> HAL::rthal_irq_request() or NUCLEUS::xnintr_irq_handler() it's treated as a 
> chain of ISR handlers.
> 

Yep, that's also what I had in mind about potential ipipe changes and
their use in the nucleus.

Jan



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