Xenomai API  2.6.5
Message pipe services.
Collaboration diagram for Message pipe services.:

Files

file  pipe.c
 This file is part of the Xenomai project.
 

Functions

int rt_pipe_create (RT_PIPE *pipe, const char *name, int minor, size_t poolsize)
 Create a message pipe. More...
 
int rt_pipe_delete (RT_PIPE *pipe)
 Delete a message pipe. More...
 
ssize_t rt_pipe_receive (RT_PIPE *pipe, RT_PIPE_MSG **msgp, RTIME timeout)
 Receive a message from a pipe. More...
 
ssize_t rt_pipe_read (RT_PIPE *pipe, void *buf, size_t size, RTIME timeout)
 Read a message from a pipe. More...
 
ssize_t rt_pipe_send (RT_PIPE *pipe, RT_PIPE_MSG *msg, size_t size, int mode)
 Send a message through a pipe. More...
 
ssize_t rt_pipe_write (RT_PIPE *pipe, const void *buf, size_t size, int mode)
 Write a message to a pipe. More...
 
ssize_t rt_pipe_stream (RT_PIPE *pipe, const void *buf, size_t size)
 Stream bytes to a pipe. More...
 
RT_PIPE_MSG * rt_pipe_alloc (RT_PIPE *pipe, size_t size)
 Allocate a message pipe buffer. More...
 
int rt_pipe_free (RT_PIPE *pipe, RT_PIPE_MSG *msg)
 Free a message pipe buffer. More...
 
int rt_pipe_flush (RT_PIPE *pipe, int mode)
 Flush the i/o queues associated with the kernel endpoint of a message pipe. More...
 
int rt_pipe_monitor (RT_PIPE *pipe, int(*fn)(RT_PIPE *pipe, int event, long arg))
 Monitor a message pipe asynchronously. More...
 

Detailed Description

Message pipe services.

A message pipe is a two-way communication channel between Xenomai tasks and standard Linux processes using regular file I/O operations on a pseudo-device. Pipes can be operated in a message-oriented fashion so that message boundaries are preserved, and also in byte streaming mode from real-time to standard Linux processes for optimal throughput.

Xenomai tasks open their side of the pipe using the rt_pipe_create() service; standard Linux processes do the same by opening one of the /dev/rtpN special devices, where N is the minor number agreed upon between both ends of each pipe. Additionally, named pipes are available through the registry support, which automatically creates a symbolic link from entries under /proc/xenomai/registry/native/pipes/ to the corresponding special device file.

Function Documentation

RT_PIPE_MSG* rt_pipe_alloc ( RT_PIPE *  pipe,
size_t  size 
)

Allocate a message pipe buffer.

This service allocates a message buffer from the pipe's heap which can be subsequently filled by the caller then passed to rt_pipe_send() for sending. The beginning of the available data area of size contiguous bytes is accessible from P_MSGPTR(msg).

Parameters
pipeThe descriptor address of the affected pipe.
sizeThe requested size in bytes of the buffer. This value should represent the size of the payload data.
Returns
The address of the allocated message buffer upon success, or NULL if the allocation fails.

Environments:

This service can be called from:

  • Kernel module initialization/cleanup code
  • Interrupt service routine
  • Kernel-based task

Rescheduling: never.

Examples:
pipe.c.

References xnheap_alloc().

Referenced by rt_pipe_write().

int rt_pipe_create ( RT_PIPE *  pipe,
const char *  name,
int  minor,
size_t  poolsize 
)

Create a message pipe.

This service opens a bi-directional communication channel allowing data exchange between Xenomai tasks and standard Linux processes. Pipes natively preserve message boundaries, but can also be used in byte stream mode from Xenomai tasks to standard Linux processes.

rt_pipe_create() always returns immediately, even if no Linux process has opened the associated special device file yet. On the contrary, the non real-time side could block upon attempt to open the special device file until rt_pipe_create() is issued on the same pipe from a Xenomai task, unless O_NONBLOCK has been specified to the open(2) system call.

Parameters
pipeThe address of a pipe descriptor Xenomai will use to store the pipe-related data. This descriptor must always be valid while the pipe is active therefore it must be allocated in permanent memory.
nameAn ASCII string standing for the symbolic name of the message pipe. When non-NULL and non-empty, this string is copied to a safe place into the descriptor, and passed to the registry package if enabled for indexing the created pipe.

