Robert Gubler wrote: > On 10/27/07, Roland Tollenaar <[EMAIL PROTECTED]> wrote: >> Hi Rob, >> >> Thanks for this response. >> >>> But my question remains -purely out of interest- why non-rt devices >> and >>> rt devices can _fundamentally_ not share an IRQ? >>> >>> >>> >>> My understanding is adeos-ipipe/xenomai provide an interrupt abstraction >>> layer underneath Linux. If there is more than one consumer of an >>> interrupt it has to be copied/forwarded to all those that need it. If >>> an IRQ is shared with an RT application, and the Linux kernel I would >>> imagine this would create some level of indeterministic RT software. > > > IRQs are incoming (to the kernel/CPU) signals IIUC. I imagine that at >> the end of these incoming IRQ's sit ISRs just waiting for IRQ and ready >> to respond to it in whatever manner they usually do. If this >> understanding is correct (which it probably is not) then I would not be >> able to conceive of a reason why the IRQ could not be passed on to the >> NON RT interrupt service routine after it has been handled by the >> RT-ISR. But I reiterate that my understanding of these things is as >> sketchy as my interest to improve the sketchiness is big. :) > > > I think the problem is once the RT-ISR passes it to the NON-RT ISR there > are no real guarantees for how long Linux (its device driver, most likely) > will hold on to the interrupt. This is problematic if it is causing > scheduling deadlines to be missed. Its probably not an issue with shared > interrupts between multiple RT applications because (1) the RT apps using it > are (hopefully) written with understanding it is in a real-time context; > this is good peace of mind. And (2) there is probably some fancy interrupt > masking or priority going on between RT-shared interrupts that make it more > deterministic. > > And now for the obligatory I-don't-really-know-what-I'm-talking-about > disclaimer again: > > I am new to these packages, so hopefully I am not providing misinformation > on its functionality. > > :)
You're providing very accurate explanations in fact! And if you or Roland things have the impression that the related FAQ entry on xenomai.org is not the clear, please enhance it! One further note on why it is hard to handle cross-domain-shared IRQs: For the non-RT user, you always need a minimal (and, of course, deterministic) IRQ handling stub in the RT domain that shut ups the IRQ at device level and then forward it for later handling to the non-RT domain. We a) have no really smart way for forwarding the IRQ at the moment (*) and we b) would then still have to maintain those hardware-specific stubs, which we cannot do for each and every Linux driver out there. Jan (*) You currently need an additional virtual IRQ. Reusing the Adeos pipeline with the same IRQ line is a yet unimplemented idea of mine for a smarter alternative.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
