REAL-TIME OPERATING SYSTEMS AND STANDARDS - Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications - page 434

RTAI offers the same services of the Linux kernel core, adding the features of an
industrial real-time operating system. It basically consists of an interrupt dispatcher
that traps the peripherals interrupts and, if necessary, reroutes them to Linux. It is not
an intrusive modification of the kernel: it uses the concept of hardware abstraction
layer (HAL) to get information from Linux and trap some fundamental functions.

RTAI uniformly mixes hard and soft real-time activities by symmetrically integrating
the scheduling of RTAI tasks, Linux kernel threads and user-space tasks. By using
Linux schedulable objects, RTAI benefits from threads protection at the price of a
slight increase in latencies. RTAI offers also a native, dynamically extensible, light
middleware layer based on the remote procedure call concept, which uses the whole
API in a distributed way.

One of the major limits of RTAI is that the project mainly focuses on x86 architec-
tures, thus there is a very limited support for embedded platforms. For this reason,
developers working in the embedded area often prefer using Xenomai.

12.3.3 XENOMAI

Started as a branch of the RTAI project, Xenomai 6 is the evolution of the Fusion
project, an effort to execute real-time RTAI tasks in user space. Xenomai brings the
concept of virtualization one step further: like RTAI, it uses the Adeos nano-kernel to
provide the interrupt virtualization, but it also allows a real-time task to execute in user
space. This is done by introducing the concept of domains : in the primary domain ,
the task is controlled by the RTOS, while in the secondary domain it is controlled by
the Linux scheduler. Normally, a real-time task starts in the primary domain, where
it remains as long as it invokes only the RTOS API. It is automatically migrated to
the secondary domain as soon as it invokes a standard Linux system call or it needs
to handle events such as exceptions or Linux signals. However, the task keeps its
real-time priority, being scheduled with the SCHED FIFO or SCHED RR Linux
policies.

While running in the secondary mode, the task can experience some delay and latency,
due to the fact that it is scheduled by Linux. However, at any time after the function
call has been completed, it can go back to the primary mode by explicitly calling a
function. In this way, real-time applications can use the full power of Linux at the cost
of some limited unpredictability.

6 Xenomai: http://www.xenomai.org