Editing RTLinux (section)

== 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">{{cite report |last=Yodaiken |first=Victor |date=1999 |title=The RTLinux Manifesto |publisher=5th Linux Conference Proceedings |url=http://www.yodaiken.com/papers/rtlmanifesto.pdf}}</ref><ref name="redist">{{cite report |last=Yodaiken |first=Victor |date=1996 |title=Cheap Operating systems Research |publisher=Proceedings of the First Conference on Freely Redistributable Systems |citeseerx=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 thesis |last=Barabanov |first=Michael |date=1996 |type=M.S. |url=http://www.yodaiken.com/papers/BarabanovThesis.pdf |title=A Linux Based Real-Time Operating System}}</ref> 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 ''[[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).