> 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 This corresponds to what I have understood of what happens when a rt-thread makes an excursion to the the non-RT world. So there may be truth in what you say. Only, what I then don't understand is this: There is no problem with the non-RT-ISR doing its thing under normal (read no IRQ sharing) circumstances. So I would not see why passing the IRQ to the non-RT-ISR once the RT-ISR has done its job would be any different to the situation where there is no sharing. The situation is IMHO not analogous to the "excursion" of a RT thread into non-rt world as would be the case for example if a rt-thread called a non-rt-safe driver. IOW passing on an IRQ does not imply that a rt-thread steps into non-rt world. Rather it jsut gives the non-RT world the opportunity to respond to its devices as it would have naturally done without a problem when it gets its IRQ outside xenomai's realm. I assume (due to the fact that the rt-monitored IRQ's can be found in /proc/xenomai/irq IIRC) that the rest of the IRQ's are not filtered/censured through adeos.
Maybe the explanation is as follows: There is no problem to the point where the nonRT-ISR gets and responds to the IRQ. But what happens if ,during the execution of the non-RT-ISR after it has been passed the IRQ, the RTdevice evokes another IRQ? Then adeos must give this IRQ to the RT-ISR and give it precedence over the Non-RT-ISR. If the non-RT-ISR is atomic or non-pre-emptible (not sure that is not the same thing or that I am not talking out of my hat here) this might be a problem. But again I would not see why this is then not a problem under the aforementioned "normal" circumstances. So I remain confused. Roland. > 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. > > :) > > -Rob > > > _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
