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,
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:
 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()  , but can be different for
some other cases;
 rthal_irq_trampoline() [HAL]
the handler is defined as void (*handler)(unsigned irq, void *cookie);
this one normally does a simple thing, just calls xnintr_irq_handler()  as
you have mentioned before.
 xnintr_irq_handler() [nucleus]
this routine calls a certain user's ISR as well as handles some
nucleus-specific chores (re-scheduling, etc.)
 user's ISR [user driver]
does user-specific things
Well,  is necessary anyway since some nucleus-related chores must be done
and this is a correct layer for that (e.g.  knows nothing about
What can be theoretically merged is  +  (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
::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  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
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.
In our case, the relation between xnintr_irq_handler() and
rthal_irq_trampoline() is 1:1. The first one does much more things that the
second one which is really almost a pure redirection layer.
Hopefully, xnintr_irq_handler() is i-cache-hot as long as possible under high
irq load. In this case, I guess, rthal_irq_trampoline() will be in cache as
well (since it's really small) and the overhead is only about having one
array indexing op. and issuing a call via a pointer to the function
(xnintr_irq_handler() in our case).
Do you think that really gives a significant overhead? Well, maybe so. I'm not
a profie here anyway...
Xenomai-core mailing list