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.

Jan