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.


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.

Best regards,

Xenomai-core mailing list

Reply via email to