Hi, I happened to be confused about signaling a semaphore in an interrupt handler, like doing rt_mark_stack_mgr in any ethernet driver of RTnet.
Will the interrupt handler be preempted by the task waken up from the semaphore waiting queue? To make it clear, I added rtos_print("A") before the rt_mark_stack_mgr and rtos_print("B") after, and rtos_print("C") in the do_stacktask(). The result turns out to be A, C, B. So the interrupt handler is preempted, which is not as I expected. For this, I would like to know your idea.
Well, this is indeed "correct". It is a rather untypical behaviour of RTAI compared to other OSes, which is kept until today for compatibility reasons. Nowadays, there is some switch in the RTAI configuration to avoid this IRQ handler preemption (don't know its name by now), but it is turned off by default.
As RTnet wants to be compatible with many RTAI version, we are still working around this in the drivers by first collecting all events (incoming packets) and finally reporting them once per IRQ to the stack manager.
BTW, My colleague student said, it is possible to give the interrupt a high
priority, higher than the real-time task, so it will not get preempted. Is
that true?
Yep, that's what the I-forgot-its-name switch is for.
For the Firewire, I have build the rtos_tasklet_scheduler, which runs the
linux tasklet in a real-time way. So this is useful in the case of Firewire.
The idea is same as the stack manager. But since the Firewire should be
connected to RTnet, which means the rtos_tasklet_scheduler and the stack
manager should coexist, they need different priorities. I think the
priority of rtos_tasklet_scheduler should be higher. Then the question again
comes out: shall the rtos_tasklet_scheduler be preemptable? If not, how to
prevent that?
So, the data flow looks like this
FW-IRQ (incoming data) -> RT-tasklet -> stack manager -> application
or like this
FW-IRQ -> RT-tasklet -> application?
Does the tasklet scheduler use a RTAI task in the background? Or does it work like a Linux bottom-half?
I cannot tell you yet what priority your tasklets should have. You are more into Firewire to assess if there is some critical work to do which is more urgent than any stack manager activity. If in doubt, make everything configurable ;) (not a professional advice, I know).
Currently, I am working on porting the eth1394 module to RTnet. The eth1394
has its own header building functions, like hard_header, rebuild_header,
etc, which may slightly increase the workload for porting. Hopefully, I can
run the first rtping on Firewire before this weekend-:). Btw, I think RTnet
only uses the hard_header, why other header functions, like rebuild_header,
hard_header_cache, etc, are not important?
This functions optimise ARP packet exchanges - something which typically happens only once on an RTnet node (ARP is static here). Furthermore, RTnet has its own optimisations for handling hw addresses. Does the code you port USE that extra functions anywhere? RTnet does definitely not, so you may simply drop the related code.
Looking forward to hear your "ping" soon! ;)
Jan
smime.p7s
Description: S/MIME Cryptographic Signature
