Philippe Gerum wrote:
> 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.
> 

Then it's time to signal the deprecation of T_PRIMARY & co. At least
from RTDM POV, there is no need for it anymore (once we resolved the
Analogy case). And RTDM was the only valid use case I recall.

Jan