[Xenomai] POSIX application running under xenomai -- what do wrapped functions do?

[Xenomai] POSIX application running under xenomai -- what do wrapped functions do?

[Steve M. Robbins]

Hi,

I've looked through the FAQ and read all the "Start Here" documentation on the 
wiki.  At the risk of sounding dense, I confess I am still a bit unsure what 
the wrapped POSIX functions are doing.  This is going to be a long-winded 
post, but here's the first questions:

Q1: Generically, what are the wrapped functions doing?  I did look at the code 
for wrapped select().  I can see it calls some xenomai function and falls back 
to the regular select(), but well, let's just say I'm no wiser...

Q2: The POSIX skin wraps I/O like read() and write().  Is it supported to mix
wrapped and unwrapped calls?  I have inherited a code base where some I/O with 
FIFOs and files uses wrapped calls but socket code uses unwrapped code.

Q3: The POSIX skin wraps select() but not pselect().  The two functions are 
basically identical in function if you don't use signal masking (as we don't). 
So we have different behaviour if I choose pselect() over select(). Since  
Xenomai needs to wrap one, is there a chance that using the unwrapped 
alternative may confuse Xenomai?  Our code uses pselect() today.



So I'm working on a motion control project using a Delta Tau system which 
consists of a PowerPC running Linux with Xenomai 2.5.6.  Delta Tau has 
arranged things so that you can just write servo loop code in their IDE and 
the build process takes care of the details.  They also provide a way to write 
a "background" linux program, which we use as a communications bridge to a 
second user interface system, sending commands and data over a socket.  The 
bridge program is mainly doing logging and socket I/O. We use some shared 
memory to send commands down to a real-time task (called RTI) and servo 
routine tasks (all written in C) and read back status. Additionally, we have a 
pair of FIFOs sending data streams from RTI to the bridge process. 

Until a few days ago, I considered the bridge program as a regular POSIX C 
program, but digging into the build system I discovered that it links with the 
xenomai posix skin libraries, with all the --wrap commands passed to the 
linker.  Furthermore the threads of this program appear in /proc/xenomai/sched 
(with PRI=1) and /proc/xenomai/stat shows that the threads are performing a 
huge number of mode switches.

Our bridge suffers from random lockups. During one lockup, with the help of 
/proc/PID/status and /proc/PID/wchan, I was able to determine that the process 
was stuck in the system call "xnshadow_harden".  It stayed "stuck" for 30+ 
hours until I rebooted the machine.  

If interested, I posted some more details here:
* http://forums.deltatau.com/showthread.php?tid=1654
* http://forums.deltatau.com/showthread.php?tid=743


Q4: Generically, what causes a process to get stuck in xnshadow_harden()?  How 
would I troubleshoot further?

Q5: We do not call pthread_setschedparam() to change the scheduler or priority 
of the bridge program's threads, yet they appear as PRI=1 in 
/proc/xenomai/sched ... any ideas?  (Note that we do invoke an initialization 
function provided by Delta Tau which may be doing something under the covers).  

Q6: I realize I haven't given terribly many details, but generically, what 
would cause a non-real time "background" process to switch to the primary 
domain, as ours seems to do?

Q7: In addition to the inconsistent wrapping in bridge, the real-time task RTI 
does not wrap any of its calls, e.g. we use write() on the FIFO.  Is this 
going to cause trouble?

Thanks for reading this far.  If you can provide clues for even one of my 
questions, I'd be very very grateful.

Thanks,
-Steve

Re: [Xenomai] POSIX application running under xenomai -- what do wrapped functions do?

[Philippe Gerum]

On 06/20/2014 05:48 PM, Steve M. Robbins wrote:
> Hi,
>
> I've looked through the FAQ and read all the "Start Here" documentation on the
> wiki.  At the risk of sounding dense, I confess I am still a bit unsure what
> the wrapped POSIX functions are doing.  This is going to be a long-winded
> post, but here's the first questions:
>
> Q1: Generically, what are the wrapped functions doing?  I did look at the code
> for wrapped select().  I can see it calls some xenomai function and falls back
> to the regular select(), but well, let's just say I'm no wiser...

