Re: [Xenomai-core] [rt shared irqs] changes on the adeos-ipipe layer v.2
er.. I was confused by the fact that sum of all apcs in /proc/xenomai/apc != virq from /proc/xenomai/irq, but ipipe_printk_virq is not listed since it's registered without rthal::apc interface. Ok, should take a look at it closer, i.e. maybe at least rthal_linux_irq can be reworked now.APCs are multiplexed on a single virq. Yep, I know. Don't know why but I thought that printk_flush is multiplexed on the same virq, OTOH it's an APC too. Well, the easiest argument against that could have been that the APC interface is implemented in the hal but printk_virq is registered in the ipipe, i.e. when there is no APC interface yet, mea culpa. --Philippe.-- Best regards,Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [rt shared irqs] changes on the adeos-ipipe layer v.2
er.. I was confused by the fact that sum of all apcs in /proc/xenomai/apc != virq from /proc/xenomai/irq, but ipipe_printk_virq is not listed since it's registered without rthal::apc interface. Ok, should take a look at it closer, i.e. maybe at least rthal_linux_irq can be reworked now.APCs are multiplexed on a single virq. Yep, I know. Don't know why but I thought that printk_flush is multiplexed on the same virq, OTOH it's an APC too. Well, the easiest argument against that could have been that the APC interface is implemented in the hal but printk_virq is registered in the ipipe, i.e. when there is no APC interface yet, mea culpa. --Philippe.-- Best regards,Dmitry Adamushko
