Jan Kiszka <[email protected]> writes:
> On 08.07.21 12:09, Philippe Gerum wrote: >> >> Jan Kiszka via Xenomai <[email protected]> writes: >> >>> On 08.07.21 11:51, Richard Weinberger wrote: >>>> On Thu, Jul 8, 2021 at 11:25 AM Jan Kiszka <[email protected]> wrote: >>>>> The general philosophy of Xenomai is that applications should not rely >>>>> on the exact switching behavior. So the question would be why your >>>>> application needs one or the other behavior? >>>> >>>> In this particular case the application uses the ioctl() system call >>>> to call into a >>>> xenomai kernel module. The module implements the rt and nrt variant of >>>> ioctl() and >>>> the application assumes which version of the ioctl() implementation >>>> will get reached. >>> >>> ...that might be the actual design bug. If a driver implements the a >>> service for both calling modes, the service should effectively do the >>> same, ie. should be mode-agnostic. Seems, this was violated here. >>> >>> Jan >> >> True, but this said, rt_task_shadow() should definitely leave the caller >> into secondary mode if called for SCHED_OTHER, since this would be the >> natural execution stage in that case. So rt_task_shadow() behaves like >> the documentation states, but should not in this particular case >> (prio=0). >> > > Then it needs to be understood what technically triggers this and > resolved, likely via an explicit migration. > Sure, good exercise for the reader to get ones feet wet with libalchemy. If somebody wants to tackle this: check callers of threadobj_run_corespec() in libcopperplate. The common case in this routine is to force a switch back to primary mode for the caller, on exit from threadobj_shadow(). We may want to make this conditional to the scheduling policy and priority. Following threadobj_init() for the content of idata may help too. -- Philippe.
