Re: [Xenomai-help] [RTnet-users] RTNet in non-TDMA mode?

[Roland Tollenaar <rwatollenaar@domain.hid>]

>     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
> 
>  
>