Re: [Xenomai-help] Analogy cmd_write example explanation

[Philippe Gerum <rpm@xenomai.org>]

On Sun, 2010-03-14 at 00:34 +0100, Alexis Berlemont wrote:
> Philippe Gerum wrote:
> > On Sat, 2010-03-13 at 17:13 +0100, Alexis Berlemont wrote:
> >> Hi,
> >>
> >> Philippe Gerum wrote:
> >>> On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote:
> >>>> Hi,
> >>>>
> >>>> Sorry for answering so late. I took a few days off far from any internet
> >>>> connection.
> >>>>
> >>>> It seems you sent many mails related with Analogy. Many thanks for your
> >>>> interest. I have not read all of them yet. However, I am beginning by
> >>>> this one (which seems unanswered). The answer is quick and easy :)
> >>>>
> >>>> Daniele Nicolodi wrote:
> >>>>> Hello. I'm looking into the analogy cmd_write example.
> >>>>>
> >>>>> I'm not sure I understand the reason for the rt_task_set_mode() function
> >>>>> call into the data acquisition loop (lines 413 or 464 in the code
> >>>>> shipped with xenomai 2.5.1).
> >>>>>
> >>>>> I do not understand why we have to set the primary mode at every
> >>>>> iteration, when we set it before for the task (line 380).
> >>>>>
> >>>>> Is it because the dump_function() uses system calls that can make the
> >>>>> task to switch to secondary mode, or there is a deeper reason I'm missing?
> >>>>>
> >>>> You are right. The dumping routine triggers a switch to secondary mode.
> >>>> That is why, the program switches back to primary mode after.
> >>> This is wrong. The Xenomai core will switch your real-time thread to
> >>> primary mode automatically when running a4l_insn* calls that end up
> >>> invoking rt_dev_ioctl(), since you did declare a real-time entry point
> >>> for this one.
> >>>
> >> I don't understand. I thought that rt_dev_ioctl() triggered an
> >> __rtdm_ioctl syscall, which, according to the rtdm systab, is declared
> >> with the flags "__xn_exec_current | __xn_exec_adaptive".
> >>
> >> So as __rt_dev_ioctl (the kernel handler behind the ioctl syscall) will
> >> return -ENOSYS neither in RT nor in NRT mode (because analogy declares
> >> both RT and NRT fops entries), I thought there was no automatic
> >> mode-switching.
> > 
> > The point is that your ioctl_nrt handler should return -ENOSYS when it
> > detects that the current request should be processed by the converse
> > domain, to trigger the switch to primary mode. This is why the adaptive
> > tag is provided in the first place.
> The problem is that rtdm does not provide any function to know whether
> the thread is shadowed. We just have rtdm_in_rt_context() which tells us
> whether the thread is RT or not. If it is NRT, we cannot distinguish a
> Linux thread from a Xenomai one.
> 
> I thought with a little patch like this in ksrc/skins/rtdm/core.c, we 
> could force -ENOSYS if the calling thread was a Xenomai NRT thread:
> 
>   diff --git a/ksrc/skins/rtdm/core.c b/ksrc/skins/rtdm/core.c
> index 8677c47..cc0cfe9 100644
> --- a/ksrc/skins/rtdm/core.c
> +++ b/ksrc/skins/rtdm/core.c
> @@ -423,6 +423,9 @@ do {									\
>   									\
>   	if (rtdm_in_rt_context())					\
>   		ret = ops->operation##_rt(context, user_info, args);	\
> +	else if (xnshadow_thread(user_info) != NULL &&			\
> +		 ops->operation##_rt != (void *)rtdm_no_support)	\
> +		ret = -ENOSYS;						\
>   	else								\
>   		ret = ops->operation##_nrt(context, user_info, args);	\
>   									\

No, this would be a half-working kludge. But I think you have pinpointed
a more general issue with RTDM: syscalls should be tagged as both
adaptive and conforming, instead of bearing the __xn_exec_current bit.
Actually, we do want the current domain to change when it is not the
most appropriate, which __xn_exec_current prevents so far.

What we rather want is to have shadows migrating to primary mode when
running rtdm_ioctl, since this is the preferred mode of operation for
Xenomai threads, so that ioctl_rt is always invoked first when present,
giving an opportunity to forward the request to secondary mode by
returning -ENOSYS. Conforming calls always enforce the preferred runtime
mode, i.e. primary for Xenomai shadows, secondary for plain Linux tasks.
That logic applies to all RTDM syscalls actually.

__xn_exec_current allows application code to infer that the RTDM driver
might behave differently depending on the current runtime mode of the
calling thread, which is very much error-prone, and likely not what was
envisioned initially.

Jan?

diff --git a/ksrc/skins/rtdm/syscall.c b/ksrc/skins/rtdm/syscall.c
index 80785ab..5fb340d 100644
--- a/ksrc/skins/rtdm/syscall.c
+++ b/ksrc/skins/rtdm/syscall.c
@@ -154,7 +154,7 @@ static xnsysent_t __systab[] = {
 	[__rtdm_close] =
 	    {sys_rtdm_close, __xn_exec_current | __xn_exec_adaptive},
 	[__rtdm_ioctl] =
-	    {sys_rtdm_ioctl, __xn_exec_current | __xn_exec_adaptive},
+	    {sys_rtdm_ioctl, __xn_exec_conforming | __xn_exec_adaptive},
 	[__rtdm_read] = {sys_rtdm_read, __xn_exec_current | __xn_exec_adaptive},
 	[__rtdm_write] =
 	    {sys_rtdm_write, __xn_exec_current | __xn_exec_adaptive},

> 
> However, that patch triggers a problem, some Analogy ioctls (mmap and
> bufconfig) needs to be done in NRT context. So, the forcing makes their
> executions impossible.
> 
> Maybe the solution would be adding a function rtdm_in_shadowed_context()
> in the rtdm api:
> 
> static inline int rtdm_in_shadow_context(rtdm_user_info_t *user_info)
> {
> 	return (xnshadow_thread(user_info) != NULL);
> }
> 
> > 
> > If the above can't be done, this means that such ioctl request has a
> > different implementation for a real-time task, depending on whether it
> > runs in primary or secondary mode, which would turn out to be the basic
> > issue: this would be ambiguous and very much error-prone. This is where
> > relying on rt_task_set_mode() may reveal design issues.
> > 
> >> So, for me, an RT task running in secondary mode, which triggers an RTDM
> >> ioctl, stays in the current mode (NRT mode) if the RTDM IOCTL NRT
> >> handler is available. For me, switching back to primary mode if the RT
> >> handler is available is not the current behaviour.
> >>
> >> What did I miss ?
> >>
> >>> Let's summarize the whole point of forcing primary mode through
> >>> rt_task_set_mode(): it's bad, it's wrong, it's counter-productive
> >>> CPU-wise, it usually reveals a design issue in the calling code in most
> >>> cases.
> >>>
> >>> The only application-level use case where switching to primary mode
> >>> eagerly this way might make sense, is when the code first switches to
> >>> secondary, then runs an awful lot of CPU-intensive code without issuing
> >>> any syscall, one might want to keep un-preempted from Linux IRQs. In
> >>> such a case, the question which arises immediately is: why the hell does
> >>> one ever tolerate switching to secondary mode initially, if strict
> >>> timely behavior is wanted later on? 
> >>>
> >>> That crap is a freaking mistake of mine, when I exported such
> >>> anti-feature via the native API mindlessly, to provide a work-around for
> >>> rare situations some internal Xenomai code might benefit from. I should
> >>> have provided an internal syscall instead, to hide this monster deep
> >>> into the abyssal zone it should never have left.
> >>>
> >>> In short: DO NOT USE THIS.
> >> I will remove it in cmd_read and cmd_write.
> >>
> >>>> Almost all the Analogy programs (cmd_read, cmd_write, insn_read,
> >>>> insn_write, insn_bits) are just demonstration examples. That is why the
> >>>> code is so linear, lengthy and repetitive. Furthermore, the code was not
> >>>> meant to be efficient. I just wanted to test the RT and NRT entries.
> >>>>
> >>>> By the way, I started to improve them. One change (which is still
> >>>> missing) is the use of rtdk.
> >>>>
> >>>>> Thanks. Cheers,
> >>>> Alexis.
> >>>>
> >>>> _______________________________________________
> >>>> Xenomai-help mailing list
> >>>> Xenomai-help@domain.hid
> >>>> https://mail.gna.org/listinfo/xenomai-help
> >>>
> >> Alexis.
> > 
> > 
> 
> Alexis.


-- 
Philippe.