RTLinux

Last updated
RTLinux
Original author(s) Victor Yodaiken, Michael Barabanov
Developer(s) FSMLabs, Wind River Systems
Written in C
Operating system Linux
Available in English
Type Kernel
License GPL2

RTLinux is a hard realtime real-time operating system (RTOS) microkernel that runs the entire Linux operating system as a fully preemptive process. The hard real-time property makes it possible to control robots, data acquisition systems, manufacturing plants, and other time-sensitive instruments and machines from RTLinux applications. The design was patented. [1] Despite the similar name, it is not related to the Real-Time Linux project of the Linux Foundation. [2]

Contents

RTLinux was developed by Victor Yodaiken, Michael Barabanov, Cort Dougan and others at the New Mexico Institute of Mining and Technology and then as a commercial product at FSMLabs. Wind River Systems acquired FSMLabs embedded technology in February 2007 and made a version available as Wind River Real-Time Core for Wind River Linux. As of August 2011, Wind River has discontinued the Wind River Real-Time Core product line, effectively ending commercial support for the RTLinux product.

Background

The key RTLinux design objective [3] was to add hard real-time capabilities to a commodity operating system to facilitate the development of complex control programs with both capabilities. [4] [5] For example, one might want to develop a real-time motor controller that used a commodity database and exported a web operator interface. Instead of attempting to build a single operating system that could support real-time and non-real-time capabilities, RTLinux was designed to share a computing device between a real-time and non-real-time operating system so that (1) the real-time operating system could never be blocked from execution by the non-real-time operating system and (2) components running in the two different environments could easily share data. As the name implies RTLinux was originally designed to use Linux as the non-real-time system [6] but it eventually evolved so that the RTCore real-time kernel could run with either Linux or Berkeley Software Distribution (BSD) Unix.

Multi-Environment Real-Time (MERT) was the first example of a real-time operating system coexisting with a Unix system. MERT relied on traditional virtualization techniques: the real-time kernel was the host operating system (or hypervisor) and Bell Systems Unix was the guest. RTLinux was an attempt to update the MERT concept to the PC era and commodity hardware. It was also an attempt to also overcome the performance limits of MERT, particularly the overhead introduced by virtualization.

Instead of encapsulating the guest OS in a virtual machine, RTLinux virtualized only the guest interrupt control. This method allowed the real-time kernel to convert the guest operating system into a system that was completely preemptible but that could still directly control, for example, storage devices. In particular, standard drivers for the guest worked without source modification although they needed to be recompiled to use the virtualization "hooks". See also paravirtualization. The Unix pipe was adapted to permit real-time and non-real-time programs to communicate, although other methods such as shared memory were also added.

From the programmer's point of view, RTLinux originally looked like a small threaded environment for real-time tasks plus the standard Linux environment for everything else. The real-time operating system was implemented as a loadable kernel module which began by virtualizing guest interrupt control and then started a real-time scheduler. Tasks were assigned static priorities and scheduling was originally purely priority driven. The guest operating system was incorporated as the lowest priority task and essentially acted as the idle task for the real-time system. Real-time tasks ran in kernel mode. Later development of RTLinux adopted the Portable Operating System Interface (POSIX) POSIX threads application programming interface (API) and then permitted creation of threads in user mode with real-time threads running inside guest processes. In multiprocessor environments threads were locked to processor cores and it was possible to prevent the guest thread from running on designated core (effectively reserving cores for only real-time processing).

Implementation

