Didn't see any reference of it in https://xenomai.org/documentation/xenomai-3/html/MIGRATION (?)
regards Le ven. 20 sept. 2019 à 16:23, Pierre FICHEUX <[email protected]> a écrit : > Thx for the answer bu I don't understand the first sentence (because of > my bad english :)) > > What dou you mean with "Xenomai 3 prefers the RT patch of a RTDM callback > over the NRT if the caller is > a real-time task." ? What is a "patch of RTDM callback" ?? > > Le ven. 20 sept. 2019 à 15:45, Jan Kiszka <[email protected]> a > écrit : > >> On 20.09.19 15:34, Pierre FICHEUX via Xenomai wrote: >> > Hi all, >> > >> > I've been using RTDM _rt / _nrt functions for a long time with Xenomai >> > 2.6.x but it seems not to work (the same way ?) with Xenomai 3 (tested >> with >> > several versions up to 3.0.8). Actually the _nrt driver function is >> never >> > called (_rt is always called...). I wrote a simple example for Xeno 2 >> and >> > Xeno 3 available here: >> > >> > https://github.com/pficheux/xenomai_examples.git >> > >> > Here is the test on Raspberry Pi 3 (Xeno 3). >> > >> > # insmod rtdm_test.ko >> > >> > # ./xenomai_test >> > >> > [ 47.661245] RTDM open:. >> > >> > [ 47.667473] ioctl: RT >> > >> > [ 47.672674] ioctl: RT >> > >> > [ 48.667479] ioctl: RT >> > >> > [ 48.678078] ioctl: RT >> > >> > [ 49.667463] ioctl: RT >> > >> > [ 49.683076] ioctl: RT >> > >> > [ 50.667463] ioctl: RT >> > >> > [ 50.687868] ioctl: RT >> > >> > >> > Of course it works fine with Xenomai 2 (on Pi B+) : >> > >> > # insmod rtdm_test.ko >> > >> > # ./xenomai_test >> > >> > [ 753.614275] RTDM open >> > >> > [ 753.632852] ioctl: RT >> > >> > [ 753.636779] ioctl: NRT >> > >> > [ 755.632839] ioctl: RT >> > >> > [ 755.640252] ioctl: NRT >> > >> > [ 756.632841] ioctl: RT >> > >> > [ 757.632838] ioctl: RT >> > >> > [ 757.643779] ioctl: NRT >> > >> > [ 758.632836] ioctl: RT >> > >> > Thx by advance for your help >> > >> >> Xenomai 3 prefers the RT patch of a RTDM callback over the NRT if the >> caller is >> a real-time task. Xenomai 2 had an adaptive behavior where the current >> state of >> the caller defined that. This is a problem I also ran into before and >> proposed >> to revert to the old behavior (in fact, we do that in one internal >> deployment). >> But there is also the point that preferring RT over NRT makes sense for >> many >> scenarios. >> >> Discussing this with Philippe back then on the list (I do not find the >> reference >> ATM), we came to the conclusion that the better answer is to allow the >> driver to >> declare which particular behavior a callback should have - in contrast to >> doing >> that in one way or the other at the top level, ie. on syscall entry of >> ioctl >> etc. But I do not have a design for that yet, and I didn't want to delay >> the 3.1 >> release further to finish that first. >> >> What we could consider for 3.1 is adding a compile-time configurable to >> re-enable the old behavior at syscall level when a user needs it. Then we >> could >> later on (3.2) push that properly to the driver level and remove the >> control again. >> >> Jan >> >> -- >> Siemens AG, Corporate Technology, CT RDA IOT SES-DE >> Corporate Competence Center Embedded Linux >> > > > -- > > Pierre FICHEUX -/- CTO Smile ECS, France -\- [email protected] > http://www.smile.fr > https://smile.eu/fr/offres/embarque-iot > I would love to change the world, but they won't give me the source code > > -- Pierre FICHEUX -/- CTO Smile ECS, France -\- [email protected] http://www.smile.fr https://smile.eu/fr/offres/embarque-iot I would love to change the world, but they won't give me the source code
