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.

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

Reply via email to