On 08.07.21 12:04, Richard Weinberger wrote: > On Thu, Jul 8, 2021 at 11:54 AM Jan Kiszka <[email protected]> wrote: >> >> 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. > > Can be, the driver was designed a long time ago. :-) > In the nrt ioctl() the driver uses e.g. ioremap(), this cannot work in primary > mode. Is the desired approach switching to secondary mode when in primary > mode such a code path is to be executed? >
Correct. That is easily achieved by returning -ENOSYS from the rt handler when seeing that nrt request in its context. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