Wrapping is only aimed at keeping the regular POSIX names for calling 
POSIX-compliant Xenomai services, without resorting to a parallel naming 
scheme for an API which is deemed portable and standardized (e.g. 
pthread_create_whatever_nonsense() instead of pthread_create()).

When a wrapper ends up calling the regular glibc service, this means 
that Xenomai won't process the call, so it simply hands it over to the 
regular kernel via the glibc, hoping for the best. In the select() case, 
this typically happens when Xenomai discovers that one or more file 
descriptors found in the sets are not RTDM ones (ie. not belonging to 
the Xenomai realm).

The key issue is that in such system with two kernels running 
side-by-side, there must be two service call stacks. One stack ends up 
calling into the real-time extension, the other into the host/Linux 
non-rt kernel. Sometimes the Xenomai wrappers do some bridging between 
them to make things more transparent to the user (well, that was the 
plan), like what happens with the select() call.

>
> Q2: The POSIX skin wraps I/O like read() and write().  Is it supported to mix
> wrapped and unwrapped calls?  I have inherited a code base where some I/O with
> FIFOs and files uses wrapped calls but socket code uses unwrapped code.

It is supported, but this also means that your code may switch back and 
forth between real-time and non real-time modes, we call these "primary" 
and "secondary" modes. Passing a RTDM fd to some unwrapped call will 
never work though, and should beget EBADF.

A thread in primary mode will be switched to secondary mode whenever it 
issues a Linux system call. Conversely, a (Xenomai) thread in secondary 
mode will switch back to primary mode when it calls a Xenomai service 
which requires it. Switching mode is:

1) time consuming and causes overhead when done very frequently (e.g. 
within some tight processing loop),

2) defeats the purpose of using a real-time extension as soon as the 
code moves to secondary mode.

This said, invoking regular kernel services from real-time threads in 
well-defined and delimited sections may be perfectly fine. We definitely 
need this for carrying out initialization/cleanup chores and such.

>
> Q3: The POSIX skin wraps select() but not pselect().  The two functions are
> basically identical in function if you don't use signal masking (as we don't).
> So we have different behaviour if I choose pselect() over select(). Since
> Xenomai needs to wrap one, is there a chance that using the unwrapped
> alternative may confuse Xenomai?  Our code uses pselect() today.
>
>

Then your code invokes the regular pselect() service from the regular 
kernel, since Xenomai does not wrap it. Xenomai won't be confused, the 
operation fully happens within the "other" kernel. This also means that 
the file descriptors must be regular ones, not obtained from the wrapped 
(i.e. RTDM-provided) open() call though.

>
> So I'm working on a motion control project using a Delta Tau system which
> consists of a PowerPC running Linux with Xenomai 2.5.6.  Delta Tau has
> arranged things so that you can just write servo loop code in their IDE and
> the build process takes care of the details.  They also provide a way to write
> a "background" linux program, which we use as a communications bridge to a
> second user interface system, sending commands and data over a socket.  The
> bridge program is mainly doing logging and socket I/O. We use some shared
> memory to send commands down to a real-time task (called RTI) and servo
> routine tasks (all written in C) and read back status. Additionally, we have a
> pair of FIFOs sending data streams from RTI to the bridge process.
>
> Until a few days ago, I considered the bridge program as a regular POSIX C
> program, but digging into the build system I discovered that it links with the
> xenomai posix skin libraries, with all the --wrap commands passed to the
> linker.  Furthermore the threads of this program appear in /proc/xenomai/sched
> (with PRI=1) and /proc/xenomai/stat shows that the threads are performing a
> huge number of mode switches.
>

Yuck. Then the issue about frenetic mode switching I described earlier 
might apply. This code may have a basic issue with properly splitting 
the real-time and non real-time activities.

> Our bridge suffers from random lockups. During one lockup, with the help of
> /proc/PID/status and /proc/PID/wchan, I was able to determine that the process
> was stuck in the system call "xnshadow_harden".  It stayed "stuck" for 30+
> hours until I rebooted the machine.

We fixed quite a few bugs (read: a truckload) since 2.5.6, including a 
few in the mode transition paths and elsewhere. So I would not be 
surprised that some of them still bite here. Any chance you could 
upgrade your board to 2.6.3? API-wise, I'm confident you would have no 
significant issue, if any at all. Besides, you would not have to change 
your kernel release - although it's likely quite old as well I guess.

