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.

> 
> > 
> > - 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.

>  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.

> > 
> > - 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
> 


-- 
Philippe.



_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to