[Xenomai-help] Analogy cmd_write example explanation

[Xenomai-help] Analogy cmd_write example explanation

[Daniele Nicolodi]

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?

Thanks. Cheers,
-- 
Daniele

Re: [Xenomai-help] Analogy cmd_write example explanation

[Alexis Berlemont]

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.

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.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Philippe Gerum]

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.

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.

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


-- 
Philippe.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Alexis Berlemont]

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.

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.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Philippe Gerum]

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.

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.


-- 
Philippe.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Alexis Berlemont]

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);	\
  									\

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.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Philippe Gerum]

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.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 5172 bytes --]

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

Right, this stickiness of RTDM syscalls to the current execution mode
conceptually dates back to the days we had users with services provided
to both domain. This model is deprecated (e.g. RTnet dropped resources
allocation from RT domain, only supports NRT now).

So I've no concerns making the call conforming - but... I guess this
would just paper over a design issue (or misunderstanding?) in Analogy.
Why does it depend on shadow vs. non-shadow at all? The explanations I
read so far were not clarifying the reason. Is there any Analogy service
that is provided to both domains (via different implementations)? If
yes, why?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-help] Analogy cmd_write example explanation

[Alexis Berlemont]

Hi,

Jan Kiszka wrote:
> Philippe Gerum wrote:
>> 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.
> 
> Right, this stickiness of RTDM syscalls to the current execution mode
> conceptually dates back to the days we had users with services provided
> to both domain. This model is deprecated (e.g. RTnet dropped resources
> allocation from RT domain, only supports NRT now).
> 
> So I've no concerns making the call conforming - but... I guess this
> would just paper over a design issue (or misunderstanding?) in Analogy.
> Why does it depend on shadow vs. non-shadow at all? The explanations I
> read so far were not clarifying the reason. Is there any Analogy service
> that is provided to both domains (via different implementations)? If
> yes, why?
> 

Analogy provides all the services in both domains:
- the instructions services are synchronous operations; no explicit
rescheduling are triggered, consequently, the implementations of the
various kinds of instructions displays are the same in both mode;
- the commands services allow asynchronous operations; so the handlers
behind the read / write fops are the same for RT and NRT entries;
however, the event management code relies on rtdm_event in one case and
on rtdm_nrtsig + waitqueues in the other case.

The main part of the "event" code is located in a4l_wait_sync and 
a4l_signal_sync.

Which design issue do you have in mind ?

Concerning your question: why ?

Not all the acquisition system users ask for determinism; working with
real-time tasks may not be mandatory. So all they need to know is the
Analogy API.

Furthermore, many acquisition boards have an impressive set of
configuration parameters which are accessed via the operations described
above. One may be interested in scripting a part of the user application
so as to gain development time. I don't want to lose flexibility by
confining Analogy to real-time tasks.

> Jan
> 
Alexis.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 7694 bytes --]

Alexis Berlemont wrote:
> Hi,
> 
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> 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.
>>
>> Right, this stickiness of RTDM syscalls to the current execution mode
>> conceptually dates back to the days we had users with services provided
>> to both domain. This model is deprecated (e.g. RTnet dropped resources
>> allocation from RT domain, only supports NRT now).
>>
>> So I've no concerns making the call conforming - but... I guess this
>> would just paper over a design issue (or misunderstanding?) in Analogy.
>> Why does it depend on shadow vs. non-shadow at all? The explanations I
>> read so far were not clarifying the reason. Is there any Analogy service
>> that is provided to both domains (via different implementations)? If
>> yes, why?
>>
> 
> Analogy provides all the services in both domains:
> - the instructions services are synchronous operations; no explicit
> rescheduling are triggered, consequently, the implementations of the
> various kinds of instructions displays are the same in both mode;
> - the commands services allow asynchronous operations; so the handlers
> behind the read / write fops are the same for RT and NRT entries;
> however, the event management code relies on rtdm_event in one case and
> on rtdm_nrtsig + waitqueues in the other case.
> 
> The main part of the "event" code is located in a4l_wait_sync and
> a4l_signal_sync.
> 
> Which design issue do you have in mind ?

I was concerned about resource allocating services for both domains. For
that reason, you should drop open_rt & close_rt callbacks even if they
may not allocate anything at analogy level ATM, they do at RTDM level.
RT resource allocation of RTDM drivers is deprecated (I will remove the
corresponding callbacks for Xenomai 3).

> 
> Concerning your question: why ?
> 
> Not all the acquisition system users ask for determinism; working with
> real-time tasks may not be mandatory. So all they need to know is the
> Analogy API.
> 
> Furthermore, many acquisition boards have an impressive set of
> configuration parameters which are accessed via the operations described
> above. One may be interested in scripting a part of the user application
> so as to gain development time. I don't want to lose flexibility by
> confining Analogy to real-time tasks.

I can't asses ATM how much this actually buys the typical Analogy user,
specifically given that it still takes a Xenomai kernel + user land to
use it and shadowing low-prio (SCHED_OTHER) tasks is feasible as well today.

But you should at least warn the user that select() is not working that
way. It remains restricted to RT tasks as there is no Linux "shadow" FD
for the RTDM one.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-help] Analogy cmd_write example explanation

[Philippe Gerum]

On Tue, 2010-03-16 at 00:30 +0100, Alexis Berlemont wrote:
> Hi,
> 
> Jan Kiszka wrote:
> > Philippe Gerum wrote:
> >> 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.
> > 
> > Right, this stickiness of RTDM syscalls to the current execution mode
> > conceptually dates back to the days we had users with services provided
> > to both domain. This model is deprecated (e.g. RTnet dropped resources
> > allocation from RT domain, only supports NRT now).
> > 
> > So I've no concerns making the call conforming - but... I guess this
> > would just paper over a design issue (or misunderstanding?) in Analogy.
> > Why does it depend on shadow vs. non-shadow at all? The explanations I
> > read so far were not clarifying the reason. Is there any Analogy service
> > that is provided to both domains (via different implementations)? If
> > yes, why?
> > 
> 
> Analogy provides all the services in both domains:
> - the instructions services are synchronous operations; no explicit
> rescheduling are triggered, consequently, the implementations of the
> various kinds of instructions displays are the same in both mode;
> - the commands services allow asynchronous operations; so the handlers
> behind the read / write fops are the same for RT and NRT entries;
> however, the event management code relies on rtdm_event in one case and
> on rtdm_nrtsig + waitqueues in the other case.
> 

Actually, the issue is not with having rt and regular tasks accept the
very same calls, it is with having the rt tasks potentially run
_different code_ for a very same request, depending on whether it is
running in primary or secondary mode.

That design issue is usually revealed by userland code switching mode
eagerly via rt_task_set_mode(), which means that the next syscall(s) may
be mode-sensitive, for that task. This is what should be fixed, without
implying that you may not define a mode-insensitive API, in order to
allow calls from rt _and_ non-rt tasks.

Provided the rtdm syscalls you need are made conforming, here is the
typical pattern I'm referring to for implementing them:

syscall_rt(...)
{
	/* We must be a shadow thread, since we got there */
	if (cant_provide_service_in_primary_mode())
		/* maybe available from secondary mode? forward it. */
		return -ENOSYS;

	do_service();
}

syscall_nrt(...)
{
	/* We could be a shadow thread unable to process the request in primary
mode, or a plain linux task. */

	do_service();
}



> The main part of the "event" code is located in a4l_wait_sync and 
> a4l_signal_sync.
> 
> Which design issue do you have in mind ?
> 
> Concerning your question: why ?
> 
> Not all the acquisition system users ask for determinism; working with
> real-time tasks may not be mandatory. So all they need to know is the
> Analogy API.
> 
> Furthermore, many acquisition boards have an impressive set of
> configuration parameters which are accessed via the operations described
> above. One may be interested in scripting a part of the user application
> so as to gain development time. I don't want to lose flexibility by
> confining Analogy to real-time tasks.
> 
> > Jan
> > 
> Alexis.


-- 
Philippe.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Alexis Berlemont]

