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