RTLinux provides the ability to run special real-time tasks and interrupt handlers on the same machine as standard Linux. These tasks and handlers execute when they need to execute no matter what Linux is doing. The worst case time between the moment a hardware interrupt is detected by the processor and the moment an interrupt handler starts to execute is under 15 microseconds on RTLinux running on a generic x86 (circa 2000). A RTLinux periodic task runs within 35 microseconds of its scheduled time on the same hardware. These times are hardware limited, and as hardware improves RTLinux will also improve. Standard Linux has excellent average performance and can even provide millisecond level scheduling precision for tasks using the POSIX soft real-time capabilities. Standard Linux is not, however, designed to provide sub-millisecond precision and reliable timing guarantees. RTLinux was based on a lightweight virtual machine where the Linux "guest" was given a virtualized interrupt controller and timer, and all other hardware access was direct. From the point of view of the real-time "host", the Linux kernel is a thread. Interrupts needed for deterministic processing are processed by the real-time core, while other interrupts are forwarded to Linux, which runs at a lower priority than real-time threads. Linux drivers handled almost all I/O. First-In-First-Out pipes (FIFO) or shared memory can be used to share data between the operating system and RTLinux.

Objective

The key RTLinux design objective is that the system should be transparent, modular, and extensible [ citation needed ]. Transparency means that there are no unopenable black boxes and the cost of any operation should be determinable. Modularity means that it is possible to omit functionality and the expense of that functionality if it is not needed. And extensibility means that programmers should be able to add modules and tailor the system to their requirements. The base RTLinux system supports high speed interrupt handling and no more. It has simple priority scheduler that can be easily replaced by schedulers more suited to the needs of some specific application. When developing RTLinux, it was designed to maximize the advantage we get from having Linux and its powerful capabilities available.

Core components

RTLinux is structured as a small core component and a set of optional components. The core component permits installation of very low latency interrupt handlers that cannot be delayed or preempted by Linux itself and some low level synchronization and interrupt control routines. This core component has been extended to support SMP and at the same time it has been simplified by removing some functionality that can be provided outside the core.

Functions

Most RTLinux functions are in a set of loadable kernel modules that provide optional services and levels of abstraction. These modules include:

  1. rtl sched - a priority scheduler that supports both a "lite POSIX" interface described below and the original V1 RTLinux API.
  2. rtl time - which controls the processor clocks and exports an abstract interface for connecting handlers to clocks.
  3. rtl posixio - supports POSIX style read/write/open interface to device drivers.
  4. rtl fifo - connects RT tasks and interrupt handlers to Linux processes through a device layer so that Linux processes can read/write to RT components.
  5. semaphore - a contributed package by Jerry Epplin which gives RT tasks blocking semaphores.
  6. POSIX mutex support is planned to be available in the next minor version update of RTLinux.
  7. mbuff is a contributed package written by Tomasz Motylewski for providing shared memory between RT components and Linux processes.

Realtime tasks

RTLinux realtime tasks get implemented as kernel modules similar to the type of module that Linux uses for drivers, file systems, and so on. Realtime tasks have direct access to the hardware and do not use virtual memory. On initialization, a realtime task (module) informs the RTLinux kernel of its deadline, period, and release-time constraints.

Threads

RT-Linux implements a POSIX API for a thread's manipulation. A thread is created by calling the pthread_create function. The third parameter of pthread_create is a function which contains the code executed by the thread.

It is necessary to set thread priorities in RTLinux. Threads with higher priorities can preempt threads with lower priorities. For example, we can have a thread controlling a stepper motor. In order to move the motor fluently, it is necessary to start this thread in strictly regular intervals. This can be guaranteed by assigning a high priority to this thread. The example threads2.c sets different thread priorities. Setting of thread priority is done by code shown below:

intinit_module(void){pthread_attr_tattr;structsched_paramparam;pthread_attr_init(&attr);param.sched_priority=1;pthread_attr_setschedparam(&attr,&param);pthread_create(&t1,&attr,&thread_code,"this is thread 1");rtl_printf("Thread 1 started\n");...}

The output the program is as follows.

Thread 1 started Thread 2 started Thread 3 started Message: this is thread 1 Message: this is thread 2 Message: this is thread 2 Message: this is thread 2 Message: this is thread 1 Message: this is thread 1 Message: this is thread 3 Message: this is thread 3 Message: this is thread 3

The thread 2 has the highest priority and the thread 3 has the lowest priority. The first message is printed by the middle priority thread 1 because it is started a short time before the thread 2.

See also

