Philippe Gerum wrote: > The steps now: > > - we implement the automatic switchback of shadow nrt threads to > secondary mode, upon return from Xenomai (primary) syscalls. I am > working on this. The most significant impact is on userland, due to the > fastsynch support, actually. Kernel-wise, it's rather straightforward. > The only exception to this would be when the caller owns an exclusive > resource (like a mutex), in which case the mode downgrade should be > postponed until the syscall releasing the last resource held returns.
Kernel is clear, but user space sounds indeed interesting. I guess we need an out-of-band channel to tell the kernel about pending user-space-only lock ownerships when calling some unrelated syscall. How does your current approach look like? > > - because of the previous fix, there would be no valid use case of > forced switches to secondary mode anymore, via > rt_task_set_mode/pthread_set_mode_np by clearing the T_PRIMARY bit. So > we may remove that particular call form, that is most often misused. > > - it turns out that __xn_exec_conforming is a misnomer, because it > rightfully causes a Xenomai nrt thread to switch to primary mode, albeit > that thread is inherently a secondary mode beast most of the time (at > least it should). We want to describe a syscall that switches the caller > to the highest domain it can reach instead, so we should rename this > mode bit as __xn_exec_strict for instance, without changing its > semantics. > > - we provide T_CONFORMING instead of T_PRIMARY for > rt_task_set_mode()/pthread_set_mode_np(), keeping the ABI (i.e. the bit > number) and the effect intact for existing callers, who are using this > to force a Xenomai-enabled rt thread back to primary mode, which could > make sense in some rare cases. However the semantics changes: invoking > this service from a Xenomai nrt thread would lead to a nop, because the > preferred mode of operation is secondary, so any switch to primary shall > be nucleus-controlled, and reverted upon syscall return asap. Changing > the macro name should also have the useful side effect of forcing a > serious code inspection for apps being rebuilt over 2.5.3, so that the > reason to switch mode eagerly could be reconsidered, and the app fixed > properly. > > To sum up, > > 1) rt_task_set_mode(whatever, T_PRIMARY, &oldmode) would become: > rt_task_set_mode(whatever, T_CONFORMING, &oldmode), actually forcing > primary mode for SCHED_FIFO Xenomai threads only. Nop otherwise. > > 2) rt_task_set_mode(T_CONFORMING, whatever, &oldmode) would always beget > -EINVAL, just because you can't ask for a thread to stop being > conformant to its basic nature. These two still look too complex and inconsistent to grasp. Let's just keep the kernel ABI, ie. let the kernel still interpret the bit (maybe now according to your conforming scheme), but drop T_PRIMARY from the user-visible defines. For the use case of an enforced primary mode switch-back, add a new service - if it is really required. rt_task_set_mode is about static property switching, so adding T_PRIMARY here was already a bad idea from that perspective. > > - then, as you pointed out, we should move the RTDM calls back to > __xn_exec_current, and provide rtdm_is_rt_capable() to allow drivers to > control the exec mode efficiently via the adaptive syscall scheme. This > way, there is no more need to play the T_PRIMARY game in order to > implement a syscall differently, depending on whether the caller is a > Xenomai shadow, or a plain linux task. The nucleus, the skins and the > driver always know better. Will come with my RTDM queue soon. It's delayed as it became too long, and something always needs more work or waits for more testing. Maybe I should start flushing the stable bits. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
