The Basics of RTLinux
CS 450-1 Operating Systems
Fall 2003
Jason Siciliano
Ross Johnston
Jonathan Blackburn
Page 1 of 9
Table of Contents
Introduction
page 1
Body of paper
page 2
Conclusion
page 7
Bibliography
page 9
Page 2 of 9
Introduction:
A real-time operating system is a system that performs operations within a
predefined amount of time. (Silbershatz, 18) Most real-time systems are embedded in
simple machines and appliances. These systems are often very simple, performing only
one or two tasks. Other real-time systems are run from terminals or personal computers,
and, much like their embedded counterparts, are designed to be simple but efficient. In a
real-time system, due to the time restrictions, functions that have a variable time to
completion are usually removed from real-time systems. Also, functions that have an
extremely good average run time, but have instances with bad maximum run time to
completion, also are not used. Since secondary storage access times vary, all data is kept
in primary storage. Human interaction with the system is absent as well.
Recently there has been research into transforming a general purpose time-sharing
operating system into a hard real-time operating system. Real-Time (RT) Linux is one
such project. Started by Michael Barabanov and Victor Yodaiken at New Mexico
Institute of Technology as a thesis project, RT Linux is now developed and produced by
FSMLabs.
The goal of the RT Linux project was to make an efficient, open source real-time
operating system (RTOS), something that the RTOS market lacked.(thesis,2) The Linux
Kernel provided a solid basis to accomplish this goal. Linux already had a large user
base and volumes of existing code. The Linux kernel is efficient, open, and freely
distributed. While the use of the Linux kernel is convenient, it is also problematic in that
Linux is a time-sharing operating system. This means the scheduling, timing and
Page 3 of 9
interrupt latency do not meet the requirements of a RTOS. Another problem caused by
the implementation of the RT Linux kernel, is interprocess communication.
Basic architecture:
RT Linux is designed so that the RT kernel and the standard Linux kernel can
coexist. While there are no RT processes running on the system, the Linux kernel and
non-RT processes run normally, without any interruption from the RT kernel. In general,
everything that can be done in Linux, is handled in the regular Linux kernel, leaving the
RT kernel with as little process strain as possible. When a RT task arrives on the system,
the RT kernel preempts the Linux kernel and takes control (journal or thesis). Data
structures exist that allow communication between the RT kernel and the Linux kernel.
This allows programs to include both real-time and non-real-time functions. Non-realtime interrupts are handled by the Linux kernel with the permission of the RT kernel and
real-time interrupts are exclusively handled by the RT scheduler. All hardware
interaction is handled using the Linux kernel.
Interrupt handling:
Interrupt latency refers to the period of time in which interrupts are disabled. The
design challenge associated with lowering this value so they are acceptable for a RT
operation is that the disabling of the interrupts is used for kernel synchronization. Before
entering its critical section, the kernel disables interrupts, enabling them once more after
exiting the critical section. Since the design of RT Linux calls for the Linux kernel to
coexist with the RT kernel, it cannot simply be erased or changed. To solve this problem
a software emulator is placed between the Linux kernel and the hardware interrupt
controller.
Page 4 of 9
Linux uses three functions to handle interrupts. The cli macro executes the x86
machine instructions, which clears the enable interrupt bit in the processor control word.
The sti macro executes the x86 instruction that sets the interrupt flag bit, enabling
interrupts. The iret function saves and restores the cpu state before and after the interrupt
handler is called. All instances of these functions in Linux are replaced with S_CLI,
S_STI, and S_IRET macros. This routes all hardware interrupts through the RT interrupt
handler. The S_CLI routine clears the interrupt state variable in the emulator. When the
Linux kernel executes the S_STI macro, data is pushed onto a stack (emulating a trap)
and then calls the S_IRET routine.
The S_IRET routine saves the contents of the registers and initializes the data
segment register to point to the kernel. This ensures the kernel data address spaces is
accessible, thus making global variables accessible. The bit string variable that contains
pending interrupts is scanned. If a set bit is not found, the interrupt state variable is set
and control is returned from the interrupt via the iret instruction. If a set bit is found,
control is shifted to the Linux handler. The handler ends with an S_IRET call so other
pending interrupts will be serviced.
During the execution of the iret routine, the Linux kernel also examines the
contents of the stack to determine if the interrupt occurred in kernel mode or user mode.
If it determines the interrupt originated from the kernel it will not use its own scheduler.
Because of this, the routines that prepare the stacks make it appear as if control has been
passed directly from the hardware interrupt controller. (A real time Linux, 7)
Modularity:
Page 5 of 9
To reduce the overhead of context switching and protection level changes, RT
tasks are all implemented in kernel address space. This is done by making RT tasks
loadable kernel modules. Linux allows Kernel Modules to be loaded and linked without
rebooting the system. While this keeps the RT processes in a single address space, it
leads to problems with inter-process communication.
Process manipulation:
In RT Linux, tasks are divided into a RT portion that executes in real time and a
non-RT portion that executes as a normal Linux process. There needs to be a method of
communication between the RT processes and the non-RT processes. RT FIFOs, or
First-In-First-Out queues, are used to fulfill this communication requirement. RT FIFOs
are implemented much like Unix Pipes. Data is written at one end of the queue, and read
from the other end. While RT FIFOs are in fact Pipes, the difference lies in who
communicates with them. Unix Pipes allow child processes to communicate with parent
processes, or it allows communication between two user processes. (Silbershatz, 733) RT
FIFOs allow communication between a RT process and a user process, or between a
protected kernel process and an unprotected user process. (Real Time Linux II, 7)
Linux also provides other means of interprocess communication but they are of no
use because the Linux kernel may be preempted by the RT kernel. The read and writes to
the RT FIFOs can not be blocked, thus avoiding the priority inversion problem. (Thesis,
18) RT processes and Linux processes view and handle RT FIFOs differently. To a
Linux process, the RT FIFO is a character device. It appears as a device file /dev/rtf1,
/dev/rtf2, etc. This allows ordinary file functions (open(), close(), write(), and read()) to
be used. To a RT process the RT FIFO is addressed by an integer number. There is a
Page 6 of 9
static number of RT FIFOs that can exist at any one time. The number is determined
during kernel configuration. If the number of RT FIFOs needs to be changed the kernel
must be recompiled. (Thesis, 18). Because of this, functions are provided that create,
destroy, and modify RT FIFOs, freeing FIFOs for use by other processes. These functions
appear in the appendix. Only a RT process has the power to create, modify, or destroy
the FIFO. Linux processes can only open, close, read, or write to the FIFO.
Scheduler:
The scheduler is possibly the most important part of a RTOS. Since, one
scheduler does not work best for all applications, RT Linux allows the scheduler to be
changed to an entirely different scheduler. This is done using loadable kernel modules.
This allows the user to test different scheduler algorithms and find one that best suits
his/her application needs.
RT Linux comes with two schedulers, a Priority-based preemptive scheduler and
an Earliest Deadline First scheduler. (Thesis, 16) The Priority-based preemptive
scheduling policy works by assigning each task that is ready to execute a priority number.
The task with the highest priority executes. Since the policy is preemptive, if a task
arrives on the system and has a higher priority than the currently executing task. The
currently executing task voluntarily relinquishes the CPU to the higher priority task. The
Earliest Deadline First scheduler chooses the task with the lowest deadline to run.
(Thesis, 16) RT Linux also implements a Rate Monotonic Scheduling algorithm for
periodic tasks with deadlines equal to periods. Under this algorithm, tasks with lower
periods have higher priorities.
Page 7 of 9
The RT Linux schedulers give Linux the lowest priority. By doing this, it is
guaranteeing that Linux tasks will run only when there are no real-time tasks on the
system. When control is passed to Linux, the state of the software interrupt emulator is
saved and then the emulated interrupts are disabled. Upon returning control to the RT
kernel, the emulator state is restored. This way of doing priorities solves one of the
fundamental problems facing real time systems. Real time systems have to handle nonreal time problems and real time problems at the same time. If you combine the two in
one kernel, it inevitably erodes the performance of the real time processes, because the
kernel has to deal with non-real time overhead. With RTLinux, both real and non-real
time processes are handled, without performance erosion, due to there actually being two
kernels, taking care of both kinds of processes. In fact, on machines with more than one
processor, the RTLinux kernel gets its own processor to further separate the two kernel
dependencies upon each other.
Page 8 of 9
Bibliography
Barabanov, Michael (1997). Thesis
Divakaran, Dinil (2002). “RTLinux HOWTO” URL:
http://www.tldp.org/HOWTO/RTLinux-HOWTO-6.html
Nutt, Gary (2001). Kernel Projects for Linux, Boston, MA: Addison-Wesley,
Ripoll, Ismael (2002). “Real-Time Linux (RT-Linux)” URL:
http://mercury.chem.pitt.edu/~sasha/LinuxFocus/English/May1998/article44.html
Silbershatz, Avi; Galvin, Peter; and Gagne, Greg (2002).
“Operating System Concepts: Sixth Edition” New York, NY P.733
Yodaiken, Victor and Barabanov, Michael “A Real-Time Linux”
URL: http://www.fsmlabs.com/articles/archive/usenix.pdf
Page 9 of 9