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
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core