Re: [Xenomai-help] Analogy cmd_write example explanation

[Philippe Gerum <rpm@xenomai.org>]

On Thu, 2010-04-01 at 23:39 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > __xn_exec_current is actually carrying a MASSIVE bug potential:
> > - stick __xn_current to your favourite syscall, and implement two
> > versions of that syscall, depending on the current calling mode for the
> > shadow thread.
> > - let people think that they should control the current mode of that
> > thread using rt_task_set_mode() and this freaking horror monster called
> > T_PRIMARY, before calling the syscall in question, to get either
> > implementation A or B.
> > - run the stuff, and surprise, get a linux signal between
> > rt_task_set_mode and the syscall. Your thread is now NRT. Too bad, you
> > wanted the RT side to run. You are toast.
> 
> That's a non-issue if the driver gets informed about the capability of
> the caller to execute a service also in RT. In that case, if an RT
> variant of the invoked service exist, the driver can simply issue the
> well-know ENOSYS, despite the fact that it could handle the call right
> now in NRT as well.

This is not the issue at stake unfortunately. The problem is with
drivers implemented in a way that provides two _different_
implementations of syscalls depending on the current mode. In that case,
-ENOSYS and adaptive won't buy you anything. __xn_exec_current will
cause your syscall to be routed to the wrong handler as previously
illustrated.

Saying that anyone writing such a driver is close to being a good
candidate for the Darwin Awards is likely true, but as a matter of fact,
those driver do exist nonetheless. And the reason why they exist, is
because we have that eager mode switch control available to userland,
that gives a bad signal to people regarding the semantics of the whole
thing.

So, to put things in the right sequence: I'm not saying that forcing
conforming syscalls is the only option, but it's the only option that
_guarantees_ that userland won't shoot itself in the foot in the
presence of the T_PRIMARY crap. At the very least, any solution that
gives more insight to drivers regarding how to manipulate the current
mode should be mated to a converse effort to reduce the nuisance of
T_PRIMARY.

> 
> Jan
> 


-- 
Philippe.