Related Research Articles

In computing, a context switch is the process of storing the state of a process or thread, so that it can be restored and resume execution at a later point, and then restoring a different, previously saved, state. This allows multiple processes to share a single central processing unit (CPU), and is an essential feature of a multiprogramming or multitasking operating system. In a traditional CPU, each process - a program in execution - utilizes the various CPU registers to store data and hold the current state of the running process. However, in a multitasking operating system, the operating system switches between processes or threads to allow the execution of multiple processes simultaneously. For every switch, the operating system must save the state of the currently running process, followed by loading the next process state, which will run on the CPU. This sequence of operations that stores the state of the running process and the loading of the following running process is called a context switch.

<span class="mw-page-title-main">Operating system</span> Software that manages computer hardware resources

An operating system (OS) is system software that manages computer hardware and software resources, and provides common services for computer programs.

A real-time operating system (RTOS) is an operating system (OS) for real-time computing applications that processes data and events that have critically defined time constraints. An RTOS is distinct from a time-sharing operating system, such as Unix, which manages the sharing of system resources with a scheduler, data buffers, or fixed task prioritization in a multitasking or multiprogramming environment. Processing time requirements need to be fully understood and bound rather than just kept as a minimum. All processing must occur within the defined constraints. Real-time operating systems are event-driven and preemptive, meaning the OS can monitor the relevant priority of competing tasks, and make changes to the task priority. Event-driven systems switch between tasks based on their priorities, while time-sharing systems switch the task based on clock interrupts.

OS-9 is a family of real-time, process-based, multitasking, multi-user operating systems, developed in the 1980s, originally by Microware Systems Corporation for the Motorola 6809 microprocessor. It was purchased by Radisys Corp in 2001, and was purchased again in 2013 by its current owner Microware LP.

<span class="mw-page-title-main">Thread (computing)</span> Smallest sequence of programmed instructions that can be managed independently by a scheduler

In computer science, a thread of execution is the smallest sequence of programmed instructions that can be managed independently by a scheduler, which is typically a part of the operating system. In many cases, a thread is a component of a process.

Processor affinity, or CPU pinning or "cache affinity", enables the binding and unbinding of a process or a thread to a central processing unit (CPU) or a range of CPUs, so that the process or thread will execute only on the designated CPU or CPUs rather than any CPU. This can be viewed as a modification of the native central queue scheduling algorithm in a symmetric multiprocessing operating system. Each item in the queue has a tag indicating its kin processor. At the time of resource allocation, each task is allocated to its kin processor in preference to others.

In computing, scheduling is the action of assigning resources to perform tasks. The resources may be processors, network links or expansion cards. The tasks may be threads, processes or data flows.

In computing, Quark is an operating system kernel used in MorphOS. It is a microkernel designed to run fully virtualized computers, called boxes. As of 2020, only one box is available, the ABox, that lets users run extant AmigaOS software compiled for Motorola 68000 series and PowerPC central processing units (CPUs).

<span class="mw-page-title-main">RTAI</span> Real-time extension for the Linux kernel

Real-time application interface (RTAI) is a real-time extension for the Linux kernel, which lets users write applications with strict timing constraints for Linux. Like Linux itself the RTAI software is a community effort. RTAI provides deterministic response to interrupts, POSIX-compliant and native RTAI real-time tasks. RTAI supports several architectures, including IA-32, x86-64, PowerPC, ARM, and MIPS.

Adeos is a nanokernel hardware abstraction layer (HAL), or hypervisor, that operates between computer hardware and the operating system (OS) that runs on it. It is distinct from other nanokernels in that it is not only a low level layer for an outer kernel. Instead, it is intended to run several kernels together, which makes it similar to full virtualization technologies. It is free and open-source software released under a GNU General Public License (GPL).

In computer systems programming, an interrupt handler, also known as an interrupt service routine or ISR, is a special block of code associated with a specific interrupt condition. Interrupt handlers are initiated by hardware interrupts, software interrupt instructions, or software exceptions, and are used for implementing device drivers or transitions between protected modes of operation, such as system calls.

