On Monday 31 October 2005 21:38, you wrote:
> > [...]
> > 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?
In that case, the nucleus must keep track of all the irqs, i.e. some_struct
irqs[IPIPE_NR_IRQS]. Ok, the rthal_realtime_irq may be removed here from
But there is already the per-irq array in ipipe_domain struct. Having got 
and  merged, we would have this array as the only one and avoid the use of
rthal_realtime_irq at all. Although, the ipipe_domain would become a bit
more heavy :) Well, but  into  is leeeess intrusive on the other hand.
> Philippe, I guess your wisdom is required here. Are we missing some
> important point in your design right now?
He would be glad you/we/someone else would come up with a worthy decision
(even if it's "keep it as is") without relying on the explanation of the
current design from his side.
Ok, the morning brings better solutions :o)