Approaches to realtime
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
, 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 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
The original RTAI project was designed specifically for DIAPM projects,
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
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
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.
to post comments)