Named pipes are supported through the use of the registry. When the registry support is enabled, passing a valid name parameter when creating a message pipe subsequently allows standard Linux processes to follow a symbolic link from /proc/xenomai/registry/pipes/name in order to reach the associated special device (i.e. /dev/rtp*), so that the specific minor information does not need to be known from those processes for opening the proper device file. In such a case, both sides of the pipe only need to agree upon a symbolic name to refer to the same data path, which is especially useful whenever the minor number is picked up dynamically using an adaptive algorithm, such as passing P_MINOR_AUTO as minor value.

Parameters
minorThe minor number of the device associated with the pipe. Passing P_MINOR_AUTO causes the minor number to be auto-allocated. In such a case, the name parameter must be valid so that user-space processes may subsequently follow the symbolic link that will be automatically created from /proc/xenomai/registry/pipes/name to the allocated pipe device entry (i.e. /dev/rtp*).
poolsizeSpecifies the size of a dedicated buffer pool for the pipe. Passing 0 means that all message allocations for this pipe are performed on the system heap.
Returns
0 is returned upon success. Otherwise:
  • -ENOMEM is returned if the system fails to get enough dynamic memory from the global real-time heap in order to register the pipe, or if not enough memory could be obtained from the selected buffer pool for allocating the internal streaming buffer.
  • -EEXIST is returned if the name is already in use by some registered object.
  • -ENODEV is returned if minor is different from P_MINOR_AUTO and is not a valid minor number for the pipe special device either (i.e. /dev/rtp*).
  • -EBUSY is returned if minor is already open.
  • -EPERM is returned if this service was called from an asynchronous context.

Environments:

This service can be called from:

  • Kernel module initialization/cleanup code
  • Kernel-based task
  • User-space task

Rescheduling: possible.

Examples:
pipe.c.

References rt_pipe_delete(), xnheap_alloc(), xnheap_init(), xnheap_set_label(), and xnregistry_enter().

int rt_pipe_delete ( RT_PIPE *  pipe)

Delete a message pipe.

This service deletes a pipe previously created by rt_pipe_create(). Data pending for transmission to non real-time processes are lost.

Parameters
pipeThe descriptor address of the affected pipe.
Returns
0 is returned upon success. Otherwise:
  • -EINVAL is returned if pipe is not a pipe descriptor.
  • -EIDRM is returned if pipe is a closed pipe descriptor.
  • -ENODEV or -EBADF can be returned if pipe is scrambled.
  • -EPERM is returned if this service was called from an asynchronous context.

Environments:

This service can be called from:

  • Kernel module initialization/cleanup code
  • Kernel-based task
  • User-space task

Rescheduling: possible.

Examples:
pipe.c.

References xnregistry_remove().

Referenced by rt_pipe_create().

int rt_pipe_flush ( RT_PIPE *  pipe,
int  mode 
)

Flush the i/o queues associated with the kernel endpoint of a message pipe.

This service flushes all data pending for consumption by the remote side in user-space for the given message pipe. Upon success, no data remains to be read from the remote side of the connection.

Parameters
pipeThe descriptor address of the pipe to flush.
modeA mask indicating which queues need to be flushed; the following flags may be combined in a single flush request:
  • XNPIPE_OFLUSH causes the output queue to be flushed (i.e. unread data sent from the real-time endpoint in kernel-space to the non real-time endpoint in user-space will be discarded). This is equivalent to calling ioctl(pipefd, XNPIPEIOC_OFLUSH, 0) from user-space.
  • XNPIPE_IFLUSH causes the input queue to be flushed (i.e. unread data sent from the non real-time endpoint in user-space to the real-time endpoint in kernel-space will be discarded). This is equivalent to calling ioctl(pipefd, XNPIPEIOC_IFLUSH, 0) from user-space.
Returns
Zero is returned upon success. Otherwise:
  • -EINVAL is returned if pipe is not a pipe descriptor.
  • -EIDRM is returned if pipe is a closed pipe descriptor.
  • -ENODEV or -EBADF are returned if pipe is scrambled.

Environments:

This service can be called from:

  • Kernel module initialization/cleanup code
  • Interrupt service routine
  • Kernel-based task

Rescheduling: never.

int rt_pipe_free ( RT_PIPE *  pipe,
RT_PIPE_MSG *  msg 
)

Free a message pipe buffer.

This service releases a message buffer returned by rt_pipe_receive() to the pipe's heap.

