Philippe Gerum wrote: > On Wed, 2010-04-14 at 01:05 +0200, Jan Kiszka wrote: >> 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? > > I want to keep things simple: shadow nrt will go through the syscalls > for acquisition/release of owned resources, instead of fastsynchs.
Then I'll have to pick this up as that will very likely create unhappy customers. In fact, the majority of our Xenomai threads are nrt (yeah, that happens if you convert existing applications). > >>> - 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. > > This is exactly what was described: drop T_PRIMARY as a way to fully > control the mode from userland, provide T_CONFORMING as a limited action > to force a switch back to primary for shadow rt. Not exactly: I'm against T_CONFORMING. > >> 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. >> > > There is no such limitation to rt_task_set_mode(), and T_CONFORMING is > not meant to be used blindly. So, I will stick with this interface. T_CONFORMING is a mini-me of T_PRIMARY. If we already clean up the latter, it is a unique chance to finally drop that misplaced interface from rt_task_set_mode. It's asymmetric and does not really fit into the "true" modes that this interface controls. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