>
> If interested, I posted some more details here:
> * http://forums.deltatau.com/showthread.php?tid=1654
> * http://forums.deltatau.com/showthread.php?tid=743
>
>
> Q4: Generically, what causes a process to get stuck in xnshadow_harden()?  How
> would I troubleshoot further?
>

As mentioned earlier, a Xenomai bug, and these ones have been nasty to 
chase down. xnshadow_harden() is part of the mode switch machinery.

> Q5: We do not call pthread_setschedparam() to change the scheduler or priority
> of the bridge program's threads, yet they appear as PRI=1 in
> /proc/xenomai/sched ... any ideas?  (Note that we do invoke an initialization
> function provided by Delta Tau which may be doing something under the covers).
>

If by threads you mean the main() threads, then there is the possibility 
that the library constructor of libpthread_rt switches the originally 
SCHED_FIFO,1 thread to its Xenomai equivalent, thus visible under 
/proc/xenomai/sched. But that would mean that your program inherits 
SCHED_FIFO,1 from its parent, not SCHED_OTHER.

> Q6: I realize I haven't given terribly many details, but generically, what
> would cause a non-real time "background" process to switch to the primary
> domain, as ours seems to do?

Calling into any Xenomai service which requires it. There are two 
classes of services that do:

- those which might block/suspend the caller (e.g. waiting on a sema4, 
reading/selecting RTDM-originated fildes, etc)

- those which do some kind of introspection of the calling context, or 
would affect some properties of the current thread.

However, a thread may only switch to primary mode if it's a Xenomai 
thread in the first place. A Xenomai thread in user-space is a regular 
POSIX thread on steroïds, which received Xenomai capabilities because 
either of these events happened:

- it was started by the wrapped pthread_create() call
- the wrapped pthread_setschedparam() call was invoked for it.

There is a subtlety to keep in mind at this point: a Xenomai thread is 
not necessarily real-time capable. Xenomai threads created in or moved 
to the SCHED_OTHER class are able to call Xenomai services (e.g. wait 
for, use or signal Xenomai resources), but won't compete for the CPU 
with Xenomai threads which belong to SCHED_FIFO/RR.

This is aimed at allowing non rt threads to synchronize with rt threads 
using common IPCs (sema4, mutexes etc), without having to resort to 
exchanging messages, provided both are Xenomai threads.

So, to sum up, the fact that a thread is able to call Xenomai(-only) 
services means that it must have been given at least Xenomai 
capabilities as mentioned (otherwise it would receive EPERM).

Unlike SCHED_FIFO/RR Xenomai threads, those special SCHED_OTHER Xenomai 
threads will switch back to secondary mode automatically when leaving a 
Xenomai system call if they happened to switch to primary mode for that 
purpose (unless they hold a real-time mutex though).

>
> Q7: In addition to the inconsistent wrapping in bridge, the real-time task RTI
> does not wrap any of its calls, e.g. we use write() on the FIFO.  Is this
> going to cause trouble?
>

This is going to switch any real-time Xenomai caller to secondary/non rt 
mode for sure.

In case this applies, if you want to exchange a stream of data between 
the rt and non-rt world, then you may want to have a look at the 
RTDM-based XDDP IPC, 
http://www.xenomai.org/documentation/xenomai-2.6/html/api/group__rtipc.html, 
with sample code in examples/rtdm/profiles/ipc.
This feature allows a non-rt thread reading/writing to a pseudo-device 
from /dev/rtp* to exchange messages with a rt thread reading/writing to 
a RTDM socket. The rt side never leaves primary mode when doing so, and 
the non rt program does not even have to link against Xenomai libraries.

> Thanks for reading this far.  If you can provide clues for even one of my
> questions, I'd be very very grateful.
>

Hopefully I won't have increased the headache.

HTH,

-- 
Philippe.

Re: [Xenomai] POSIX application running under xenomai -- what do wrapped functions do?

[Steve M. Robbins]

Hello Philippe,

Thank you so SO much for the detailed response to my vague questions.  There 
is a lot of helpful information for me to digest.


On June 20, 2014 07:38:51 PM Philippe Gerum wrote:

> > Thanks for reading this far.  If you can provide clues for even one of my
> > questions, I'd be very very grateful.
> 
> Hopefully I won't have increased the headache.