Parameters
pipeThe descriptor address of the affected pipe.
msgThe address of the message buffer to free.
Returns
0 is returned upon success, or -EINVAL if msg is not a valid message buffer previously allocated by the rt_pipe_alloc() service.

Environments:

This service can be called from:

  • Kernel module initialization/cleanup code
  • Interrupt service routine
  • Kernel-based task

Rescheduling: never.

Examples:
pipe.c.

References xnheap_free().

Referenced by rt_pipe_read(), and rt_pipe_write().

int rt_pipe_monitor ( RT_PIPE *  pipe,
int(*)(RT_PIPE *pipe, int event, long arg)  fn 
)

Monitor a message pipe asynchronously.

This service registers a notifier callback that will be called upon specific events occurring on the channel. rt_pipe_monitor() is particularly useful to monitor a channel asynchronously while performing other tasks.

Parameters
pipeThe descriptor address of the pipe to monitor.
fnThe notification handler. This user-provided routine will be passed the address of the message pipe descriptor receiving the event, the event code, and an optional argument. Four events are currently defined:
  • P_EVENT_INPUT is sent when the user-space endpoint writes to the pipe, which means that some input is pending for the kernel-based endpoint. The argument is the size of the incoming message.
  • P_EVENT_OUTPUT is sent when the user-space endpoint successfully reads a complete buffer from the pipe. The argument is the size of the outgoing message.
  • P_EVENT_CLOSE is sent when the user-space endpoint is closed. The argument is always 0.
  • P_EVENT_NOBUF is sent when no memory is available from the kernel pool to hold the message currently sent from the user-space endpoint. The argument is the size of the failed allocation. Upon return from the handler, the caller will block and retry until enough space is available from the pool; during that process, the handler might be called multiple times, each time a new attempt to get the required memory fails.

The P_EVENT_INPUT and P_EVENT_OUTPUT events are fired on behalf of a fully atomic context; therefore, care must be taken to keep their overhead low. In those cases, the Xenomai services that may be called from the handler are restricted to the set allowed to a real-time interrupt handler.

Returns
Zero is returned upon success. Otherwise:
  • -EINVAL is returned if pipe is not a pipe descriptor.
  • -EIDRM is returned if pipe is a closed pipe descriptor.
  • -ENODEV or -EBADF are returned if pipe is scrambled.

Environments:

This service can be called from:

  • Kernel module initialization/cleanup code
  • Kernel-based task

Rescheduling: never.

ssize_t rt_pipe_read ( RT_PIPE *  pipe,
void *  buf,
size_t  size,
RTIME  timeout 
)

Read a message from a pipe.

This service retrieves the next message written to the associated special device in user-space. rt_pipe_read() always preserves message boundaries, which means that all data sent through the same write(2) operation to the special device will be gathered in a single message by this service. This services differs from rt_pipe_receive() in that it copies back the payload data to a user-defined memory area, instead of returning a pointer to the internal message buffer holding such data.

Unless otherwise specified, the caller is blocked for a given amount of time if no data is immediately available on entry.

Parameters
pipeThe descriptor address of the pipe to read from.
bufA pointer to a memory location which will be written upon success with the read message contents.
sizeThe count of bytes from the received message to read up into buf. If size is lower than the actual message size, -ENOBUFS is returned since the incompletely received message would be lost. If size is zero, this call returns immediately with no other action.
timeoutThe number of clock ticks to wait for some message to arrive (see note). Passing TM_INFINITE causes the caller to block indefinitely until some data is eventually available. Passing TM_NONBLOCK causes the service to return immediately without waiting if no data is available on entry.
Returns
The number of read bytes copied to the buf is returned upon success. Otherwise:
  • 0 is returned if the peer closed the channel while rt_pipe_read() was reading from it. There is no way to distinguish this situation from an empty message return using rt_pipe_read(). One should rather call rt_pipe_receive() whenever this information is required.
  • -EINVAL is returned if pipe is not a pipe descriptor.
  • -EIDRM is returned if pipe is a closed pipe descriptor.
  • -ENODEV or -EBADF are returned if pipe is scrambled.
  • -ETIMEDOUT is returned if timeout is different from TM_NONBLOCK and no data is available within the specified amount of time.
  • -EWOULDBLOCK is returned if timeout is equal to TM_NONBLOCK and no data is immediately available on entry.
  • -EINTR is returned if rt_task_unblock() has been called for the waiting task before any data was available.
  • -EPERM is returned if this service should block, but was called from a context which cannot sleep (e.g. interrupt, non-realtime context).
  • -ENOBUFS is returned if size is not large enough to collect the message data.

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)

