Re: [Xenomai-help] Analogy cmd_write example explanation

[Jan Kiszka <jan.kiszka@domain.hid>]

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