Discussions about configuration, compilation or installation of Xenomai, as well as common usage of its features and interfaces. ()

Jan Kiszka | 1 Apr 2010 23:13

Picon

Re: Analogy cmd_write example explanation

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?

(Continue reading)

Philippe Gerum | 1 Apr 2010 23:22

Re: Analogy cmd_write example explanation

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

(Continue reading)

Jan Kiszka | 1 Apr 2010 23:26

Picon

Re: Analogy cmd_write example explanation

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

(Continue reading)

Philippe Gerum | 1 Apr 2010 23:31

Re: Analogy cmd_write example explanation

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

(Continue reading)

Jan Kiszka | 1 Apr 2010 23:36

Picon

Re: Analogy cmd_write example explanation

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

(Continue reading)

Philippe Gerum | 1 Apr 2010 23:48

Re: Analogy cmd_write example explanation

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

(Continue reading)

Jan Kiszka | 1 Apr 2010 23:54

Picon

Re: Analogy cmd_write example explanation

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

(Continue reading)

Philippe Gerum | 2 Apr 2010 00:00

Re: Analogy cmd_write example explanation

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

(Continue reading)

Jan Kiszka | 2 Apr 2010 00:07

Picon

Re: Analogy cmd_write example explanation

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

_______________________________________________

(Continue reading)

Gilles Chanteperdrix | 2 Apr 2010 00:53

Re: Analogy cmd_write example explanation

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

(Continue reading)

Jan Kiszka | 2 Apr 2010 00:58

Picon

Re: Analogy cmd_write example explanation

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

(Continue reading)

Gilles Chanteperdrix | 2 Apr 2010 01:08

Re: Analogy cmd_write example explanation

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

(Continue reading)

Jan Kiszka | 2 Apr 2010 02:04

Picon

Re: Analogy cmd_write example explanation

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

(Continue reading)

Gilles Chanteperdrix | 2 Apr 2010 12:39

Re: [Xenomai-help] Analogy cmd_write example explanation

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.

Jan Kiszka | 2 Apr 2010 13:11

Picon

Re: [Xenomai-help] Analogy cmd_write example explanation

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.

(Continue reading)

Gilles Chanteperdrix | 2 Apr 2010 13:14

Re: [Xenomai-help] Analogy cmd_write example explanation

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

(Continue reading)

Jan Kiszka | 2 Apr 2010 13:28

Picon

Re: [Xenomai-help] Analogy cmd_write example explanation

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.

(Continue reading)

Philippe Gerum | 13 Apr 2010 22:41

Re: [Xenomai-help] Analogy cmd_write example explanation

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

(Continue reading)

Jan Kiszka | 14 Apr 2010 01:05

Picon

Re: [Xenomai-help] Analogy cmd_write example explanation

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

(Continue reading)

Philippe Gerum | 14 Apr 2010 09:22

Re: [Xenomai-help] Analogy cmd_write example explanation

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

(Continue reading)

Gilles Chanteperdrix | 14 Apr 2010 10:24

Re: [Xenomai-help] Analogy cmd_write example explanation

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

(Continue reading)

Return

Return to gmane.linux.real-time.xenomai.users.

Project Web Page

Discussions about configuration, compilation or installation of Xenomai, as well as common usage of its features and interfaces. ()

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane