The Basics of RTLinux



The Basics of RTLinux

CS 450-1 Operating Systems

Fall 2003

Jason Siciliano

Ross Johnston

Jonathan Blackburn

Table of Contents

Introduction page 1

Body of paper page 2

Conclusion page 7

Bibliography page 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 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-real-time 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.

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:

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 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.

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 non-real 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.

Bibliography

Barabanov, Michael (1997). Thesis

Divakaran, Dinil (2002). “RTLinux HOWTO” URL:



Nutt, Gary (2001). Kernel Projects for Linux, Boston, MA: Addison-Wesley,

Ripoll, Ismael (2002). “Real-Time Linux (RT-Linux)” URL:



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:

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download