The state of RTAI [LWN.net]

November 10, 2004

This article was contributed by Joe 'Zonker' Brockmeier.

After the Approaches to realtime Linux article drew a great deal of interest, we decided to drill down and offer a closer look at one of the projects mentioned therein: The Real Time Application Interface (RTAI) project, whose developers felt that our portrayal of the project was not entirely accurate. To set things straight, we touched base with RTAI hackers Philippe Gerum and Paolo Mantegazza.

First, we learned that there are actually two ongoing projects, the first is the original RTAI project, funded by the Dipartimento di Ingegneria Aerospaziale, Politecnico di Milano (DIAPM). The other project is RTAI/Fusion, which is a different approach that merges the RTAI interfaces with the Xenomai development framework.

The RTAI project with Linux RealTime (LXRT) uses several kernel modules to gain the realtime functionality that one may need. RTAI makes changes in the Linux interrupt and scheduling policies to provide real time capabilities within the non-real time Linux environment. According to the RTAI website:

RTAI offers the same services of the Linux kernel core, adding the features of an industrial real time operating system. It consists basically of an interrupt dispatcher: RTAI mainly traps the peripherals interrupts and if necessary re-routes them to Linux. It is not an intrusive modification of the kernel; it uses the concept of HAL (hardware abstraction layer) to get information from Linux and to trap some fundamental functions. This HAL provides few dependencies to Linux Kernel. This leads to a simple adaptation in the Linux kernel, an easy RTAI port from version to version of Linux and an easier use of other operating systems instead of RTAI. RTAI considers Linux as a background task running when no real time activity occurs.

The original RTAI project was designed specifically for DIAPM projects, says Mantegazza:

The whole of RTAI, so LXRT also, was born to satisfy DIAPM needs first, it was made available much as it is in the form 'if you like it use it.' Bugs fixing apart, there is very little of RTAI that has been done to show up or to solve non DIAPM problems. However our applications are not trivial, you can bet we have_pushed/are_pushing LXRT to the extremes.

On the other hand, Xenomai was designed to allow developers to port applications from other realtime systems, and therefore it takes a different approach. Gerum describes Xenomai as a "kind of generic RTOS (Real Time Operating System) core" that enable a developer to plug in their own real-time APIs. Gerum says the idea was that most RTOS vendors offer the same functionality, but with "different API window dressings." Xenomai was designed to "provide one generic core running side-by-side with the Linux kernel" that would allow for different APIs.

The RTAI/Fusion project that is now under development works with a "vanilla" Linux kernel running on top of the Adeos (Adaptive Domain Environment for Operating Systems) nanokernel. By running the Linux kernel and Fusion under the Adeos nanokernel, Fusion cooperates with Linux and allows developers to use "any number of real-time APIs at the same time."

Given that there are a number of real time projects for Linux, not to mention the other various RTOSes, we asked whether it would be possible to come up with a "one size fits all" solution for real time operating systems. Mantegazza says yes, but Gerum is not so sure:

Since the traditional RTOS vendors did not succeed in capturing more than a half of the real-time market during the last 20 years, the rest consisting of home-grown solutions, I guess that the answer is no. This said, it should be possible to have a real-time framework which is extensible enough to allow people to build their real-time solution of choice over it. The system would simply provide a few canned interfaces in order to be usable out of the box, by people with common needs.

Simple design and straightforward code layers make the above possible. For instance, DSP-like applications do not necessarily need a full-fledged multi-tasking infrastructure; basic interrupt handlers with predictable preemption time are often enough here. On the other hand, you are not going to run a complete telecom software stack over interrupt service routines, so you need a complete RTOS core and rich utility libraries.

It's important to note that RTAI/Fusion would not replace RTAI/LXRT so much as envelope it, if successful. According to Gerum, the plan is to "refactor the original RTAI 3.x interfaces over Fusion, if this technology is successful."

What's left to implement in Fusion? Gerum says there are several things left to be done:

What remains is about porting to other CPU architectures, extending the toolset and the available canned real-time interfaces including new traditional RTOS emulations.

Fusion already provides a full-fledged event-driven simulator with a nifty GUI for debugging applications on the host system; GDB can also be used to debug the real-time threads in user-space on the target. However, LTT (Linux Trace Toolkit) support is missing, for instance.

Users that are interested in trying RTAI/Fusion can get a jump-start with Debian, which has RTAI packages in testing and unstable.

Though the Real Time market is a small niche of the Linux community, it's good to see healthy projects like RTAI/LXRT and RTAI/Fusion that will give Linux the opportunity to achieve the goal of world domination.

(Log in to post comments)