Philippe Gerum wrote:
> On Tue, 2010-03-16 at 00:30 +0100, Alexis Berlemont wrote:
>> Hi,
>>
>> Jan Kiszka wrote:
>>> Philippe Gerum wrote:
>>>> 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.
>>> Right, this stickiness of RTDM syscalls to the current execution mode
>>> conceptually dates back to the days we had users with services provided
>>> to both domain. This model is deprecated (e.g. RTnet dropped resources
>>> allocation from RT domain, only supports NRT now).
>>>
>>> So I've no concerns making the call conforming - but... I guess this
>>> would just paper over a design issue (or misunderstanding?) in Analogy.
>>> Why does it depend on shadow vs. non-shadow at all? The explanations I
>>> read so far were not clarifying the reason. Is there any Analogy service
>>> that is provided to both domains (via different implementations)? If
>>> yes, why?
>>>
>> Analogy provides all the services in both domains:
>> - the instructions services are synchronous operations; no explicit
>> rescheduling are triggered, consequently, the implementations of the
>> various kinds of instructions displays are the same in both mode;
>> - the commands services allow asynchronous operations; so the handlers
>> behind the read / write fops are the same for RT and NRT entries;
>> however, the event management code relies on rtdm_event in one case and
>> on rtdm_nrtsig + waitqueues in the other case.
>>
> 
> Actually, the issue is not with having rt and regular tasks accept the
> very same calls, it is with having the rt tasks potentially run
> _different code_ for a very same request, depending on whether it is
> running in primary or secondary mode.
> 
> That design issue is usually revealed by userland code switching mode
> eagerly via rt_task_set_mode(), which means that the next syscall(s) may
> be mode-sensitive, for that task. This is what should be fixed, without
> implying that you may not define a mode-insensitive API, in order to
> allow calls from rt _and_ non-rt tasks.
> 
> Provided the rtdm syscalls you need are made conforming, here is the
> typical pattern I'm referring to for implementing them:
> 
> syscall_rt(...)
> {
> 	/* We must be a shadow thread, since we got there */
> 	if (cant_provide_service_in_primary_mode())
> 		/* maybe available from secondary mode? forward it. */
> 		return -ENOSYS;
> 
> 	do_service();
> }
> 
> syscall_nrt(...)
> {
> 	/* We could be a shadow thread unable to process the request in primary
> mode, or a plain linux task. */
> 
> 	do_service();
> }
Yes I understand. I did that two days ago. My git repository will be
updated. Is it ok for you ?

Author: Alexis Berlemont <alexis.berlemont@domain.hid>  2010-03-16 01:19:23
Committer: Alexis Berlemont <alexis.berlemont@domain.hid>  2010-03-16 
01:19:23
Parent: 4be0333bef1a7dd41ef79b4d31209642b05e5593 (analogy: remove 
rt_task_set_mode from test programs)
Child:  0000000000000000000000000000000000000000 (Local uncommitted 
changes, not checked in to index)
Branch: analogy
Follows: v2.5.1
Precedes:

     analogy: change the error code in case of context error (-EPERM -> 
-ENOSYS)

     Replace the -EPERM code by the -ENOSYS in bufconfig and mmap
     ioctls. These two ioctls must be performed in NRT context. With the
     __xn_exec_adaptive flag, the syscalls may be restarted in the proper
     domain (NRT in our case) if the suitable error code is sent.

------------------------ ksrc/drivers/analogy/buffer.c 
------------------------
index 0c66b4a..aa6acac 100644
@@ -397,8 +397,7 @@ int a4l_ioctl_mmap(a4l_cxt_t *cxt, void *arg)
  	/* The mmap operation cannot be performed in a
  	   real-time context */
  	if (a4l_test_rt() != 0) {
-		__a4l_err("a4l_ioctl_mmap: mmap must be done in NRT context\n");
-		return -EPERM;
+		return -ENOSYS;
  	}

  	/* Recover the argument structure */
@@ -473,9 +472,7 @@ int a4l_ioctl_bufcfg(a4l_cxt_t * cxt, void *arg)
  	/* As Linux API is used to allocate a virtual buffer,
  	   the calling process must not be in primary mode */
  	if (a4l_test_rt() != 0) {
-		__a4l_err("a4l_ioctl_bufcfg: buffer config must done "
-			  "in NRT context\n");
-		return -EPERM;
+		return -ENOSYS;
  	}

  	if (rtdm_safe_copy_from_user(cxt->user_info,

------------------------ ksrc/drivers/analogy/device.c 
------------------------
index 082053f..ec40b95 100644
@@ -428,7 +428,7 @@ int a4l_ioctl_devcfg(a4l_cxt_t * cxt, void *arg)
  		  "a4l_ioctl_devcfg: minor=%d\n", a4l_get_minor(cxt));

  	if (a4l_test_rt() != 0)
-		return -EPERM;
+		return -ENOSYS;

  	if (arg == NULL) {
  		/* Basic checking */



> 
> 
> 
>> The main part of the "event" code is located in a4l_wait_sync and 
>> a4l_signal_sync.
>>
>> Which design issue do you have in mind ?
>>
>> Concerning your question: why ?
>>
>> Not all the acquisition system users ask for determinism; working with
>> real-time tasks may not be mandatory. So all they need to know is the
>> Analogy API.
>>
>> Furthermore, many acquisition boards have an impressive set of
>> configuration parameters which are accessed via the operations described
>> above. One may be interested in scripting a part of the user application
>> so as to gain development time. I don't want to lose flexibility by
>> confining Analogy to real-time tasks.
>>
>>> Jan
>>>
>> Alexis.
> 
> 

Alexis.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Philippe Gerum]

On Thu, 2010-03-18 at 22:14 +0100, Alexis Berlemont wrote:
> Yes I understand. I did that two days ago. My git repository will be
> updated. Is it ok for you ?

Yes, looks good.

-- 
Philippe.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Gilles Chanteperdrix]

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

Argh.... The switchtest driver is relying on __xn_exec_current to have
context switches occur precisely in the mode we want. __xn_exec_adaptive
introduce more context switches around which we can not place separate
checks for fpu context, so, in short, breaks it badly. Fixing this
requires turning the switchtest driver into a skin with its own syscalls.

Note the sequence which occurs when a shadowed thread running in
secondary mode calls an ioctl for which only an nrt implementation occurs:
the thread is hardened to handle the ioctl
ioctl_rt is called which returns -ENOSYS
the thread is relaxed
ioctl_nrt is called

It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm
syscall made by a thread with a shadow, and in fact seems to result in
as bad a result. Is it really what we want? The __xn_exec_current bit
resulted in a more lazy behaviour.

Also note that, at least when using the posix skin, almost all threads
have shadows, and only the priority makes the difference between a
really critical thread, and non critical threads with the null priority.
So, this will happen all the time.

-- 
					    Gilles.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 7254 bytes --]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> 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.
> 
> Argh.... The switchtest driver is relying on __xn_exec_current to have
> context switches occur precisely in the mode we want. __xn_exec_adaptive
> introduce more context switches around which we can not place separate
> checks for fpu context, so, in short, breaks it badly. Fixing this
> requires turning the switchtest driver into a skin with its own syscalls.
> 
> Note the sequence which occurs when a shadowed thread running in
> secondary mode calls an ioctl for which only an nrt implementation occurs:
> the thread is hardened to handle the ioctl
> ioctl_rt is called which returns -ENOSYS
> the thread is relaxed
> ioctl_nrt is called
> 
> It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm
> syscall made by a thread with a shadow, and in fact seems to result in
> as bad a result. Is it really what we want? The __xn_exec_current bit
> resulted in a more lazy behaviour.
> 
> Also note that, at least when using the posix skin, almost all threads
> have shadows, and only the priority makes the difference between a
> really critical thread, and non critical threads with the null priority.
> So, this will happen all the time.

Right. Actually, we only need the conforming property for the (fairly
rare) case that a service is provided in both flavors. And if such a
service is hidden behind a single IOCTL command, it's even not possible
to detect this at RTDM level. We do need help from the driver or its
user space library, or we need to give them the tools to do the adaptive
switch themselves.

So three options:
 - Implement adaptive switching inside RTDM
    o For all major functions != ioctl, we need to check for a shadow
      thread and the availability of an RT handler => switch
    o For IOCTLs we need an extra bit, likely in the IOC_TYPE namespace
      to indicate the availability of an RT handler. This comes at the
      risk of colliding with existing drivers that do not use the
      standard IOCTL encoding scheme.
 - Push adaptive switching into the driver
    o That means providing the information if the caller could be
      switched to RT context.
 - Push adaptive switching into the helper library
    o That means exporting a service that performs a switch if the
      caller is switchable, but currently relaxed.

The second option is the least invasive one, I think. The first one is
most transparent, but also more fragile and complex than the rest. Three
is likely not Philippe's favorite as it would introduce yet another
explicit mode switching mechanism.

Opinions? Other ideas?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-help] Analogy cmd_write example explanation

[Philippe Gerum]

On Thu, 2010-04-01 at 23:13 +0200, Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> >> 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.
> > 
> > Argh.... The switchtest driver is relying on __xn_exec_current to have
> > context switches occur precisely in the mode we want. __xn_exec_adaptive
> > introduce more context switches around which we can not place separate
> > checks for fpu context, so, in short, breaks it badly. Fixing this
> > requires turning the switchtest driver into a skin with its own syscalls.
> > 
> > Note the sequence which occurs when a shadowed thread running in
> > secondary mode calls an ioctl for which only an nrt implementation occurs:
> > the thread is hardened to handle the ioctl
> > ioctl_rt is called which returns -ENOSYS
> > the thread is relaxed
> > ioctl_nrt is called
> > 
> > It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm
> > syscall made by a thread with a shadow, and in fact seems to result in
> > as bad a result. Is it really what we want? The __xn_exec_current bit
> > resulted in a more lazy behaviour.
> > 
> > Also note that, at least when using the posix skin, almost all threads
> > have shadows, and only the priority makes the difference between a
> > really critical thread, and non critical threads with the null priority.
> > So, this will happen all the time.
> 
> Right. Actually, we only need the conforming property for the (fairly
> rare) case that a service is provided in both flavors.

