RTLinux: Difference between revisions

Revision as of 19:01, 18 October 2020

Latest revision as of 20:49, 12 July 2024

(27 intermediate revisions by 20 users not shown)

Line 1:

{{confusedShort description|Real-Timetime operating Linuxsystem}}

{{distinguish|text=[[Real-Time Linux]], the official patchset for real-time support in the Linux kernel}}

{{more footnotes needed|date=June 2009}}

{{ infobox software<!-- The OS template doesn't fit nor the software2 template so we must create a kernel template -->

| logo =

Line 11 ⟶ 12:

| language = [[English language|English]]

| operating system = [[Linux]]

| genre = [[Kernel (computeroperating sciencesystem)|Kernel]]

| license = [[GNU General Public License#Version 2|GPL2]]

}}

'''RTLinux''' is a [[hard realtime]] [[real-time operating system]] (RTOS) [[microkernel]] that runs the entire [[Linux]] [[operating system]] as a fully [[preemption (computing)|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.<ref name="RTLinux Patent">{{cite web |last1=yodaiken |first1=victor |title=Adding real-time support to general purpose operating systems |url=https://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PTXT&s1=5,995,745.PN.&OS=PN/5,995,745&RS=PN/5,995,745 |website=USPTO |publisher=USPTO |access-date=19 January 2022 |ref=RTLPATENT}}</ref> Despite the similar name, it is not related to the [[Real-Time Linux]] project of the [[Linux Foundation]].<ref>{{cite web|url=https://wiki.linuxfoundation.org/realtime/start|title=realtime:start [Linux Foundation Wiki]|website=wiki.linuxfoundation.org}}</ref>

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<ref name="Barabanov">{{cite report |last=Barabanov |first=Michael |title=Introducing RTLinux |publisher=Linux Journal |citeseerx=10.1.1.302.3221 |ref=RTLINUX}}</ref> was to add hard real-time capabilities to a commodity operating system to facilitate the development of complex control programs with both capabilities.<ref name="manifesto">"The{{cite RTLinuxreport Manifesto",|last=Yodaiken |first=Victor Yodaiken,|date=1999 |title=The RTLinux Manifesto |publisher=5th Linux Conference Proceedings, 1999, [|url=http://www.yodaiken.com/papers/rtlmanifesto.pdf]}}</ref><ref name="redist">"Cheap{{cite Operatingreport systems Research",|last=Yodaiken |first=Victor Yodaiken.|date=1996 Published|title=Cheap inOperating thesystems Research |publisher=Proceedings of the First Conference on Freely Redistributable Systems, Cambridge MA, 1996 [http://|citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.39.9505 ]|place=Cambridge, Massachusetts }}</ref> 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<ref name="barabanov">{{cite webthesis |last=Barabanov |first=Michael |date=1996 |type=M.S. |url=http://www.yodaiken.com/papers/BarabanovThesis.pdf |title=Barabanov, Michael (1996). "A Linux Based Real-Time Operating System"|publisher=}}</ref> but it eventually evolved so that the RTCore real-time kernel could run with either Linux or [[Berkeley Software Distribution]] (BSD) UNIX[[Unix]].

[[Multi-Environment Real-Time]] (MERT) was the first example of a real-time operating system coexisting with a UNIXUnix system. MERT relied on traditional virtualization techniques: the real-time kernel was the ''host'' operating system (or [[hypervisor]]) and Bell Systems UNIXUnix 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.

TheInstead techniqueof wasencapsulating onlythe usedguest toOS virtualizein 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 UNIXUnix "''[[Pipeline (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 capabilityability ofto runningrun 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 (computing and electronics)|FIFOsFIFO]]) 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|date=August 2021}}. 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.

The key RTLinux design objective is that the system should be transparent, modular, and extensible. 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.

== FunctionalityFunctions ==

The majority ofMost RTLinux functionalityfunctions isare in a collectionset of loadable kernel modules that provide optional services and levels of abstraction. These modules include:

The majority of RTLinux functionality is in a collection of loadable kernel modules that provide optional services and levels of abstraction. These modules include:

# rtl sched - a priority scheduler that supports both a "lite POSIX" interface described below and the original V1 RTLinux API.

Line 51 ⟶ 50:

== Realtime tasks ==

RTLinux realtime tasks get implemented as [[kernel module]]s 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 <code>pthread_create</code> function. The third parameter of <code>pthread_create</code> is a function which contains the code executed by the thread.

Line 63 ⟶ 60:

int init_module(void)

{

pthread_attr_t attr;

struct sched_param param;

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");

/* ... */

}

</syntaxhighlight>

Line 96 ⟶ 93:

{{Portal|Free and open-source software}}

* [[RTAI]]. RTAI began as a variant of RTLinux called "MyRTlinux" and in later releases was claimed {{dubious|date=August 2021|reason=This phrase calls the entire article's quality and purpose into question.}} by its authors not to use the patented RTLinux virtualization technique.

* [[RMX (operating system)]]

* [[SCHED_DEADLINE]]

* [[Xenomai]]

* [[PREEMPTPreemption RT(computing)]]

* [[Linux on embedded systems]]

* [[Real-time testing]]

== References ==

{{reflistReflist}}

==Sources==

{{refbegin}}

* [http://www.yodaiken.com/papers/rtlmanifesto.pdf Yodaiken, Victor (1999). "The RTLinux Manifesto". Published in the 5th Linux Conference Proceedings]

* [http://www.yodaiken.com/papers/BarabanovThesis.pdf Barabanov, Michael (1996). "A Linux Based Real-Time Operating System"]

* [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.39.9505 Yodaiken, Victor (1996). "Cheap Operating systems Research" Published in the Proceedings of the First Conference on Freely Redistributable Systems, Cambridge MA, 1996]

* [http://www.ddj.com/cpp/184401758 Dougan, Cort (2004), "Precision and predictability for Linux and RTLinuxPro", Dr. Dobbs Journal, February 1, 2004]

* [httphttps://patimg1patentimages.usptostorage.govgoogleapis.com/99/da/90/31f19019130256/US5995745.piw?docid=US005995745&PageNum=1&&IDKey=B6CC585C7E2B&HomeUrl=pdf Yodaiken, Victor (1997), US Patent 5,995,745]

{{refend}}

== External links ==

* [http://www.yodaiken.com/papers/sync.pdf Article about RTLinux synchronization]

* [http://www.soe.ucsc.edu/~sbrandt/courses/Winter00/290S/rtlinux.pdf ''A Real-Time Linux''] {{Webarchive|url=https://web.archive.org/web/20070318062700/http://www.soe.ucsc.edu/~sbrandt/courses/Winter00/290S/rtlinux.pdf |date=2007-03-18 }}. Victor Yodaiken and Michael Barabanov, New Mexico Institute of Technology

* {{webarchive |date=2013-01-28 |url=https://archive.istoday/20130128073427/http://www.linuxdevices.com/articles/AT3694406595.html |title=Article about RT concept}}

{{Real-time operating systems}}

{{Linux}}

{{Real-time operating systems}}

{{Microkernels}}

[[Category:Linux kernel variant]]