Dmitry Adamushko wrote: > 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 > hal. > 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.
Due to the intrusiveness, I would vote for a -> merge. One issue remains in any case: the HAL currently maintains a /proc entry for the registered IRQs. It reports if a handler is registered and the IRQ hits per CPU. As I think this entry should also report the registered driver names in the future, we have to hand the management over to whatever part traces all registered handlers. Is this acceptable from the layering point of view? Jan
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core