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. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
