>> > Ok, maybe we have some hope with the tracer though. What should >> > trigger a trace is the fact that a relax request has been sent, but >> > that the next linux scheduling point does not wake up the said task. >> > This is all debug code, so it does not need to be clean. You can >> > define a per-cpu variable (if running on SMP systems, otherwise a >> > global variable will do) with the last request posted. And when a >> > linux scheduling happens, test that the newly scheduled task is the >> > task that was passed to the relax, if that is not the case, trigger >> > a trace freeze. The point where the nucleus is informed of a Linux >> > task switch is do_schedule_event(). The trick is that if you have >> > some tasks with a higher priority than the relaxed task, it is >> > normal that the relaxed task is not scheduled immediately, so if you >> > want the condition to hold, you need to run the xenomai tasks which >> > relax with the highest priority. Also, obviously, after the test, >> > the pointer should be reset to NULL, because there are several task >> > queued, and with a global variable you have no way of knowing which >> > is next. >> >> I will do so. Do I have to change the gatekeeper's priority behind the >> relaxing >> task to assure that the gatekeeper would be scheduled before? > > The gatekeeper is not involved.
Sorry, I wanted to say: "that gatekeeper would NOT be scheduled before?". Otherwise we see possibly the gatekeeper instead of the relaxed task? Or am I wrong? Regards, Christoph _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