Ha!  We'll see ...

-Steve

Re: [Xenomai] POSIX application running under xenomai -- what do wrapped functions do?

[Steve M. Robbins]

On June 20, 2014 07:38:51 PM Philippe Gerum wrote:
> On 06/20/2014 05:48 PM, Steve M. Robbins wrote:

> > So I'm working on a motion control project using a Delta Tau system which
> > consists of a PowerPC running Linux with Xenomai 2.5.6.  Delta Tau has
> > arranged things so that you can just write servo loop code in their IDE
> > and
> > the build process takes care of the details.  They also provide a way to
> > write a "background" linux program, which we use as a communications
> > bridge to a second user interface system, sending commands and data over
> > a socket.  The bridge program is mainly doing logging and socket I/O. We
> > use some shared memory to send commands down to a real-time task (called
> > RTI) and servo routine tasks (all written in C) and read back status.
> > Additionally, we have a pair of FIFOs sending data streams from RTI to
> > the bridge process.
> > 
> > Until a few days ago, I considered the bridge program as a regular POSIX C
> > program, but digging into the build system I discovered that it links with
> > the xenomai posix skin libraries, with all the --wrap commands passed to
> > the linker.  Furthermore the threads of this program appear in
> > /proc/xenomai/sched (with PRI=1) and /proc/xenomai/stat shows that the
> > threads are performing a huge number of mode switches.

By removing the --wrap arguments on the link step, we removed the mode
switching of the bridge process.  This appears to have cured our hardware
watchdog problem.


> > Q7: In addition to the inconsistent wrapping in bridge, the real-time task
> > RTI does not wrap any of its calls, e.g. we use write() on the FIFO.  Is
> > this going to cause trouble?
> 
> This is going to switch any real-time Xenomai caller to secondary/non rt
> mode for sure.

Yep, the RTI does a ton of mode switching.  It's due entirely to the write() 
calls: as an experiment, I commented out the write()s and the mode switches 
went away.

 
> In case this applies, if you want to exchange a stream of data between
> the rt and non-rt world, then you may want to have a look at the
> RTDM-based XDDP IPC,
> http://www.xenomai.org/documentation/xenomai-2.6/html/api/group__rtipc.html,
> with sample code in examples/rtdm/profiles/ipc.
> This feature allows a non-rt thread reading/writing to a pseudo-device
> from /dev/rtp* to exchange messages with a rt thread reading/writing to
> a RTDM socket. The rt side never leaves primary mode when doing so, and
> the non rt program does not even have to link against Xenomai libraries.


Yeah, that sounds like what I want.  We are stuck with Xenomai 2.5.6 for now, 
so I went and looked in the docs for that version.  It looks like the Message 
Pipe services [1] would be a fairly direct replacement for our existing FIFO 
code.  How does the Message Pipe compare to your suggestion of Real Time IPC?  
I do see an entry for the Real Time IPC devices in the 2.5 docs [2], albeit a 
bit sparse on details.  Can I simply use the 2.6 docs as a reference?


[1] http://www.xenomai.org/documentation/xenomai-2.5/html/api/group__pipe.html
[2] 
http://www.xenomai.org/documentation/xenomai-2.5/html/api/group__rtipc.html

Thanks,
-Steve

Re: [Xenomai] POSIX application running under xenomai -- what do wrapped functions do?

[Philippe Gerum]

On 07/22/2014 09:17 AM, Steve M. Robbins wrote:
> On June 20, 2014 07:38:51 PM Philippe Gerum wrote:
>> On 06/20/2014 05:48 PM, Steve M. Robbins wrote:
> 
>>> So I'm working on a motion control project using a Delta Tau system which
>>> consists of a PowerPC running Linux with Xenomai 2.5.6.  Delta Tau has
>>> arranged things so that you can just write servo loop code in their IDE
>>> and
>>> the build process takes care of the details.  They also provide a way to
>>> write a "background" linux program, which we use as a communications
>>> bridge to a second user interface system, sending commands and data over
>>> a socket.  The bridge program is mainly doing logging and socket I/O. We
>>> use some shared memory to send commands down to a real-time task (called
>>> RTI) and servo routine tasks (all written in C) and read back status.
>>> Additionally, we have a pair of FIFOs sending data streams from RTI to
>>> the bridge process.
>>>
>>> Until a few days ago, I considered the bridge program as a regular POSIX C
>>> program, but digging into the build system I discovered that it links with
>>> the xenomai posix skin libraries, with all the --wrap commands passed to
>>> the linker.  Furthermore the threads of this program appear in
>>> /proc/xenomai/sched (with PRI=1) and /proc/xenomai/stat shows that the
>>> threads are performing a huge number of mode switches.
> 
> By removing the --wrap arguments on the link step, we removed the mode
> switching of the bridge process.  This appears to have cured our hardware
> watchdog problem.
> 

