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 Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core