The LynxOS RTOS is a Unix-like real-time operating system from Lynx Software Technologies. Sometimes known as the Lynx Operating System, LynxOS features full POSIX conformance and, more recently, Linux compatibility. LynxOS is mostly used in real-time embedded systems, in applications for avionics, aerospace, the military, industrial process control and telecommunications. As such, it is compatible with military-grade security protocol such as wolfSSL, a popular Transport Layer Security (TLS/SSL) library.

Signals are standardized messages sent to a running program to trigger specific behavior, such as quitting or error handling. They are a limited form of inter-process communication (IPC), typically used in Unix, Unix-like, and other POSIX-compliant operating systems.

In computer science, asynchronous I/O is a form of input/output processing that permits other processing to continue before the I/O operation has finished. A name used for asynchronous I/O in the Windows API is overlapped I/O.

<span class="mw-page-title-main">Completely Fair Scheduler</span> Linux process scheduler

The Completely Fair Scheduler (CFS) is a process scheduler that was merged into the 2.6.23 release of the Linux kernel and is the default scheduler of the tasks of the SCHED_NORMAL class. It handles CPU resource allocation for executing processes, and aims to maximize overall CPU utilization while also maximizing interactive performance.

LynxSecure is a least privilege real-time separation kernel hypervisor from Lynx Software Technologies designed for safety and security critical applications found in military, avionic, industrial, and automotive markets.

<span class="mw-page-title-main">Linux kernel</span> Operating system kernel

The Linux kernel is a free and open-source, monolithic, modular, multitasking, Unix-like operating system kernel. It was originally written in 1991 by Linus Torvalds for his i386-based PC, and it was soon adopted as the kernel for the GNU operating system, which was written to be a free (libre) replacement for Unix.

<span class="mw-page-title-main">Brain Fuck Scheduler</span> Process scheduler in Linux

The Brain Fuck Scheduler (BFS) is a process scheduler designed for the Linux kernel in August 2009 based on earliest eligible virtual deadline first scheduling (EEVDF), as an alternative to the Completely Fair Scheduler (CFS) and the O(1) scheduler. BFS was created by an experienced kernel programmer Con Kolivas.

SCHED_DEADLINE EDF-based task scheduler in the Linux kernel

SCHED_DEADLINE is a CPU scheduler available in the Linux kernel since version 3.14, based on the earliest deadline first (EDF) and constant bandwidth server (CBS) algorithms, supporting resource reservations: each task scheduled under such policy is associated with a budget Q, and a period P, corresponding to a declaration to the kernel that Q time units are required by that task every P time units, on any processor. This makes SCHED_DEADLINE particularly suitable for real-time applications, like multimedia or industrial control, where P corresponds to the minimum time elapsing between subsequent activations of the task, and Q corresponds to the worst-case execution time needed by each activation of the task.

<span class="mw-page-title-main">Rodos (operating system)</span> Real-time operating system

Rodos is a real-time operating system for embedded systems and was designed for application domains demanding high dependability.

References

  1. ↑ yodaiken, victor. "Adding real-time support to general purpose operating systems". USPTO. USPTO. Retrieved 19 January 2022.
  2. ↑ "realtime:start [Linux Foundation Wiki]". wiki.linuxfoundation.org.
  3. ↑ Barabanov, Michael. Introducing RTLinux (Report). Linux Journal. CiteSeerX   10.1.1.302.3221 .
  4. ↑ Yodaiken, Victor (1999). The RTLinux Manifesto (PDF) (Report). 5th Linux Conference Proceedings.
  5. ↑ Yodaiken, Victor (1996). Cheap Operating systems Research (Report). Cambridge, Massachusetts: Proceedings of the First Conference on Freely Redistributable Systems. CiteSeerX   10.1.1.39.9505 .
  6. ↑ Barabanov, Michael (1996). A Linux Based Real-Time Operating System (PDF) (M.S.).

Sources

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.