Started as a master's degree project in 1995 by Michael Barabanov and Victor Yodaiken, RTLinux is a hard real-time variant of the popular Linux desktop and server operating system. FSMLabs (FSMLabs.com) was set up to develop and market RTLinux.
Linux
The Linux kernel is incapable of running applications with hard real-time constraints since it is designed as a multipurpose, multiuser operating system. This means that every single application gets a chance to run, even if it means a lower priority application will pre-empt a high priority application. This is the way that most desktop and server operating systems work as it gives best "overall" performance for the machine, and all applications are given a chance to run. This is no use at all for real-time operating systems since high priority tasks must run even if low priority tasks are left waiting, however it may be acceptable for soft real-time applications.
The RTLinux Approach
The traditional approach to converting a non-real time kernel to real time operation is to completely rewrite large amounts of the kernel so that CPU scheduling is priority based and all the rest of the kernel is real time compliant. This can be a large and time consuming job, especially for large kernels like the Linux kernel which have lots of drivers that must be made real time compliant. Also, the Linux kernel is constantly being updated, and keeping these updates compliant would be a mammoth task.
The approach taken by Michael Barabanov was to write a simple real time operating system that the Linux kernel would run on top of. This made the task far simpler, as all that was required was for the real time part of RTLinux to pass interrupts that it did not want to deal with on to the Linux kernel, and also allow the real time and non-real time parts to communicate.
The Linux kernel runs as the lowest priority thread on the RTLinux scheduler, this means it will never pre-empt a real time task and can, except in extremely high load situations, act as a complete Linux system with very little noticeable slow down. In fact, This system works so well that when the Linux section of RTLinux is under extremely heavy load, the real time section does not show any signs of the extra load; execution latency stays unchanged from when the Linux part is under extremely light load.
Implementation
The RTLinux real time kernel receives all the interrupt requests, it then checks whether there are any real time tasks that are waiting upon these interrupts. If there are not, they are passed on for the Linux kernel to deal with. If the Linux kernel has interrupts disabled, the real time kernel queues the interrupts until the Linux kernel is ready to receive them.
The real time and non-real time tasks can communicate through special "RTFIFOs". From the Linux side they appear to be character devices like any other; they can be accessed using standard file operations such as open, close, read and write. From the real time point of view, they are slightly more complex: they are accessed through a special API that allows opening, closing, reading and writing. The real time access to the FIFOs is non-blocking, so a real time task will never block while trying to read from or write to an RTFIFO.
APIs
The RTLinux API is quite small and simple. For real time task manipulation it uses POSIX threads with the PThread API. There are also several extended functions to allow for simplified functionality or even functionality which does not exist within the PThread API. For example suspending tasks, attaching tasks to specific CPUs in multiprocessor computers and automated periodic execution have been added or simplified in RTLinux.
It also supports POSIX mutual exclusion and condition variables through the standard PThread interface. POSIX semaphores are also supported. As standard there are no message queues or other more complex message passing facilities, however there is a slightly modified API available in a module that supports queues. Alternatively, implementing a queue using the PThread Mutex's or the POSIX semaphores should not be hard. RTLinux also supports POSIX mmap() calls. This allows real time tasks and Linux tasks to access shared sections of memory.
RTLinux real time tasks can access Linux kernel functions such as the Sys V Inter-Process Communication (IPC) API. This, however, is not recommended as the Linux kernel code is not designed to be used by real time tasks and can cause unwanted delays or other unexpected problems. If, for example, a Sys V IPC semaphore is used, the real time task will not block when the semaphore has already been set. Using RTLinux' own POSIX semaphores and condition variables does not have this problem, since they cause the real time tasks to block as you would expect.
RTLinux allows non-POSIX defined operations through its own simple interface. There are 35 non-POSIX functions defined in the RTLinux API. 8 of these deal with RTFIFOs, 11 manipulate interrupts and interrupt handlers and another 8 are extensions to the PThread interface. The rest deal with clocks and various other functions.
POSIX
RTLinux has been designed with the POSIX 1003.13 standard in mind. This is a standard for implementing a minimal Real Time Operating System. It defines a single, multi-threaded POSIX process running alone on a system. RTLinux uses this standard by treating each real time task as a thread within the POSIX process and treating interrupt handlers as signal handlers. On an SMP machine, RTLinux runs one POSIX process on each processor. POSIX 1003.13 also allows the real time part to avoid the complications of having a file system. RTLinux only allows real time tasks to open specific "files". These "files" are the RTFIFOs that Linux user space programs may also access.
Linux User Space
One of the primary advantages of RTLinux is the ability to access a standard Linux OS. This means anything Linux can do, RTLinux can do just as well, although not vice versa. Linux user space is where most of the non-real time IO is carried out, for example accessing hard disks or a network. This has the advantage of allowing RTLinux access to any of the thousands of devices available to Linux with little or (in most cases) no rewriting of drivers required.
Other Stuff
FSMLabs have converted BSD to run in a similar way to RTLinux so the BSD fans can have some real-time fun too. The method used to convert Linux to real-time should be able to be used to convert many more OS's, and realising this FSMLabs patented the method. However, in the spirit of open source and the GPL, they've made the patent an "open patent". Brielfy, this means any code written under the terms of the patent must be GPL'd. See FSMLabs.com for further details.
The closest thing to a website RTLinux has is at http://FSMLabs.com/community where there are several discussion lists as well as technical articles about RTLinux.