Wrong. You want conforming because real-time is the preferred mode of
operations for real-time threads.

>  And if such a
> service is hidden behind a single IOCTL command, it's even not possible
> to detect this at RTDM level. We do need help from the driver or its
> user space library, or we need to give them the tools to do the adaptive
> switch themselves.
> 
> So three options:
>  - Implement adaptive switching inside RTDM
>     o For all major functions != ioctl, we need to check for a shadow
>       thread and the availability of an RT handler => switch
>     o For IOCTLs we need an extra bit, likely in the IOC_TYPE namespace
>       to indicate the availability of an RT handler. This comes at the
>       risk of colliding with existing drivers that do not use the
>       standard IOCTL encoding scheme.
>  - Push adaptive switching into the driver
>     o That means providing the information if the caller could be
>       switched to RT context.
>  - Push adaptive switching into the helper library
>     o That means exporting a service that performs a switch if the
>       caller is switchable, but currently relaxed.
> 
> The second option is the least invasive one, I think. The first one is
> most transparent, but also more fragile and complex than the rest. Three
> is likely not Philippe's favorite as it would introduce yet another
> explicit mode switching mechanism.
> 
> Opinions? Other ideas?
> 
> Jan
> 


-- 
Philippe.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Philippe Gerum]

On Thu, 2010-04-01 at 21:47 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > 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.
> 
> Argh.... The switchtest driver is relying on __xn_exec_current to have
> context switches occur precisely in the mode we want.

The switchtest driver is aimed at testing that some processing do work
reliably in all runtime modes and execution domains, for that reason, it
_has to_ control the current mode, and why that code has to understand
the inner working of the Xenomai core to trigger exactly what it wants
to observe. But this is hardly what a normal application wants to deal
with.

>  __xn_exec_adaptive
> introduce more context switches around which we can not place separate
> checks for fpu context, so, in short, breaks it badly. Fixing this
> requires turning the switchtest driver into a skin with its own syscalls.
> 

Forget about switchtest when discussing the exec/adaptive bits, really.
The real issue is with the conforming bit actually. This app is one of a
kind, and exactly at the opposite of the normal use case we want to
follow the principle of least surprise.

switchtest is broken now because it used to rely on an anti-feature that
used to break application code. The sad truth is that by fixing the case
for the normal application usage, we broke switchtest. But this is at
least more acceptable.

> Note the sequence which occurs when a shadowed thread running in
> secondary mode calls an ioctl for which only an nrt implementation occurs:
> the thread is hardened to handle the ioctl
> ioctl_rt is called which returns -ENOSYS
> the thread is relaxed
> ioctl_nrt is called
> 

Yes, and that is to be expected and acceptable. In most drivers, how
many calls are implemented as secondary mode _only_, to be fired by rt
threads, that would trigger such double-switch? E.g. how many syscalls
do require to migrate to secondary because they rely on regular Linux
kernel services and may also be called by rt threads? 1%?
And of course, none of them can guarantee any real-time behaviour, so
you won't invoke them in your time-critical code, which means that one
context switch more in this case is not a serious issue.

So, it remains that in the overwhelming number of cases, people calling
a real-time driver want the driver to do, well, real-time things. And if
they don't in some instances, well, they just don't care about one
context switch more, to allow real-time threads to downgrade to the
proper mode, if this is what really bugs you.

> It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm
> syscall made by a thread with a shadow, and in fact seems to result in
> as bad a result. Is it really what we want? The __xn_exec_current bit
> resulted in a more lazy behaviour.
> 

switchtest wants to be lazy. Normal applications don't care a dime, they
are mainly dealing with real-time code, that requires real-time mode,
and as such a conforming call.

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

Besides, you could not even debug your application under GDB sanely in
that case, because tracing downgrades the caller to secondary, and
__xn_exec_current does not force migration.

> Also note that, at least when using the posix skin, almost all threads
> have shadows, and only the priority makes the difference between a
> really critical thread, and non critical threads with the null priority.
> So, this will happen all the time.
> 

Mmm. Is your point that most RTDM drivers out there are implementing
mostly linux mode calls to be run in time-critical tight loops?

-- 
Philippe.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 8064 bytes --]

Philippe Gerum wrote:
> On Thu, 2010-04-01 at 23:13 +0200, Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Philippe Gerum wrote:
>>>> 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.
>>> Argh.... The switchtest driver is relying on __xn_exec_current to have
>>> context switches occur precisely in the mode we want. __xn_exec_adaptive
>>> introduce more context switches around which we can not place separate
>>> checks for fpu context, so, in short, breaks it badly. Fixing this
>>> requires turning the switchtest driver into a skin with its own syscalls.
>>>
>>> Note the sequence which occurs when a shadowed thread running in
>>> secondary mode calls an ioctl for which only an nrt implementation occurs:
>>> the thread is hardened to handle the ioctl
>>> ioctl_rt is called which returns -ENOSYS
>>> the thread is relaxed
>>> ioctl_nrt is called
>>>
>>> It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm
>>> syscall made by a thread with a shadow, and in fact seems to result in
>>> as bad a result. Is it really what we want? The __xn_exec_current bit
>>> resulted in a more lazy behaviour.
>>>
>>> Also note that, at least when using the posix skin, almost all threads
>>> have shadows, and only the priority makes the difference between a
>>> really critical thread, and non critical threads with the null priority.
>>> So, this will happen all the time.
>> Right. Actually, we only need the conforming property for the (fairly
>> rare) case that a service is provided in both flavors.
> 
> Wrong. You want conforming because real-time is the preferred mode of
> operations for real-time threads.

Sorry, wrong as well. :)

Setup/reconfiguration phases happening over already shadowed threads can
suffer significantly when playing ping-pong via mode switches. That's
why threads stay in secondary mode after their first Linux syscall and
are not immediately switched back.

Jan

> 
>>  And if such a
>> service is hidden behind a single IOCTL command, it's even not possible
>> to detect this at RTDM level. We do need help from the driver or its
>> user space library, or we need to give them the tools to do the adaptive
>> switch themselves.
>>
>> So three options:
>>  - Implement adaptive switching inside RTDM
>>     o For all major functions != ioctl, we need to check for a shadow
>>       thread and the availability of an RT handler => switch
>>     o For IOCTLs we need an extra bit, likely in the IOC_TYPE namespace
>>       to indicate the availability of an RT handler. This comes at the
>>       risk of colliding with existing drivers that do not use the
>>       standard IOCTL encoding scheme.
>>  - Push adaptive switching into the driver
>>     o That means providing the information if the caller could be
>>       switched to RT context.
>>  - Push adaptive switching into the helper library
>>     o That means exporting a service that performs a switch if the
>>       caller is switchable, but currently relaxed.
>>
>> The second option is the least invasive one, I think. The first one is
>> most transparent, but also more fragile and complex than the rest. Three
>> is likely not Philippe's favorite as it would introduce yet another
>> explicit mode switching mechanism.
>>
>> Opinions? Other ideas?
>>
>> Jan
>>
> 
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-help] Analogy cmd_write example explanation

[Philippe Gerum]

On Thu, 2010-04-01 at 23:26 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Thu, 2010-04-01 at 23:13 +0200, Jan Kiszka wrote:
> >> Gilles Chanteperdrix wrote:
> >>> Philippe Gerum wrote:
> >>>> 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.
> >>> Argh.... The switchtest driver is relying on __xn_exec_current to have
> >>> context switches occur precisely in the mode we want. __xn_exec_adaptive
> >>> introduce more context switches around which we can not place separate
> >>> checks for fpu context, so, in short, breaks it badly. Fixing this
> >>> requires turning the switchtest driver into a skin with its own syscalls.
> >>>
> >>> Note the sequence which occurs when a shadowed thread running in
> >>> secondary mode calls an ioctl for which only an nrt implementation occurs:
> >>> the thread is hardened to handle the ioctl
> >>> ioctl_rt is called which returns -ENOSYS
> >>> the thread is relaxed
> >>> ioctl_nrt is called
> >>>
> >>> It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm
> >>> syscall made by a thread with a shadow, and in fact seems to result in
> >>> as bad a result. Is it really what we want? The __xn_exec_current bit
> >>> resulted in a more lazy behaviour.
> >>>
> >>> Also note that, at least when using the posix skin, almost all threads
> >>> have shadows, and only the priority makes the difference between a
> >>> really critical thread, and non critical threads with the null priority.
> >>> So, this will happen all the time.
> >> Right. Actually, we only need the conforming property for the (fairly
> >> rare) case that a service is provided in both flavors.
> > 
> > Wrong. You want conforming because real-time is the preferred mode of
> > operations for real-time threads.
> 
> Sorry, wrong as well. :)
> 
> Setup/reconfiguration phases happening over already shadowed threads can
> suffer significantly when playing ping-pong via mode switches. That's
> why threads stay in secondary mode after their first Linux syscall and
> are not immediately switched back.

