Xenomai inter-process communication mode

The xenomai communication mode is divided into the IPC in the xenomai domain and the IPC between the xenomai domain and the Linux domain,

Currently, rtipc (rtdm driver) is used to provide socket interfaces and real-time applications for user spaces.

By calling the corresponding interface, you can avoid switching to the Linux domain, resulting in lower real-time performance. Rtipc corresponds to three protocols:

Xddp (IPC between xenomai domain and Linux domain)

IDDP and bufp (IPC in the xenomai domain)

In addition, the original rt_pipe mechanism is still supported, but not from xenomai 3.

Http://www.xenomai.org/pipermail/xenomai/2009-September/017631.html

In the wake of a recent discussion about Xenomai 3, the requirement tofind a substitute for the native message pipes interface (i.e. RT_PIPE)was pointed out.The real-time side of this new interface would have to be available fromkernel space to RTDM drivers as well, so that people adopting a cleansplit model like RTDM-drivers <-> userland applications, would not beleft in the cold, with no replacement for the legacy RT_PIPE API inkernel space, which will be phased out in Xenomai 3.This question, and a few others, may have found an answer with therecent merging of the so-called RTIPC framework, for Xenomai 2.5.x.RTIPC is an RTDM-based "meta-driver", on top of which one may stackprotocol drivers, exporting a socket interface to the real-time users,running in primary mode within the Xenomai domain. The point of RTIPCbeing precisely that such users won‘t want to leave the real-time modefor sending/receiving data to/from other destinations/sources.So far, I have merged three protocols along with the RTIPC framework,namely XDDP, IDDP and BUFP.* XDDP stands for "cross-domain datagram protocol", i.e. to exchangedatagrams between the Xenomai (primary) real-time domain, and the Linuxrealm. This is what the message pipe fans may want to have a look at.Basically, it connects a real-time RTDM socket to one of the /dev/rtp*pseudo-devices. The network port used on the socket side matches theminor device number used on the non RT side. The added bonus of XDDP isthat people relying on the POSIX skin may now have access to the messagepipe feature, without dragging in bits of the native skin API for thatpurpose.* IDDP stands for "intra-domain datagram protocol", i.e. aXenomai-to-Xenomai real-time datagram channel. This protocol may not beas flexible as POSIX message queues (does not support message prioritybut does out-of-bound sending though), but exports a socket interface,which is surely better for your brain than mq_*() (ask Gilles). Thebasic idea behind it is that anything you could do based on AF_UNIXsockets in the Linux realm, should be (mostly) doable with AF_RTIPC+IDDPin the Xenomai domain. However, we use numeric port numbers or labelstrings, and not socket paths to bind sockets in the Xenomai namespace.* BUFP stands for "buffer protocol", probably the most naive of all, butlikely the best fit when you don‘t care for message boundaries, and justwant an efficient IPC to send a byte stream from a producer to aconsumer thread, without leaving the Xenomai domain. This protocol isthe exact equivalent of the RT_BUFFER API that came to light earlier inthe 2.5.x series, but again, exporting a socket interface to thereal-time application.The fact that all RTIPC protocols are RTDM-based, means that one canreach the socket API from kernel space as well, using the inter-driverRTDM interface, see:http://www.xenomai.org/documentation/xenomai-head/html/api/index.html

Example:

Http://www.rts.uni-hannover.de/xenomai/lxr/source/examples/rtdm/profiles/ipc/

* Real-Time xenomai threads and regular Linux threads may want
* Exchange data in a way that does not require the former to leave
* The Real-Time Domain (I. e. Secondary mode). Message pipes-
* Implemented by the rtdm-based xddp protocol-are provided for this
* Purpose.
*
* On the Linux domain side, pseudo-device files named/dev/RTP <minor>
* Give regular POSIX Threads Access to non real-time communication
* Endpoints, via the standard character-based I/O interface. On
* Xenomai domain side, sockets may be bound to xddp ports, which act
* As proxies to send and receive data to/from the associated
* Pseudo-device files. Ports and pseudo-device minor numbers are
* Too red, meaning that e.g. port 7 will proxy the traffic
*/Dev/rtp7. therefore, port numbers may range from 0
* Config_xeno_opt_pipe_nrdev-1.
*
* All data sent through a bound/connected xddp socket via sendto (2) or
* Write (2) will be passed to the peer endpoint in the Linux domain,
* And made available for reading via the standard read (2) System
* Call. Conversely, all data sent using write (2) Through the non
* Real-Time endpoint will be conveyed to the real-time socket
* Endpoint, and made available to the recvfrom (2) or read (2) System
* Cballs.

Other related descriptions:

Https://www.mail-archive.com/?email protected]/msg04535.html

Xddp is a wrapper over xenomai's message pipe support, offeringSocket-based interface to applications. Each xddp port is mapped toGiven/dev/RTP device minor, but the communication endpoints between RTAnd NRT are different internally.

[XDDP-port] <---> xnpipe #<port>                     ^                     |                     |  * input queue:  /dev/rtp -> xnpipe                     |  * output queue: xnpipe -> /dev/rtp                     |                     v               /dev/rtp<port>

So, when NRT reads from/dev/RTP <port>, it does not actually listen The same endpoint/queue than RT, because message pipes are Bi-directional. Likewise, NRT and RT never write to the same queue, Since the purpose of message pipes is to cross the RT/NRT domain boundary.