Patches to turn the Linux Kernel into a real time kernel were submitted today, 9th of October 2004, by Montavista people to the Linux Kernel mailing list.
Montavista has been actively working for years to port Linux to embedded devices. Usually this kind of devices needs a real time operating system that can interact in a really fast way: this means working on lowering the interrupt latency and the task preemption latency, mainly, as stated by the developers from Montavista in their mail to the kernel list.

The purpose of this effort is to to further reduce interrupt latency and to dramatically reduce task preemption latency in the 2.6 kernel series. Our broad objective is to achieve preemption latency bounded by the worst case IRQ disable.

About why applying these patches to the Linux kernel the answer is given by this other piece of the mail: Our objective is to enable the Linux 2.6 kernel to be usable for high-performance multi-media applications and for applications requiring very fast, task level reliable control functions.

The AV industry is building HDTV related technology on Linux, and desktop systems are increasingly used for similar applications.

Cell phones, PDAs and MP3 players are converging into highly integrated devices requiring a large number of threads. These threads support a vast array of communications protocols (IP, Bluetooth, 802.11, GSM, CDMA, etc.). Especially the cellular-based protocols require highly deadline-sensitive operations to work reliably.

GPS processing, for example, requires hard real-time tasks and guaranteed KHz frequency interrupt processing. Linux-based remote controlled GPS stations at inaccessible or dangerous sites, like the inside of Mt. St. Helens, stream live data via IP.

Additionally, Linux is being increasingly utilized in traditional real-time control environments including radar processing, factory automation systems, "in the loop" process control systems, medical and instrumentation systems, and automotive control systems. Many times these systems have task level response requirements in the 10's to hundreds of microsecond ranges, which is a level of guaranteed task response not achievable with current 2.6 Linux technology.

At this point the patched kernels, according to Montavista, are fairly stable. That means that you can experience hangs under heavy load and in very low memory conditions (so let's say in stress conditions). At this moment the kernel is able to give a task response in the order of the 100's of microseconds, so the final target is not achieved, but this is due to the big amount of debug code.
The reason for merging this code into the main kernel tree, explain Montavista, is the need to begin a real discussion moment on real time technology implementation for 2.6 kernel serie with all the other industries working on it.

As for the implementation specifics Montavista says: We have substituted the definition of kernel spinlocks with a mutex abstraction that uses the P-mutex from the Bundeswehr University in Munich, Germany: http://inf3-www.informatik.unibw-muenchen.de/research/linux/mutex/

The spinlock definitions have been abstracted to invoke a crude but effective #define-based substitution of spin_lock to mutex_lock functions (in linux/kmutex.h).

We have abstracted the mutex layer to allow configuration and selection of the mutex implementation. We have used a simple mutex implementation, but intend to support use of other mutexes, for example the existing system semaphore, or third party plugins such as the the FUSYN project.