I decided to implement lazy switch in that case because it made sense
not to add overhead when it is not needed. The situation you describe is
a code that actually cares for an extra switch at the expense of a
proper design, by imposing a lot of mode switches in tight loops. Please
fix the app, not the core, really.

> 
> Jan
> 
> > 
> >>  And if such a
> >> service is hidden behind a single IOCTL command, it's even not possible
> >> to detect this at RTDM level. We do need help from the driver or its
> >> user space library, or we need to give them the tools to do the adaptive
> >> switch themselves.
> >>
> >> So three options:
> >>  - Implement adaptive switching inside RTDM
> >>     o For all major functions != ioctl, we need to check for a shadow
> >>       thread and the availability of an RT handler => switch
> >>     o For IOCTLs we need an extra bit, likely in the IOC_TYPE namespace
> >>       to indicate the availability of an RT handler. This comes at the
> >>       risk of colliding with existing drivers that do not use the
> >>       standard IOCTL encoding scheme.
> >>  - Push adaptive switching into the driver
> >>     o That means providing the information if the caller could be
> >>       switched to RT context.
> >>  - Push adaptive switching into the helper library
> >>     o That means exporting a service that performs a switch if the
> >>       caller is switchable, but currently relaxed.
> >>
> >> The second option is the least invasive one, I think. The first one is
> >> most transparent, but also more fragile and complex than the rest. Three
> >> is likely not Philippe's favorite as it would introduce yet another
> >> explicit mode switching mechanism.
> >>
> >> Opinions? Other ideas?
> >>
> >> Jan
> >>
> > 
> > 
> 
> 


-- 
Philippe.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 7729 bytes --]

Philippe Gerum wrote:
> On Thu, 2010-04-01 at 23:26 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Thu, 2010-04-01 at 23:13 +0200, Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> Philippe Gerum wrote:
>>>>>> 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.
>>>>> Argh.... The switchtest driver is relying on __xn_exec_current to have
>>>>> context switches occur precisely in the mode we want. __xn_exec_adaptive
>>>>> introduce more context switches around which we can not place separate
>>>>> checks for fpu context, so, in short, breaks it badly. Fixing this
>>>>> requires turning the switchtest driver into a skin with its own syscalls.
>>>>>
>>>>> Note the sequence which occurs when a shadowed thread running in
>>>>> secondary mode calls an ioctl for which only an nrt implementation occurs:
>>>>> the thread is hardened to handle the ioctl
>>>>> ioctl_rt is called which returns -ENOSYS
>>>>> the thread is relaxed
>>>>> ioctl_nrt is called
>>>>>
>>>>> It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm
>>>>> syscall made by a thread with a shadow, and in fact seems to result in
>>>>> as bad a result. Is it really what we want? The __xn_exec_current bit
>>>>> resulted in a more lazy behaviour.
>>>>>
>>>>> Also note that, at least when using the posix skin, almost all threads
>>>>> have shadows, and only the priority makes the difference between a
>>>>> really critical thread, and non critical threads with the null priority.
>>>>> So, this will happen all the time.
>>>> Right. Actually, we only need the conforming property for the (fairly
>>>> rare) case that a service is provided in both flavors.
>>> Wrong. You want conforming because real-time is the preferred mode of
>>> operations for real-time threads.
>> Sorry, wrong as well. :)
>>
>> Setup/reconfiguration phases happening over already shadowed threads can
>> suffer significantly when playing ping-pong via mode switches. That's
>> why threads stay in secondary mode after their first Linux syscall and
>> are not immediately switched back.
> 
> I decided to implement lazy switch in that case because it made sense
> not to add overhead when it is not needed. The situation you describe is
> a code that actually cares for an extra switch at the expense of a
> proper design, by imposing a lot of mode switches in tight loops. Please
> fix the app, not the core, really.

You still assume that there aren't many non-RT services provided by an
RTDM driver. That's true - for some drivers. It's totally wrong for
others. RTDM simply doesn't know this.

The core was designed for flexibility - as it has to deal with all those
kinds of drivers. So the best decision here is to give control back to
the driver, not try to be overly clever at the most generic point in RTDM.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-help] Analogy cmd_write example explanation

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-help] Analogy cmd_write example explanation

[Philippe Gerum]

On Thu, 2010-04-01 at 23:36 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Thu, 2010-04-01 at 23:26 +0200, Jan Kiszka wrote:
> >> Philippe Gerum wrote:
> >>> On Thu, 2010-04-01 at 23:13 +0200, Jan Kiszka wrote:
> >>>> Gilles Chanteperdrix wrote:
> >>>>> Philippe Gerum wrote:
> >>>>>> 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.
> >>>>> Argh.... The switchtest driver is relying on __xn_exec_current to have
> >>>>> context switches occur precisely in the mode we want. __xn_exec_adaptive
> >>>>> introduce more context switches around which we can not place separate
> >>>>> checks for fpu context, so, in short, breaks it badly. Fixing this
> >>>>> requires turning the switchtest driver into a skin with its own syscalls.
> >>>>>
> >>>>> Note the sequence which occurs when a shadowed thread running in
> >>>>> secondary mode calls an ioctl for which only an nrt implementation occurs:
> >>>>> the thread is hardened to handle the ioctl
> >>>>> ioctl_rt is called which returns -ENOSYS
> >>>>> the thread is relaxed
> >>>>> ioctl_nrt is called
> >>>>>
> >>>>> It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm
> >>>>> syscall made by a thread with a shadow, and in fact seems to result in
> >>>>> as bad a result. Is it really what we want? The __xn_exec_current bit
> >>>>> resulted in a more lazy behaviour.
> >>>>>
> >>>>> Also note that, at least when using the posix skin, almost all threads
> >>>>> have shadows, and only the priority makes the difference between a
> >>>>> really critical thread, and non critical threads with the null priority.
> >>>>> So, this will happen all the time.
> >>>> Right. Actually, we only need the conforming property for the (fairly
> >>>> rare) case that a service is provided in both flavors.
> >>> Wrong. You want conforming because real-time is the preferred mode of
> >>> operations for real-time threads.
> >> Sorry, wrong as well. :)
> >>
> >> Setup/reconfiguration phases happening over already shadowed threads can
> >> suffer significantly when playing ping-pong via mode switches. That's
> >> why threads stay in secondary mode after their first Linux syscall and
> >> are not immediately switched back.
> > 
> > I decided to implement lazy switch in that case because it made sense
> > not to add overhead when it is not needed. The situation you describe is
> > a code that actually cares for an extra switch at the expense of a
> > proper design, by imposing a lot of mode switches in tight loops. Please
> > fix the app, not the core, really.
> 
> You still assume that there aren't many non-RT services provided by an
> RTDM driver. That's true - for some drivers. It's totally wrong for
> others. RTDM simply doesn't know this.
> 
> The core was designed for flexibility - as it has to deal with all those
> kinds of drivers. So the best decision here is to give control back to
> the driver, not try to be overly clever at the most generic point in RTDM.
> 

It's not about being clever, /me can't do that magic anyway. But, this
is about ensuring that people, who don't necessarily understand how the
innards of the underlying co-kernel work, do benefit from the principle
of least surprise. And using conforming calls for drivers - which may
expose a given syscall to different kind of threads (e.g. Analogy) - is,
at least on the paper, the best option.

The bottom line for me, is that T_PRIMARY, as a user-space visible
"feature" should be dropped at some point, and never ever considered as
a way to fix the RTDM syscall issue anymore. I don't mind saving an
extra-context switch even in what I think should be _rare_ cases, but
this has to be done in a way that does not introduce the same kind of
misunderstanding the eager mode switching allowed by rt_task_set_mode()
did in the past.

Really, I'm convinced that an awful lot of people are currently running
under-performing at best, or even broken applications today, because of
that, thing.

> Jan
> 


-- 
Philippe.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

Gilles Chanteperdrix wrote:
> ...
> Argh.... The switchtest driver is relying on __xn_exec_current to have
> context switches occur precisely in the mode we want. __xn_exec_adaptive
> introduce more context switches around which we can not place separate
> checks for fpu context, so, in short, breaks it badly. Fixing this
> requires turning the switchtest driver into a skin with its own syscalls.

Independent of how switchtest (or RTDM) is fixed again: Do you already
have a patch like this in your queue?

