Jan Kiszka 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,
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
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
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...
...compared to the usefulness I still have to understand - yes.
Other option: what about merging  into , i.e. let
xnintr_irq_handler deal with the translation IRQ number -> cookie?
That's an option, yes. The other one being to teach Adeos to pass an additional
cookie, but in such a case, only the i-pipe series would be upgraded to allow
that, which would be a bit rude to people still currently relying on the legacy
oldgen patches for running Xenomai. This said, at some point in time, upgrading
will be necessary though.
Philippe, I guess your wisdom is required here. Are we missing some
important point in your design right now?
Mmm, for the wisdom thing, please see there:
For the design issue, I agree that the initial trampoline is just a waste of
cache lines and cycles. The only thing to keep in mind is to preserve a sensible
layering so that the whole thing is still able to run over the event-driven
simulation engine we have, but AFAICS, fixing the xnarch layer everywhere would
Xenomai-core mailing list