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

When an interrupt is raised, the micro-kernel interrupt routine is executed. If the
interrupt is related to a real-time activity, a real-time thread is notified and the real-
time kernel executes its own scheduler. If the interrupt is not related to a real-time
activity, then it is “flagged.” When no real-time threads are active, Linux is resumed
and executes its own code. Moreover, any pending interrupt related to Linux is served.

In this way, Linux is executed as a background activity in the real-time executive. This
approach has the advantage of separating as much as possible the interactions between
the Linux kernel, which is very complex and difficult to modify, and the real-time
executive. It also obtains a very low average latency for real-time activities and, at the
same time, the full power of Linux on the same machine. However, there are several
drawbacks. Real-Time tasks execute in the same address space as the Linux kernel;
therefore, a fault in a user task may crash the kernel. When working with the real-time
threads, it is not possible to use the standard Linux device driver mechanism; as a
result, it is often necessary to rewrite the device drivers for the real-time application.
For example, for using the network in real-time, it is necessary to use another device
driver expressly designed for RTLinux. The real-time scheduler is a simple fixed
priority scheduler, which is POSIX compliant. There is no direct support for resource
management facilities. Some Linux drivers directly disable interrupts during some
portions of their execution. During this time, no real-time activities can be executed,
and thus the worst-case latency of real-time activities is increased.

12.3.2 RTAI

RTAI 5 (Real Time Application Interface) started as a modification of RTLinux by
Paolo Mantegazza at the Dipartimento di Ingegneria Aerospaziale, Politecnico di Mi-
lano, Italy. Through the years, the original idea of RTLinux has been considerably
changed and enhanced. RTAI is now a community project, and the source code is re-
leased as open source. Because of some uncertainty about the legal repercussion of the
RTLinux patent on RTAI, the RTAI community has developed the Adaptive Domain
Environment for Operating Systems (Adeos) nano-kernel as an alternative for RTAI's
core to get rid of the old kernel patch and exploit a more structured and flexible way to
add a real-time environment to Linux. The purpose of Adeos is not limited to RTAI's
core, but it is to provide a flexible environment for sharing hardware resources among
multiple operating systems. It also makes it easier to plug in additional features, such
as debuggers, analyzers, and standard open middleware layers, serving all operating
systems running on top of it almost without any intrusion. A comparison between
latency with and without RTAI was done by Lipari and Scordino [LS06].

5 RTAI: http://www.rtai.org