diff --git a/ksrc/drivers/testing/switchtest.c b/ksrc/drivers/testing/switchtest.c
index 057094b..09cd0ec 100644
--- a/ksrc/drivers/testing/switchtest.c
+++ b/ksrc/drivers/testing/switchtest.c
@@ -665,6 +665,9 @@ static int rtswitch_ioctl_rt(struct rtdm_dev_context *context,
 	struct rttst_swtest_dir fromto;
 
 	switch (request) {
+	case RTTST_RTIOC_SWTEST_SET_TASKS_COUNT:
+	case RTTST_RTIOC_SWTEST_SET_CPU:
+	case RTTST_RTIOC_SWTEST_SET_PAUSE:
 	case RTTST_RTIOC_SWTEST_REGISTER_UTASK:
 	case RTTST_RTIOC_SWTEST_CREATE_KTASK:
 	case RTTST_RTIOC_SWTEST_GET_SWITCHES_COUNT:

I.e. add the missing reflections of NRT IOCTLs.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-help] Analogy cmd_write example explanation

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> ...
>> Argh.... The switchtest driver is relying on __xn_exec_current to have
>> context switches occur precisely in the mode we want. __xn_exec_adaptive
>> introduce more context switches around which we can not place separate
>> checks for fpu context, so, in short, breaks it badly. Fixing this
>> requires turning the switchtest driver into a skin with its own syscalls.
> 
> Independent of how switchtest (or RTDM) is fixed again: Do you already
> have a patch like this in your queue?
> 
> diff --git a/ksrc/drivers/testing/switchtest.c b/ksrc/drivers/testing/switchtest.c
> index 057094b..09cd0ec 100644
> --- a/ksrc/drivers/testing/switchtest.c
> +++ b/ksrc/drivers/testing/switchtest.c
> @@ -665,6 +665,9 @@ static int rtswitch_ioctl_rt(struct rtdm_dev_context *context,
>  	struct rttst_swtest_dir fromto;
>  
>  	switch (request) {
> +	case RTTST_RTIOC_SWTEST_SET_TASKS_COUNT:
> +	case RTTST_RTIOC_SWTEST_SET_CPU:
> +	case RTTST_RTIOC_SWTEST_SET_PAUSE:
>  	case RTTST_RTIOC_SWTEST_REGISTER_UTASK:
>  	case RTTST_RTIOC_SWTEST_CREATE_KTASK:
>  	case RTTST_RTIOC_SWTEST_GET_SWITCHES_COUNT:
> 
> I.e. add the missing reflections of NRT IOCTLs.

Yes, I had this fix in my tree. But switchtest is broken not only for
this reason. I am just waiting what will be decided with regard to the
two mode switches when calling an nrt ioctl from a shadowed thread
running in secondary mode, to implement a complete fix (most probably
rewriting it as a skin).

-- 
					    Gilles.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 9478 bytes --]

Philippe Gerum wrote:
> On Thu, 2010-04-01 at 23:36 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Thu, 2010-04-01 at 23:26 +0200, Jan Kiszka wrote:
>>>> Philippe Gerum wrote:
>>>>> On Thu, 2010-04-01 at 23:13 +0200, Jan Kiszka wrote:
>>>>>> Gilles Chanteperdrix wrote:
>>>>>>> Philippe Gerum wrote:
>>>>>>>> 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.
>>>>>>> Argh.... The switchtest driver is relying on __xn_exec_current to have
>>>>>>> context switches occur precisely in the mode we want. __xn_exec_adaptive
>>>>>>> introduce more context switches around which we can not place separate
>>>>>>> checks for fpu context, so, in short, breaks it badly. Fixing this
>>>>>>> requires turning the switchtest driver into a skin with its own syscalls.
>>>>>>>
>>>>>>> Note the sequence which occurs when a shadowed thread running in
>>>>>>> secondary mode calls an ioctl for which only an nrt implementation occurs:
>>>>>>> the thread is hardened to handle the ioctl
>>>>>>> ioctl_rt is called which returns -ENOSYS
>>>>>>> the thread is relaxed
>>>>>>> ioctl_nrt is called
>>>>>>>
>>>>>>> It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm
>>>>>>> syscall made by a thread with a shadow, and in fact seems to result in
>>>>>>> as bad a result. Is it really what we want? The __xn_exec_current bit
>>>>>>> resulted in a more lazy behaviour.
>>>>>>>
>>>>>>> Also note that, at least when using the posix skin, almost all threads
>>>>>>> have shadows, and only the priority makes the difference between a
>>>>>>> really critical thread, and non critical threads with the null priority.
>>>>>>> So, this will happen all the time.
>>>>>> Right. Actually, we only need the conforming property for the (fairly
>>>>>> rare) case that a service is provided in both flavors.
>>>>> Wrong. You want conforming because real-time is the preferred mode of
>>>>> operations for real-time threads.
>>>> Sorry, wrong as well. :)
>>>>
>>>> Setup/reconfiguration phases happening over already shadowed threads can
>>>> suffer significantly when playing ping-pong via mode switches. That's
>>>> why threads stay in secondary mode after their first Linux syscall and
>>>> are not immediately switched back.
>>> I decided to implement lazy switch in that case because it made sense
>>> not to add overhead when it is not needed. The situation you describe is
>>> a code that actually cares for an extra switch at the expense of a
>>> proper design, by imposing a lot of mode switches in tight loops. Please
>>> fix the app, not the core, really.
>> You still assume that there aren't many non-RT services provided by an
>> RTDM driver. That's true - for some drivers. It's totally wrong for
>> others. RTDM simply doesn't know this.
>>
>> The core was designed for flexibility - as it has to deal with all those
>> kinds of drivers. So the best decision here is to give control back to
>> the driver, not try to be overly clever at the most generic point in RTDM.
>>
> 
> It's not about being clever, /me can't do that magic anyway. But, this
> is about ensuring that people, who don't necessarily understand how the
> innards of the underlying co-kernel work, do benefit from the principle
> of least surprise. And using conforming calls for drivers - which may
> expose a given syscall to different kind of threads (e.g. Analogy) - is,
> at least on the paper, the best option.
> 
> The bottom line for me, is that T_PRIMARY, as a user-space visible
> "feature" should be dropped at some point, and never ever considered as
> a way to fix the RTDM syscall issue anymore. I don't mind saving an
> extra-context switch even in what I think should be _rare_ cases, but
> this has to be done in a way that does not introduce the same kind of
> misunderstanding the eager mode switching allowed by rt_task_set_mode()
> did in the past.
> 
> Really, I'm convinced that an awful lot of people are currently running
> under-performing at best, or even broken applications today, because of
> that, thing.

We are not discussing T_PRIMARY here. We are discussing something like
an "rtdm_is_rt_capable()" addition for those _few_ RTDM drivers that
actually want to provide Ianus-like services.

I'm fairly convinced now that solving that corner-case via conforming
syscalls for _all_ RTDM services, thus _all_ drivers, is the wrong path.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-help] Analogy cmd_write example explanation

[Philippe Gerum]

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.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Philippe Gerum]