Rescheduling: always unless the request is immediately satisfied or timeout specifies a non-blocking operation.

Note
The timeout value will be interpreted as jiffies if the native skin is bound to a periodic time base (see CONFIG_XENO_OPT_NATIVE_PERIOD), or nanoseconds otherwise.

References rt_pipe_free(), and rt_pipe_receive().

ssize_t rt_pipe_receive ( RT_PIPE *  pipe,
RT_PIPE_MSG **  msgp,
RTIME  timeout 
)

Receive a message from a pipe.

This service retrieves the next message written to the associated special device in user-space. rt_pipe_receive() always preserves message boundaries, which means that all data sent through the same write(2) operation to the special device will be gathered in a single message by this service. This service differs from rt_pipe_read() in that it returns a pointer to the internal buffer holding the message, which improves performances by saving a data copy to a user-provided buffer, especially when large messages are involved.

Unless otherwise specified, the caller is blocked for a given amount of time if no data is immediately available on entry.

Parameters
pipeThe descriptor address of the pipe to receive from.
msgpA pointer to a memory location which will be written upon success with the address of the received message. Once consumed, the message space should be freed using rt_pipe_free(). The application code can retrieve the actual data and size carried by the message by respectively using the P_MSGPTR() and P_MSGSIZE() macros. *msgp is set to NULL and zero is returned to the caller, in case the peer closed the channel while rt_pipe_receive() was reading from it.
timeoutThe number of clock ticks to wait for some message to arrive (see note). Passing TM_INFINITE causes the caller to block indefinitely until some data is eventually available. Passing TM_NONBLOCK causes the service to return immediately without waiting if no data is available on entry.
Returns
The number of read bytes available from the received message is returned upon success; this value will be equal to P_MSGSIZE(*msgp). Otherwise:
  • 0 is returned and *msgp is set to NULL if the peer closed the channel while rt_pipe_receive() was reading from it. This is to be distinguished from an empty message return, where *msgp points to a valid - albeit empty - message block (i.e. P_MSGSIZE(*msgp) == 0).
  • -EINVAL is returned if pipe is not a pipe descriptor.
  • -ENODEV or -EBADF are returned if pipe is scrambled.
  • -ETIMEDOUT is returned if timeout is different from TM_NONBLOCK and no data is available within the specified amount of time.
  • -EWOULDBLOCK is returned if timeout is equal to TM_NONBLOCK and no data is immediately available on entry.
  • -EINTR is returned if rt_task_unblock() has been called for the waiting task before any data was available.
  • -EPERM is returned if this service should block, but was called from a context which cannot sleep (e.g. interrupt, non-realtime context).

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

Rescheduling: always unless the request is immediately satisfied or timeout specifies a non-blocking operation.

Note
The timeout value will be interpreted as jiffies if the native skin is bound to a periodic time base (see CONFIG_XENO_OPT_NATIVE_PERIOD), or nanoseconds otherwise.
Examples:
pipe.c.

Referenced by rt_pipe_read().

ssize_t rt_pipe_send ( RT_PIPE *  pipe,
RT_PIPE_MSG *  msg,
size_t  size,
int  mode 
)

Send a message through a pipe.

This service writes a complete message to be received from the associated special device. rt_pipe_send() always preserves message boundaries, which means that all data sent through a single call of this service will be gathered in a single read(2) operation from the special device. This service differs from rt_pipe_write() in that it accepts a canned message buffer, instead of a pointer to the raw data to be sent. This call is useful whenever the caller wants to prepare the message contents separately from its sending, which does not require to have all the data to be sent available at once but allows for incremental updates of the message, and also saves a message copy, since rt_pipe_send() deals internally with message buffers.

Parameters
pipeThe descriptor address of the pipe to send to.
msgThe address of the message to be sent. The message space must have been allocated using the rt_pipe_alloc() service. Once passed to rt_pipe_send(), the memory pointed to by msg is no more under the control of the application code and thus should not be referenced by it anymore; deallocation of this memory will be automatically handled as needed. As a special exception, msg can be NULL and will not be dereferenced if size is zero.
sizeThe size in bytes of the message (payload data only). Zero is a valid value, in which case the service returns immediately without sending any message. This parameter allows you to actually send less data than you reserved using the rt_pipe_alloc() service, which may be the case if you did not know how much space you needed at the time of allocation. In all other cases it may be more convenient to just pass P_MSGSIZE(msg).
modeA set of flags affecting the operation:
  • P_URGENT causes the message to be prepended to the output queue, ensuring a LIFO ordering.
  • P_NORMAL causes the message to be appended to the output queue, ensuring a FIFO ordering.
