Hi Jan, Actually it was "clear" for me after reading some examples such as kernel/drivers/testing/rtdmtest.c.
Btw examples deal only with ioctl and I don't understand how it could work for read/write (any example around??). regards Le lun. 23 sept. 2019 à 15:10, Jan Kiszka <[email protected]> a écrit : > On 20.09.19 16:23, Pierre FICHEUX wrote: > > 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" ?? > > I actually have to correct myself: Since "cobalt/syscalls: allow for > handing > over mode selection to syscall handlers" (predates v3.0.3), RTDM entry > points > are supposed to have to original behavior again (call driver handler > corresponding to current caller mode first, then switch if handler returns > -ENOSYS). > > Maybe we need to look into your concrete case again if something else > changes > the migration pattern. > > Jan > > > > > Le ven. 20 sept. 2019 à 15:45, Jan Kiszka <[email protected] > > <mailto:[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] > <mailto:[email protected]> > > http://www.smile.fr <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 > > > > -- > 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