On Thu, 2010-04-01 at 23:54 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Thu, 2010-04-01 at 23:36 +0200, Jan Kiszka wrote:
> >> Philippe Gerum wrote:
> >>> On Thu, 2010-04-01 at 23:26 +0200, Jan Kiszka wrote:
> >>>> Philippe Gerum wrote:
> >>>>> On Thu, 2010-04-01 at 23:13 +0200, Jan Kiszka wrote:
> >>>>>> Gilles Chanteperdrix wrote:
> >>>>>>> Philippe Gerum wrote:
> >>>>>>>> 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.
> >>>>>>> Argh.... The switchtest driver is relying on __xn_exec_current to have
> >>>>>>> context switches occur precisely in the mode we want. __xn_exec_adaptive
> >>>>>>> introduce more context switches around which we can not place separate
> >>>>>>> checks for fpu context, so, in short, breaks it badly. Fixing this
> >>>>>>> requires turning the switchtest driver into a skin with its own syscalls.
> >>>>>>>
> >>>>>>> Note the sequence which occurs when a shadowed thread running in
> >>>>>>> secondary mode calls an ioctl for which only an nrt implementation occurs:
> >>>>>>> the thread is hardened to handle the ioctl
> >>>>>>> ioctl_rt is called which returns -ENOSYS
> >>>>>>> the thread is relaxed
> >>>>>>> ioctl_nrt is called
> >>>>>>>
> >>>>>>> It boils down to putting an rt_task_set_mode(PRIMARY) before each rtdm
> >>>>>>> syscall made by a thread with a shadow, and in fact seems to result in
> >>>>>>> as bad a result. Is it really what we want? The __xn_exec_current bit
> >>>>>>> resulted in a more lazy behaviour.
> >>>>>>>
> >>>>>>> Also note that, at least when using the posix skin, almost all threads
> >>>>>>> have shadows, and only the priority makes the difference between a
> >>>>>>> really critical thread, and non critical threads with the null priority.
> >>>>>>> So, this will happen all the time.
> >>>>>> Right. Actually, we only need the conforming property for the (fairly
> >>>>>> rare) case that a service is provided in both flavors.
> >>>>> Wrong. You want conforming because real-time is the preferred mode of
> >>>>> operations for real-time threads.
> >>>> Sorry, wrong as well. :)
> >>>>
> >>>> Setup/reconfiguration phases happening over already shadowed threads can
> >>>> suffer significantly when playing ping-pong via mode switches. That's
> >>>> why threads stay in secondary mode after their first Linux syscall and
> >>>> are not immediately switched back.
> >>> I decided to implement lazy switch in that case because it made sense
> >>> not to add overhead when it is not needed. The situation you describe is
> >>> a code that actually cares for an extra switch at the expense of a
> >>> proper design, by imposing a lot of mode switches in tight loops. Please
> >>> fix the app, not the core, really.
> >> You still assume that there aren't many non-RT services provided by an
> >> RTDM driver. That's true - for some drivers. It's totally wrong for
> >> others. RTDM simply doesn't know this.
> >>
> >> The core was designed for flexibility - as it has to deal with all those
> >> kinds of drivers. So the best decision here is to give control back to
> >> the driver, not try to be overly clever at the most generic point in RTDM.
> >>
> > 
> > It's not about being clever, /me can't do that magic anyway. But, this
> > is about ensuring that people, who don't necessarily understand how the
> > innards of the underlying co-kernel work, do benefit from the principle
> > of least surprise. And using conforming calls for drivers - which may
> > expose a given syscall to different kind of threads (e.g. Analogy) - is,
> > at least on the paper, the best option.
> > 
> > The bottom line for me, is that T_PRIMARY, as a user-space visible
> > "feature" should be dropped at some point, and never ever considered as
> > a way to fix the RTDM syscall issue anymore. I don't mind saving an
> > extra-context switch even in what I think should be _rare_ cases, but
> > this has to be done in a way that does not introduce the same kind of
> > misunderstanding the eager mode switching allowed by rt_task_set_mode()
> > did in the past.
> > 
> > Really, I'm convinced that an awful lot of people are currently running
> > under-performing at best, or even broken applications today, because of
> > that, thing.
> 
> We are not discussing T_PRIMARY here. We are discussing something like
> an "rtdm_is_rt_capable()" addition for those _few_ RTDM drivers that
> actually want to provide Ianus-like services.
> 

Yes, we do discuss of T_PRIMARY in between the lines.

> I'm fairly convinced now that solving that corner-case via conforming
> syscalls for _all_ RTDM services, thus _all_ drivers, is the wrong path.
> 
> Jan
> 


-- 
Philippe.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

Philippe Gerum wrote:
> On Thu, 2010-04-01 at 23:54 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> The bottom line for me, is that T_PRIMARY, as a user-space visible
>>> "feature" should be dropped at some point, and never ever considered as
>>> a way to fix the RTDM syscall issue anymore. I don't mind saving an
>>> extra-context switch even in what I think should be _rare_ cases, but
>>> this has to be done in a way that does not introduce the same kind of
>>> misunderstanding the eager mode switching allowed by rt_task_set_mode()
>>> did in the past.
>>>
>>> Really, I'm convinced that an awful lot of people are currently running
>>> under-performing at best, or even broken applications today, because of
>>> that, thing.
>> We are not discussing T_PRIMARY here. We are discussing something like
>> an "rtdm_is_rt_capable()" addition for those _few_ RTDM drivers that
>> actually want to provide Ianus-like services.
>>
> 
> Yes, we do discuss of T_PRIMARY in between the lines.
> 

You can take it away, and the rtdm_is_rt_capable-approach would still
work, but that without affecting existing designs.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-help] Analogy cmd_write example explanation

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2507 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-help] Analogy cmd_write example explanation

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Philippe Gerum wrote:
>> On Thu, 2010-04-01 at 23:54 +0200, Jan Kiszka wrote:
>>> Philippe Gerum wrote:
>>>> The bottom line for me, is that T_PRIMARY, as a user-space visible
>>>> "feature" should be dropped at some point, and never ever considered as
>>>> a way to fix the RTDM syscall issue anymore. I don't mind saving an
>>>> extra-context switch even in what I think should be _rare_ cases, but
>>>> this has to be done in a way that does not introduce the same kind of
>>>> misunderstanding the eager mode switching allowed by rt_task_set_mode()
>>>> did in the past.
>>>>
>>>> Really, I'm convinced that an awful lot of people are currently running
>>>> under-performing at best, or even broken applications today, because of
>>>> that, thing.
>>> We are not discussing T_PRIMARY here. We are discussing something like
>>> an "rtdm_is_rt_capable()" addition for those _few_ RTDM drivers that
>>> actually want to provide Ianus-like services.
>>>
>> Yes, we do discuss of T_PRIMARY in between the lines.
>>
> 
> You can take it away, and the rtdm_is_rt_capable-approach would still
> work, but that without affecting existing designs.

Ok. I almost regret I launched this troll. We have discussed some time
with Philippe, and I agree with him that drivers which this change
really broke were already broken. The only side-effect is the double
switch issue, which, per-se is not that much a trouble in real-world
applications. So what I propose is a special RTDM driver flag that would
somehow fix the issue for the switchtest driver, and would only be used
by that driver and not exported in the rtdm headers, and of course not
documented.

-- 
					    Gilles.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Thu, 2010-04-01 at 23:54 +0200, Jan Kiszka wrote:
>>>> Philippe Gerum wrote:
>>>>> The bottom line for me, is that T_PRIMARY, as a user-space visible
>>>>> "feature" should be dropped at some point, and never ever considered as
>>>>> a way to fix the RTDM syscall issue anymore. I don't mind saving an
>>>>> extra-context switch even in what I think should be _rare_ cases, but
>>>>> this has to be done in a way that does not introduce the same kind of
>>>>> misunderstanding the eager mode switching allowed by rt_task_set_mode()
>>>>> did in the past.
>>>>>
>>>>> Really, I'm convinced that an awful lot of people are currently running
>>>>> under-performing at best, or even broken applications today, because of
>>>>> that, thing.
>>>> We are not discussing T_PRIMARY here. We are discussing something like
>>>> an "rtdm_is_rt_capable()" addition for those _few_ RTDM drivers that
>>>> actually want to provide Ianus-like services.
>>>>
>>> Yes, we do discuss of T_PRIMARY in between the lines.
>>>
>> You can take it away, and the rtdm_is_rt_capable-approach would still
>> work, but that without affecting existing designs.
> 
> Ok. I almost regret I launched this troll. We have discussed some time
> with Philippe, and I agree with him that drivers which this change
> really broke were already broken. The only side-effect is the double
> switch issue, which, per-se is not that much a trouble in real-world
> applications. So what I propose is a special RTDM driver flag that would
> somehow fix the issue for the switchtest driver, and would only be used
> by that driver and not exported in the rtdm headers, and of course not
> documented.
> 

No, I'm queuing rtdm_rt_capable() + a revert of the __xn_exec_conforming
commit now. That's way less surprising for existing drivers and still
does not require user land to fiddle with the mode. All can be handled
at driver level (ie. in Analogy, obviously the only driver that needs it
so far).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-help] Analogy cmd_write example explanation

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Philippe Gerum wrote:
>>>> On Thu, 2010-04-01 at 23:54 +0200, Jan Kiszka wrote:
>>>>> Philippe Gerum wrote:
>>>>>> The bottom line for me, is that T_PRIMARY, as a user-space visible
>>>>>> "feature" should be dropped at some point, and never ever considered as
>>>>>> a way to fix the RTDM syscall issue anymore. I don't mind saving an
>>>>>> extra-context switch even in what I think should be _rare_ cases, but
>>>>>> this has to be done in a way that does not introduce the same kind of
>>>>>> misunderstanding the eager mode switching allowed by rt_task_set_mode()
>>>>>> did in the past.
>>>>>>
>>>>>> Really, I'm convinced that an awful lot of people are currently running
>>>>>> under-performing at best, or even broken applications today, because of
>>>>>> that, thing.
>>>>> We are not discussing T_PRIMARY here. We are discussing something like
>>>>> an "rtdm_is_rt_capable()" addition for those _few_ RTDM drivers that
>>>>> actually want to provide Ianus-like services.
>>>>>
>>>> Yes, we do discuss of T_PRIMARY in between the lines.
>>>>
>>> You can take it away, and the rtdm_is_rt_capable-approach would still
>>> work, but that without affecting existing designs.
>> Ok. I almost regret I launched this troll. We have discussed some time
>> with Philippe, and I agree with him that drivers which this change
>> really broke were already broken. The only side-effect is the double
>> switch issue, which, per-se is not that much a trouble in real-world
>> applications. So what I propose is a special RTDM driver flag that would
>> somehow fix the issue for the switchtest driver, and would only be used
>> by that driver and not exported in the rtdm headers, and of course not
>> documented.
>>
> 
> No, I'm queuing rtdm_rt_capable() + a revert of the __xn_exec_conforming
> commit now. That's way less surprising for existing drivers and still
> does not require user land to fiddle with the mode. All can be handled
> at driver level (ie. in Analogy, obviously the only driver that needs it
> so far).

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.