Returns
Upon success, this service returns size. Upon error, one of the following error codes is returned:
  • -EINVAL is returned if pipe is not a pipe descriptor.
  • -EIDRM is returned if pipe is a closed pipe descriptor.
  • -ENODEV or -EBADF are returned if pipe is scrambled.

Environments:

This service can be called from:

  • Kernel module initialization/cleanup code
  • Interrupt service routine
  • Kernel-based task

Rescheduling: possible.

Note
Writing data to a pipe before any peer has opened the associated special device is allowed. The output will be buffered until then, only restricted by the available memory in the relevant buffer pool (see rt_pipe_create()).
Examples:
pipe.c.

Referenced by rt_pipe_write().

ssize_t rt_pipe_stream ( RT_PIPE *  pipe,
const void *  buf,
size_t  size 
)

Stream bytes to a pipe.

This service writes a sequence of bytes to be received from the associated special device. Unlike rt_pipe_send(), this service does not preserve message boundaries. Instead, an internal buffer is filled on the fly with the data, which will be consumed as soon as the receiver wakes up.

Data buffers sent by the rt_pipe_stream() service are always transmitted in FIFO order (i.e. P_NORMAL mode).

Parameters
pipeThe descriptor address of the pipe to write to.
bufThe address of the first data byte to send. The data will be copied to an internal buffer before transmission.
sizeThe size in bytes of the buffer. Zero is a valid value, in which case the service returns immediately without buffering any data.
Returns
The number of bytes sent upon success; this value may be lower than size, depending on the available space in the internal buffer. Otherwise:
  • -EINVAL is returned if pipe is not a pipe descriptor.
  • -EIDRM is returned if pipe is a closed pipe descriptor.
  • -ENODEV or -EBADF are returned if pipe is scrambled.
  • -ENOSYS is returned if the byte streaming mode has been disabled at configuration time by nullifying the size of the pipe buffer (see CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ).

Environments:

This service can be called from:

  • Kernel module initialization/cleanup code
  • Interrupt service routine
  • Kernel-based task
  • User-space task

Rescheduling: possible.

Note
Writing data to a pipe before any peer has opened the associated special device is allowed. The output will be buffered until then, only restricted by the available memory in the relevant buffer pool (see rt_pipe_create()).
ssize_t rt_pipe_write ( RT_PIPE *  pipe,
const void *  buf,
size_t  size,
int  mode 
)

Write a message to a pipe.

This service writes a complete message to be received from the associated special device. rt_pipe_write() always preserves message boundaries, which means that all data sent through a single call of this service will be gathered in a single read(2) operation from the special device. This service differs from rt_pipe_send() in that it accepts a pointer to the raw data to be sent, instead of a canned message buffer. This call is useful whenever the caller does not need to prepare the message contents separately from its sending.

Parameters
pipeThe descriptor address of the pipe to write to.
bufThe address of the first data byte to send. The data will be copied to an internal buffer before transmission.
sizeThe size in bytes of the message (payload data only). Zero is a valid value, in which case the service returns immediately without sending any message.
modeA set of flags affecting the operation:
  • P_URGENT causes the message to be prepended to the output queue, ensuring a LIFO ordering.
  • P_NORMAL causes the message to be appended to the output queue, ensuring a FIFO ordering.
Returns
Upon success, this service returns size. Upon error, one of the following error codes is returned:
  • -EINVAL is returned if pipe is not a pipe descriptor.
  • -ENOMEM is returned if not enough buffer space is available to complete the operation.
  • -EIDRM is returned if pipe is a closed pipe descriptor.
  • -ENODEV or -EBADF are returned if pipe is scrambled.

Environments:

This service can be called from:

  • Kernel module initialization/cleanup code
  • Interrupt service routine
  • Kernel-based task
  • User-space task

Rescheduling: possible.

Note
Writing data to a pipe before any peer has opened the associated special device is allowed. The output will be buffered until then, only restricted by the available memory in the relevant buffer pool (see rt_pipe_create()).

References rt_pipe_alloc(), rt_pipe_free(), and rt_pipe_send().