> 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? Regards, Christoph _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