What we are left to fix is the corner case of switchtest.


-- 
					    Gilles.

Re: [Xenomai-help] Analogy cmd_write example explanation

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3316 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Philippe Gerum wrote:
>>>>> On Thu, 2010-04-01 at 23:54 +0200, Jan Kiszka wrote:
>>>>>> Philippe Gerum wrote:
>>>>>>> The bottom line for me, is that T_PRIMARY, as a user-space visible
>>>>>>> "feature" should be dropped at some point, and never ever considered as
>>>>>>> a way to fix the RTDM syscall issue anymore. I don't mind saving an
>>>>>>> extra-context switch even in what I think should be _rare_ cases, but
>>>>>>> this has to be done in a way that does not introduce the same kind of
>>>>>>> misunderstanding the eager mode switching allowed by rt_task_set_mode()
>>>>>>> did in the past.
>>>>>>>
>>>>>>> Really, I'm convinced that an awful lot of people are currently running
>>>>>>> under-performing at best, or even broken applications today, because of
>>>>>>> that, thing.
>>>>>> We are not discussing T_PRIMARY here. We are discussing something like
>>>>>> an "rtdm_is_rt_capable()" addition for those _few_ RTDM drivers that
>>>>>> actually want to provide Ianus-like services.
>>>>>>
>>>>> Yes, we do discuss of T_PRIMARY in between the lines.
>>>>>
>>>> You can take it away, and the rtdm_is_rt_capable-approach would still
>>>> work, but that without affecting existing designs.
>>> Ok. I almost regret I launched this troll. We have discussed some time
>>> with Philippe, and I agree with him that drivers which this change
>>> really broke were already broken. The only side-effect is the double
>>> switch issue, which, per-se is not that much a trouble in real-world
>>> applications. So what I propose is a special RTDM driver flag that would
>>> somehow fix the issue for the switchtest driver, and would only be used
>>> by that driver and not exported in the rtdm headers, and of course not
>>> documented.
>>>
>> No, I'm queuing rtdm_rt_capable() + a revert of the __xn_exec_conforming
>> commit now. That's way less surprising for existing drivers and still
>> does not require user land to fiddle with the mode. All can be handled
>> at driver level (ie. in Analogy, obviously the only driver that needs it
>> so far).
> 
> 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. RTDM has insufficient
knowledge about what the drivers will, how many RT and how may non-RT
calls they will provide and what load pattern user space will apply on
this. RTDM can only mediate based on the available information.

The T_PRIMARY issue has to be solved be removing that feature, not by
changing RTDM.

> 
> What we are left to fix is the corner case of switchtest.
> 

...and the performance degeneration of Analogy when used with a plain
Linux tasks - part of the scenario that started this whole discussion.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

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

[Gilles Chanteperdrix]

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.

-- 
					    Gilles.

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

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.

The decision about conforming switches is really only driver business.
RTDM can only support the driver by providing all required information.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

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

[Gilles Chanteperdrix]

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. If those threads perform lots
of non-RT service requests on RTDM drivers at a critical time and exoect
their execution time to be bounded, then you are wrong, because you can
not expect any non real-time service to have a bounded execution time
anyway.

-- 
					    Gilles.

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

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.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

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

[Philippe Gerum]

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.

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3882 bytes --]

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

Kernel is clear, but user space sounds indeed interesting. I guess we
need an out-of-band channel to tell the kernel about pending
user-space-only lock ownerships when calling some unrelated syscall. How
does your current approach look like?

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

These two still look too complex and inconsistent to grasp.

Let's just keep the kernel ABI, ie. let the kernel still interpret the
bit (maybe now according to your conforming scheme), but drop T_PRIMARY
from the user-visible defines. For the use case of an enforced primary
mode switch-back, add a new service - if it is really required.
rt_task_set_mode is about static property switching, so adding T_PRIMARY
here was already a bad idea from that perspective.

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

Will come with my RTDM queue soon. It's delayed as it became too long,
and something always needs more work or waits for more testing. Maybe I
should start flushing the stable bits.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

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

[Philippe Gerum]

On Wed, 2010-04-14 at 01:05 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > 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.
> 
> Kernel is clear, but user space sounds indeed interesting. I guess we
> need an out-of-band channel to tell the kernel about pending
> user-space-only lock ownerships when calling some unrelated syscall. How
> does your current approach look like?

I want to keep things simple: shadow nrt will go through the syscalls
for acquisition/release of owned resources, instead of fastsynchs.

> 
> > 
> > - 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.
> 
> These two still look too complex and inconsistent to grasp.
> 
> Let's just keep the kernel ABI, ie. let the kernel still interpret the
> bit (maybe now according to your conforming scheme), but drop T_PRIMARY
> from the user-visible defines.

This is exactly what was described: drop T_PRIMARY as a way to fully
control the mode from userland, provide T_CONFORMING as a limited action
to force a switch back to primary for shadow rt.

>  For the use case of an enforced primary
> mode switch-back, add a new service - if it is really required.
> rt_task_set_mode is about static property switching, so adding T_PRIMARY
> here was already a bad idea from that perspective.
> 

There is no such limitation to rt_task_set_mode(), and T_CONFORMING is
not meant to be used blindly. So, I will stick with this interface.

> > 
> > - 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.
> 
> Will come with my RTDM queue soon. It's delayed as it became too long,
> and something always needs more work or waits for more testing. Maybe I
> should start flushing the stable bits.
> 
> Jan
> 


-- 
Philippe.

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 4435 bytes --]

Philippe Gerum wrote:
> On Wed, 2010-04-14 at 01:05 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> 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.
>> Kernel is clear, but user space sounds indeed interesting. I guess we
>> need an out-of-band channel to tell the kernel about pending
>> user-space-only lock ownerships when calling some unrelated syscall. How
>> does your current approach look like?
> 
> I want to keep things simple: shadow nrt will go through the syscalls
> for acquisition/release of owned resources, instead of fastsynchs.

Then I'll have to pick this up as that will very likely create unhappy
customers. In fact, the majority of our Xenomai threads are nrt (yeah,
that happens if you convert existing applications).

> 
>>> - 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.
>> These two still look too complex and inconsistent to grasp.
>>
>> Let's just keep the kernel ABI, ie. let the kernel still interpret the
>> bit (maybe now according to your conforming scheme), but drop T_PRIMARY
>> from the user-visible defines.
> 
> This is exactly what was described: drop T_PRIMARY as a way to fully
> control the mode from userland, provide T_CONFORMING as a limited action
> to force a switch back to primary for shadow rt.

Not exactly: I'm against T_CONFORMING.

> 
>>  For the use case of an enforced primary
>> mode switch-back, add a new service - if it is really required.
>> rt_task_set_mode is about static property switching, so adding T_PRIMARY
>> here was already a bad idea from that perspective.
>>
> 
> There is no such limitation to rt_task_set_mode(), and T_CONFORMING is
> not meant to be used blindly. So, I will stick with this interface.

T_CONFORMING is a mini-me of T_PRIMARY. If we already clean up the
latter, it is a unique chance to finally drop that misplaced interface
from rt_task_set_mode. It's asymmetric and does not really fit into the
"true" modes that this interface controls.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]

Jan Kiszka wrote:
> Philippe Gerum wrote:
>> On Wed, 2010-04-14 at 01:05 +0200, Jan Kiszka wrote:
>>> Philippe Gerum wrote:
>>>> 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.
>>> Kernel is clear, but user space sounds indeed interesting. I guess we
>>> need an out-of-band channel to tell the kernel about pending
>>> user-space-only lock ownerships when calling some unrelated syscall. How
>>> does your current approach look like?
>> I want to keep things simple: shadow nrt will go through the syscalls
>> for acquisition/release of owned resources, instead of fastsynchs.
> 
> Then I'll have to pick this up as that will very likely create unhappy
> customers. In fact, the majority of our Xenomai threads are nrt (yeah,
> that happens if you convert existing applications).

Hmm, thinking about it again, there not that much to optimize in the
trivial, non-nested locking case (on entry, we already go through the
syscall if we aren't migrated yet, just the release syscall will be
new). I will check what share of our load is nested and would actually
suffer from unconditional syscalls. I just hope there is no issue with
dropping the lazy scheme as that would complicate things in a way I
would not want to go as well.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

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

[Gilles Chanteperdrix]

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

This sounds consistent to me, some valid use cases of T_PRIMARY are
preserved without keeping T_PRIMARY entirely.

-- 
					    Gilles.

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

[Philippe Gerum]