Ok.

> 
>>> Q7: In addition to the inconsistent wrapping in bridge, the real-time task
>>> RTI does not wrap any of its calls, e.g. we use write() on the FIFO.  Is
>>> this going to cause trouble?
>>
>> This is going to switch any real-time Xenomai caller to secondary/non rt
>> mode for sure.
> 
> Yep, the RTI does a ton of mode switching.  It's due entirely to the write() 
> calls: as an experiment, I commented out the write()s and the mode switches 
> went away.
> 

Makes sense. write() causes a regular linux syscall, which always
entails a mode switch when issued from primary mode, to make sure the
kernel is re-entered from a safe location (as the real-time code might
have preempted the regular kernel anywhere at the last activation).

>  
>> In case this applies, if you want to exchange a stream of data between
>> the rt and non-rt world, then you may want to have a look at the
>> RTDM-based XDDP IPC,
>> http://www.xenomai.org/documentation/xenomai-2.6/html/api/group__rtipc.html,
>> with sample code in examples/rtdm/profiles/ipc.
>> This feature allows a non-rt thread reading/writing to a pseudo-device
>> from /dev/rtp* to exchange messages with a rt thread reading/writing to
>> a RTDM socket. The rt side never leaves primary mode when doing so, and
>> the non rt program does not even have to link against Xenomai libraries.
> 
> 
> Yeah, that sounds like what I want.  We are stuck with Xenomai 2.5.6 for now, 
> so I went and looked in the docs for that version.  It looks like the Message 
> Pipe services [1] would be a fairly direct replacement for our existing FIFO 
> code.  How does the Message Pipe compare to your suggestion of Real Time IPC?  
> I do see an entry for the Real Time IPC devices in the 2.5 docs [2], albeit a 
> bit sparse on details.  Can I simply use the 2.6 docs as a reference?
> 

Almost, yes, with a few differences regarding some of the sockopt
request names though (XDDP_LABEL->XDDP_SETLABEL,
XDDP_SETSTREAMBUF->XDDP_BUFZ etc).

> 
> [1] http://www.xenomai.org/documentation/xenomai-2.5/html/api/group__pipe.html
> [2] 
> http://www.xenomai.org/documentation/xenomai-2.5/html/api/group__rtipc.html
> 

RTIPC/xddp and the Message pipe services are based on the very same code
in the Xenomai core, it's only a matter of differing interfaces. Over
2.5.6, I would go for the pipes, since the xddp driver in that release
might lack a couple of fixes which were merged into 2.6.

-- 
Philippe.

Re: [Xenomai] POSIX application running under xenomai -- what do wrapped functions do?

[Leopold Palomo-Avellaneda]

Hi Steve,

El Dimarts, 22 de juliol de 2014, a les 02:17:19, Steve M. Robbins va 
escriure:

[...]
> 
> > In case this applies, if you want to exchange a stream of data between
> > the rt and non-rt world, then you may want to have a look at the
> > RTDM-based XDDP IPC,
> > http://www.xenomai.org/documentation/xenomai-2.6/html/api/group__rtipc.htm
> > l, with sample code in examples/rtdm/profiles/ipc.
> > This feature allows a non-rt thread reading/writing to a pseudo-device
> > from /dev/rtp* to exchange messages with a rt thread reading/writing to
> > a RTDM socket. The rt side never leaves primary mode when doing so, and
> > the non rt program does not even have to link against Xenomai libraries.
> 
> Yeah, that sounds like what I want.  We are stuck with Xenomai 2.5.6 for
> now, so I went and looked in the docs for that version.  It looks like the
> Message Pipe services [1] would be a fairly direct replacement for our
> existing FIFO code.  How does the Message Pipe compare to your suggestion
> of Real Time IPC? I do see an entry for the Real Time IPC devices in the
> 2.5 docs [2], albeit a bit sparse on details.  Can I simply use the 2.6
> docs as a reference?
> 

