Re: [Xenomai-core] [Xenomai-help] Analogy cmd_write example explanation

[Philippe Gerum <rpm@xenomai.org>]

On Fri, 2010-04-02 at 13:28 +0200, Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > Jan Kiszka wrote:
> >> Gilles Chanteperdrix wrote:
> >>> Redirecting to xenomai core.
> >>>
> >>> Jan Kiszka wrote:
> >>>> Gilles Chanteperdrix wrote:
> >>>>> Because of __xn_exec_current, people have broken drivers, and user-space
> >>>>> applications using T_PRIMARY as a broken way to workaround these broken
> >>>>> drivers, and by maintaining compatibility, we let them keep their broken
> >>>>> drivers and applications, by changing to the more natural
> >>>>> __xn_exec_conforming and removing T_PRIMARY, we ask them to fix their
> >>>>> drivers and applications.
> >>>> Right goal, wrong approach for the reason I pointed out to Philippe:
> >>>>
> >>>> We cannot map all kinds of driver requirements on a single
> >>>> __xn_exec_current in the RTDM middle layer.
> >>> What requirement can we not handle? It looks to me like with
> >>> __xn_exec_conforming, we can handle any requirement.
> >>>
> >>> The only problem being the "double context switch" issue. But as
> >>> Philippe said, a sane application is calling such ioctls from non
> >>> critical code, so this is in fact a non-issue.
> >> And this is one of the restrictions I don't want to keep for upcoming
> >> versions. Think of a POSIX app that creates threads, even non-RT ones.
> >> Those are automatically shadowed. If those threads perform lots of
> >> non-RT service requests on RTDM drivers, they will suffer.
> > 
> > If those threads perform lots of non-RT service requests on RTDM drivers
> > at a non critical time, then no problem.
> 
> That's is a needless regression as we now do decisions in the wrong
> layer without sufficient knowledge about the case. RTDM is just a
> support layer for the driver, the logic sits in the latter.

You can't regress that much from a wrong situation. It is incorrect
already, and this is definitely much more important than a corner case.
As we all agreed, this is an issue that makes a number of people think
they should or even _have to_ control the current domain their threads
are running in. This leads to a fundamental misunderstanding about: 1)
how to write efficient apps, 2) how to write sane drivers.

This said, I agree that making RTDM syscalls conforming may cause some
pre-2.5.2 drivers to break, and unless there is absolutely no other
route to get things fixed, we should avoid this. So here is another
option I'd like we consider. Actually, it's not a single fix, but rather
several steps to fix the situation with respect to (eager) mode
management in RTDM drivers and elsewhere.

A few assumptions that drive the logic below:

- a shadow nrt thread running in secondary mode won't get a significant
performance advantage with conforming calls, compared to lazy-switching
calls (i.e. __xn_exec_current). The only advantage would come from not
running the RTDM syscall prologue twice when calling a rt service, which
is admittedly no big deal, in the absence of significant pressure on the
RTDM context lock. Since we do want to make nrt shadows automatically
switch back to secondary mode at some point, it turns out that the
preferred mode of operation for them would not be significantly favored
by conforming calls, even when applied to rt services.

- applications using rt_task_set_mode(...T_PRIMARY...) or the POSIX skin
equivalent via pthead_set_mode_np() are very likely to be wrong. At
best, they are adding a useless overhead, at worst, they are assuming
too much from the call. E.g. stepping into such code over GDB will
defeat the purpose of any switch to primary mode, receiving linux
signals as well (and the nucleus may send some of them), and I take for
granted that nobody wants utter crap like sigblock
+set_mode(T_PRIMARY)+syscall+sigunblock to never ever show up as a
common coding pattern in application space.

- as an illustration of the previous issue, attempting to control the
behavior of a RTDM driver by eagerly switching to the so-called "right"
mode before invoking some driver entry points, instead of having the
driver implement the proper logic to handle the adaptive switch if both
modes are supported, is definitely wrong.

- it turns out that we should find a way to leave the mode switch
handling where it belongs to, which is in kernel space (nucleus, skins,
and drivers), and definitely not in userland.

- there is no mode issue wrt shadow rt and plain linux tasks. The
preferred exec mode for the latter shall be primary, and the latter only
supports secondary mode anyway. So we are only discussing about shadow
nrt threads, i.e. Xenomai-enabled SCHED_OTHER threads in userland.

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.

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

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


-- 
Philippe.