On Wed, 2010-04-14 at 09:37 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Wed, 2010-04-14 at 01:05 +0200, Jan Kiszka wrote:
> >> Philippe Gerum wrote:
> >>> 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.
> >> Kernel is clear, but user space sounds indeed interesting. I guess we
> >> need an out-of-band channel to tell the kernel about pending
> >> user-space-only lock ownerships when calling some unrelated syscall. How
> >> does your current approach look like?
> > 
> > I want to keep things simple: shadow nrt will go through the syscalls
> > for acquisition/release of owned resources, instead of fastsynchs.
> 
> Then I'll have to pick this up as that will very likely create unhappy
> customers. In fact, the majority of our Xenomai threads are nrt (yeah,
> that happens if you convert existing applications).

I would understand that people do not want to bother that much with
using the right kind of threads between shadow nrt and plain linux
within the context of an initial port, but at some point, the code
should be made consistent with respect to the real use.

If there is a problem with auto-shadowing in the POSIX skin, or
sched_setscheduler() or whatever, then it should be addressed, but we
just can't pile up code only to satisfy such a corner case, i.e.
situations where applications create Xenomai nrt threads without actual
need for this, to make them run in secondary mode only, without
requiring a single primary-mode service (hence wanting hard to keep
__xn_exec_current for RTDM).

So, I will merge the bits I have in mind as a first step, because they
satisfy the normal usage of Xenomai threads. I will certainly ACK any
improvement to this code which keeps the original fastsynch optimization
for nrt threads, provided the feature/code overhead ratio seems correct.

> 
> > 
> >>> - 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.
> >> These two still look too complex and inconsistent to grasp.
> >>
> >> Let's just keep the kernel ABI, ie. let the kernel still interpret the
> >> bit (maybe now according to your conforming scheme), but drop T_PRIMARY
> >> from the user-visible defines.
> > 
> > This is exactly what was described: drop T_PRIMARY as a way to fully
> > control the mode from userland, provide T_CONFORMING as a limited action
> > to force a switch back to primary for shadow rt.
> 
> Not exactly: I'm against T_CONFORMING.
> 
> > 
> >>  For the use case of an enforced primary
> >> mode switch-back, add a new service - if it is really required.
> >> rt_task_set_mode is about static property switching, so adding T_PRIMARY
> >> here was already a bad idea from that perspective.
> >>
> > 
> > There is no such limitation to rt_task_set_mode(), and T_CONFORMING is
> > not meant to be used blindly. So, I will stick with this interface.
> 
> T_CONFORMING is a mini-me of T_PRIMARY. If we already clean up the
> latter, it is a unique chance to finally drop that misplaced interface
> from rt_task_set_mode. It's asymmetric and does not really fit into the
> "true" modes that this interface controls.
> 

So, basically T_LOCK is a static switch for you? You mean that locking
the scheduler is a static property of any thread? Same for T_NOSIG and
blocking asynchronous calls? Look, I designed this interface after the
pSOS equivalent, and I can assure you that this was indeed meant to be a
mean to control dynamic properties.

Now, T_CONFORMING may please us or not, I won't argue about this. I do
think that having to switch mode eagerly in the context of an
application is the sign that something went wrong at design level
somehow. But, we are currently in the middle of a stable 2.5.x series,
with a requirement to keep the ABI and the (correct) feature set intact
between releases, so the way to fix the T_PRIMARY mess has to be
two-fold:

- Restrict the usage of T_PRIMARY to the only case where it might make
sense in a very limited number of situations. This implies switching
back to the preferred mode of operation for a Xenomai rt thread, so that
syscall-less sections following a secondary mode switch can still be
executed at full rt privileges.

- Remove all other uses of T_PRIMARY, because they are at best useless
and overkill, at worst plain wrong.

To this end, T_PRIMARY becomes T_CONFORMING, and the ABI is kept for the
acceptable case. This allow people NOT to recompile their app if they
were eargerly switching mode for a valid reason, and force others to fix
their applications.

Under normal circumstances, I would not even have suggested to touch the
API in a stable series for feature removal, but the situation wrt RTDM
and the wrong usage of mode switching that obviously started to slip
into our own code base (e.g. Analogy) was a wake up call.

> Jan
> 


-- 
Philippe.

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

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Wed, 2010-04-14 at 09:37 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Wed, 2010-04-14 at 01:05 +0200, Jan Kiszka wrote:
>>>> Philippe Gerum wrote:
>>>>> 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.
>>>> Kernel is clear, but user space sounds indeed interesting. I guess we
>>>> need an out-of-band channel to tell the kernel about pending
>>>> user-space-only lock ownerships when calling some unrelated syscall. How
>>>> does your current approach look like?
>>> I want to keep things simple: shadow nrt will go through the syscalls
>>> for acquisition/release of owned resources, instead of fastsynchs.
>> Then I'll have to pick this up as that will very likely create unhappy
>> customers. In fact, the majority of our Xenomai threads are nrt (yeah,
>> that happens if you convert existing applications).
> 
> I would understand that people do not want to bother that much with
> using the right kind of threads between shadow nrt and plain linux
> within the context of an initial port, but at some point, the code
> should be made consistent with respect to the real use.
> 
> If there is a problem with auto-shadowing in the POSIX skin, or
> sched_setscheduler() or whatever, then it should be addressed, but we
> just can't pile up code only to satisfy such a corner case, i.e.
> situations where applications create Xenomai nrt threads without actual
> need for this, to make them run in secondary mode only, without
> requiring a single primary-mode service (hence wanting hard to keep
> __xn_exec_current for RTDM).
> 
> So, I will merge the bits I have in mind as a first step, because they
> satisfy the normal usage of Xenomai threads. I will certainly ACK any
> improvement to this code which keeps the original fastsynch optimization
> for nrt threads, provided the feature/code overhead ratio seems correct.

I agree. Let us have your solution merged first, to get to a less
troublesome situation (my concern is about switchtest, I am a bit
selfish, but switchtest just helped me again solving FPU issues).

Optimizations can be taken care of later, especially when we are talking
about optimization of shadowed non real-time threads, good performances
for them is a nice-to-have, not our primary concern.

-- 
					    Gilles.

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

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3620 bytes --]

Philippe Gerum wrote:
> On Wed, 2010-04-14 at 09:37 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>> On Wed, 2010-04-14 at 01:05 +0200, Jan Kiszka wrote:
>>>> Philippe Gerum wrote:
>>>>> 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.
>>>> Kernel is clear, but user space sounds indeed interesting. I guess we
>>>> need an out-of-band channel to tell the kernel about pending
>>>> user-space-only lock ownerships when calling some unrelated syscall. How
>>>> does your current approach look like?
>>> I want to keep things simple: shadow nrt will go through the syscalls
>>> for acquisition/release of owned resources, instead of fastsynchs.
>> Then I'll have to pick this up as that will very likely create unhappy
>> customers. In fact, the majority of our Xenomai threads are nrt (yeah,
>> that happens if you convert existing applications).
> 
> I would understand that people do not want to bother that much with
> using the right kind of threads between shadow nrt and plain linux
> within the context of an initial port, but at some point, the code
> should be made consistent with respect to the real use.
> 
> If there is a problem with auto-shadowing in the POSIX skin, or
> sched_setscheduler() or whatever, then it should be addressed, but we
> just can't pile up code only to satisfy such a corner case, i.e.
> situations where applications create Xenomai nrt threads without actual
> need for this, to make them run in secondary mode only, without
> requiring a single primary-mode service (hence wanting hard to keep
> __xn_exec_current for RTDM).

The scenario is not that simple - unfortunately.

> 
> So, I will merge the bits I have in mind as a first step, because they
> satisfy the normal usage of Xenomai threads. I will certainly ACK any
> improvement to this code which keeps the original fastsynch optimization
> for nrt threads, provided the feature/code overhead ratio seems correct.

Fine with me.

>>>>  For the use case of an enforced primary
>>>> mode switch-back, add a new service - if it is really required.
>>>> rt_task_set_mode is about static property switching, so adding T_PRIMARY
>>>> here was already a bad idea from that perspective.
>>>>
>>> There is no such limitation to rt_task_set_mode(), and T_CONFORMING is
>>> not meant to be used blindly. So, I will stick with this interface.
>> T_CONFORMING is a mini-me of T_PRIMARY. If we already clean up the
>> latter, it is a unique chance to finally drop that misplaced interface
>> from rt_task_set_mode. It's asymmetric and does not really fit into the
>> "true" modes that this interface controls.
>>
> 
> So, basically T_LOCK is a static switch for you? You mean that locking
> the scheduler is a static property of any thread? Same for T_NOSIG and
> blocking asynchronous calls? Look, I designed this interface after the
> pSOS equivalent, and I can assure you that this was indeed meant to be a
> mean to control dynamic properties.

Those modes are not static but they can be applied symmetrically and do
not change due to other influences.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]