if you want, look this:

https://github.com/iocroblab/cpp4ec

it's our project that has a rt-thread that interchange information with a non-
rt part with xddp.

Leo


-- 
--
Linux User 152692     PGP: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140724/bf1db8ab/attachment.sig>

Re: [Xenomai] POSIX application running under xenomai -- what do wrapped functions do?

[Steve M. Robbins]

On July 23, 2014 10:37:35 PM Philippe Gerum wrote:

> RTIPC/xddp and the Message pipe services are based on the very same code
> in the Xenomai core, it's only a matter of differing interfaces. Over
> 2.5.6, I would go for the pipes, since the xddp driver in that release
> might lack a couple of fixes which were merged into 2.6.

OK, we are now looking a bit more closely at the 2.5 Message Pipe docs and my colleague noticed a small quirk.  

For rt_pipe_read(), the doc [1] says:

		Environments:

		This service can be called from:

		 *    Kernel module initialization/cleanup code
		 *    Interrupt service routine only if timeout is equal to TM_NONBLOCK.

		 *    Kernel-based task
		 *    User-space task (switches to primary mode)

So a literal reading of the last two bullet points suggest that a call from kernel-based task never switches to primary mode while a call from the user-space task always does.  Naively that seems surprising.  Is it accurate?  

Secondly, for a user-space task: will it mode switch if there is data available?  If we use TM_NONBLOCK in a user space task, can we avoid the mode switch?

Finally, the function rt_pipe_receive() is pretty similar to rt_pipe_read() so much so that I would guess one is implemented using the other.  Thus I'm a bit surprised that its "Environments" documentation [2] differs from the previous in that it doesn't list "User-space task".  Is that accurate?


[1] http://www.xenomai.org/documentation/xenomai-2.5/html/api/group__pipe.html#g62cb64807c2c843f8e8eebb2dc3a7d4e
[2] http://www.xenomai.org/documentation/xenomai-2.5/html/api/group__pipe.html#g731e5ef18007dcd58a9346bea66abbc6

Thanks,
-Steve

Re: [Xenomai] POSIX application running under xenomai -- what do wrapped functions do?

[Stefan Smarzly]

Am 25.07.2014 16:54, schrieb Steve M. Robbins:
> On July 23, 2014 10:37:35 PM Philippe Gerum wrote:
>
>> RTIPC/xddp and the Message pipe services are based on the very same code
>> in the Xenomai core, it's only a matter of differing interfaces. Over
>> 2.5.6, I would go for the pipes, since the xddp driver in that release
>> might lack a couple of fixes which were merged into 2.6.
> OK, we are now looking a bit more closely at the 2.5 Message Pipe docs and my colleague noticed a small quirk.
>
> For rt_pipe_read(), the doc [1] says:
>
> 		Environments:
>
> 		This service can be called from:
>
> 		 *    Kernel module initialization/cleanup code
> 		 *    Interrupt service routine only if timeout is equal to TM_NONBLOCK.
>
> 		 *    Kernel-based task
> 		 *    User-space task (switches to primary mode)
>
> So a literal reading of the last two bullet points suggest that a call from kernel-based task never switches to primary mode while a call from the user-space task always does.  Naively that seems surprising.  Is it accurate?

As far as I know there is not a mode switch for RT kernel code at all. 
When running a kernel module, you do not have to invoke any syscalls as 
the user space occasionally has to do. You are already in kernel space. 
Thus, it should be primary mode by default.
This is what I am thinking. Maybe one of the officials can correct this 
information.

> Secondly, for a user-space task: will it mode switch if there is data available?  If we use TM_NONBLOCK in a user space task, can we avoid the mode switch?

The task will enter primary mode as soon as you are calling this 
function independent of the flag set to TM_NONBLOCK or not. Otherwise it 
could not test whether data is available at all. And by the way: You 
want to have a task to stay in primary mode as best as you can. 
Otherwise, you do not have any real-time guarantee anymore. So, if the 
task is already in primary mode, there won't be any mode switch.

