On Thu, Dec 11, 2014 at 03:47:36PM +0000, Stoidner, Christoph wrote:
>
> > 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.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
