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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
