On 06/14/2016 07:13 PM, Jan Kiszka wrote: > On 2016-06-14 17:23, Philippe Gerum wrote: >> Restoring the original behavior unconditionally would not be a fix but >> only a work-around for your own issue. Finding a better way acceptable >> to all parties is on my todo list for the upcoming 3.0.3. > > An alternative design to a plain revert of the current->conforming > switch could be to enhance conforming to take the scheduling class into > account: SCHED_WEAK and SCHED_OTHER should have a NRT as conforming > domain while real-time scheduling classes obviously target RT. But I > didn't check yet what side effects that may have, nor if there could be > relevant impact on syscall performance (unlikely, though). >
That would not make more sense: SCHED_WEAK/OTHER is about having _Xenomai_ threads interfacing with the _Xenomai_ system, without competing with real-time threads priority-wise. But this is still about running Xenomai services, for synchronizing on real-time events or receiving messages from the real-time side. Basically, this requires to run from primary mode. We need a scheme that: - does not allow user-space to select the RTDM handler being called only by manipulating its runtime mode, because this would certainly lead to a massive mess for the application. - does not ask the driver to deal with mode detection on each and every (ioctl) request it implements. With the conforming mode applicable to all RTDM I/O calls, only the _rt side should return ENOSYS to hand over some requests to the nrt side. When a request cannot be processed from nrt, then we know the request is wrong/invalid, returning ENOSYS makes no sense. - possibly restrict the former "current" behavior to some ioctl() calls, as specified by the driver, not decided by the application. -- Philippe. _______________________________________________ Xenomai mailing list Xenomai@xenomai.org https://xenomai.org/mailman/listinfo/xenomai
