User:Victoryodaiken/sandbox

RTLinux is a hard realtime RTOS microkernel that runs the entire Linux operating system as a fully preemptive process. It is the hard realtime variant of Linux that makes it possible to control robots, data acquisition systems, manufacturing plants, and other time-sensitive instruments and machines.

It was developed by Victor Yodaiken (Yodaiken 1999), Michael Barabanov (Barabanov 1996), 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 RTLinux although it is still available as a free software product.

Objective
The key RTLinux design objective was to add hard real-time capabilities to a commodity operating system to facilitate the development of complex control programs with both capabilities. 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 first designed to use Linux as the non-real-time system, but eventually evolved so that the RTCore real-time kernel could run with either Linux or BSD UNIX.

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 and to also overcome the performance limits of MERT. The technique it used was to only virtualize the guest interrupt control. This 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. The UNIX "pipe" was adopted to permit real-time and non-real-time programs to communicate although other methods such as shared memory were also added.

From the programmers point of view, RTLinux originally looked like a small threaded environment for real-time plus 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 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).

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.

Functionalities of RTLinux
The majority of RTLinux functionality is in a collection 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 is 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.

Kernel Modules
RT-Linux application is in fact a Linux kernel module. It is the same type of module, which Linux uses for drivers, file systems and so on. The main difference between RTLinux module and an ordinary Linux module is that RT-Linux module calls functions, which are offered by RT-Linux kernel whereas ordinary module uses only Linux kernel functions. The source code of a simple Linux module is given below. It contains two functions: init_module, which is called when the module is inserted to the kernel by insmod or modprobe command, and cleanup_module, which is called before module is removed by rmmod.

#include  #include   int init_module(void) {   printk("Init\n"); /*Printing "Init" in Kernel*/ return 0; } void cleanup_module(void) {   printk("Cleanup\n"); /*Clearing "Init" in Kernel*/ }

After you insert the module by running modprobe threads0, you should see a message Init on your console. After running rmmod threads0, you will see a Cleanup message. If you write RT-Linux application you use these functions to initialize and deinitialize your application.

Threads
RT-Linux implements a POSIX API for a threads manipulation. If you are familiar with a POSIX threads library (pthread) used by user-space application, it should not be problem for you to work with threads in RT-Linux. 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.

Thread priorities
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: 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"); ... }

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 short time before the thread 2.