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: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to