> Finally, the function rt_pipe_receive() is pretty similar to rt_pipe_read() so much so that I would guess one is implemented using the other.  Thus I'm a bit surprised that its "Environments" documentation [2] differs from the previous in that it doesn't list "User-space task".  Is that accurate?

I do not know, but I think, it should work for both. At least it does 
for RT queues.

>
> [1] http://www.xenomai.org/documentation/xenomai-2.5/html/api/group__pipe.html#g62cb64807c2c843f8e8eebb2dc3a7d4e
> [2] http://www.xenomai.org/documentation/xenomai-2.5/html/api/group__pipe.html#g731e5ef18007dcd58a9346bea66abbc6
>
> Thanks,
> -Steve
>
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai

I hope I could help.
Stefan.

Re: [Xenomai] POSIX application running under xenomai -- what do wrapped functions do?

[Philippe Gerum]

On 07/25/2014 04:54 PM, Steve M. Robbins wrote:
> On July 23, 2014 10:37:35 PM Philippe Gerum wrote:
> 
>> RTIPC/xddp and the Message pipe services are based on the very same code
>> in the Xenomai core, it's only a matter of differing interfaces. Over
>> 2.5.6, I would go for the pipes, since the xddp driver in that release
>> might lack a couple of fixes which were merged into 2.6.
> 
> OK, we are now looking a bit more closely at the 2.5 Message Pipe docs and my colleague noticed a small quirk.  
> 
> For rt_pipe_read(), the doc [1] says:
> 
> 		Environments:
> 
> 		This service can be called from:
> 
> 		 *    Kernel module initialization/cleanup code

not related, but the TM_NONBLOCK clause applies above as well.

> 		 *    Interrupt service routine only if timeout is equal to TM_NONBLOCK.
> 
> 		 *    Kernel-based task
> 		 *    User-space task (switches to primary mode)
> 
> So a literal reading of the last two bullet points suggest that a call from kernel-based task never switches to primary mode while a call from the user-space task always does.  Naively that seems surprising.  Is it accurate?  
> 

Because a kernel-based Xenomai thread can only run in primary mode over
the Xenomai 2.x architecture, so the mode switch does not apply in essence.

> Secondly, for a user-space task: will it mode switch if there is data available?  If we use TM_NONBLOCK in a user space task, can we avoid the mode switch?
> 

It will mode switch regardless of whether data is available, the
transition happens in the early syscall path before we know about the
pipe status. TM_NONBLOCK won't help here.

> Finally, the function rt_pipe_receive() is pretty similar to rt_pipe_read() so much so that I would guess one is implemented using the other.  Thus I'm a bit surprised that its "Environments" documentation [2] differs from the previous in that it doesn't list "User-space task".  Is that accurate?
> 

Documentation issue, the clause applies to both calls indeed.

> 
> [1] http://www.xenomai.org/documentation/xenomai-2.5/html/api/group__pipe.html#g62cb64807c2c843f8e8eebb2dc3a7d4e
> [2] http://www.xenomai.org/documentation/xenomai-2.5/html/api/group__pipe.html#g731e5ef18007dcd58a9346bea66abbc6
> 
> Thanks,
> -Steve
> 
> 


-- 
Philippe.

Re: [Xenomai] POSIX application running under xenomai -- what do wrapped functions do?

[Steve M. Robbins]

On July 25, 2014 05:17:10 PM Stefan Smarzly wrote:
> Am 25.07.2014 16:54, schrieb Steve M. Robbins:



> > Secondly, for a user-space task: will it mode switch if there is data
> > available?  If we use TM_NONBLOCK in a user space task, can we avoid the
> > mode switch?
> The task will enter primary mode as soon as you are calling this
> function independent of the flag set to TM_NONBLOCK or not. Otherwise it
> could not test whether data is available at all. And by the way: You
> want to have a task to stay in primary mode as best as you can.
> Otherwise, you do not have any real-time guarantee anymore. So, if the
> task is already in primary mode, there won't be any mode switch.

Of course you are correct; and staying in primary mode is what we desire.  I 
had the modes backwards in my head.  Clearly I needed more caffeine before 
posting :-)

Thanks, Stefan and Philippe for the clarifications!

Best regards,
-Steve