1.1 Introduction

RT-Linux was the first approach to make Linux more real-time. The technique used by RT-Linux was first proposed by Yodaiken e Barabanov (University of New Mexico), it was initially distributed as open source software (GPL license). Later they patented the interrupt interception method. They founded FSM-labs to sell a professional version of RT-Linux. Paolo Mantegazza at Politecnico di Milano started developing on RT-Linux. However, he was in contrast with Yodaiken since the very beginning. He branched off and made its own version of RT-Linux, called RTAI. After some time, under the fear of being sued by Yodaiken, they substituted all RT-Linux code with Adeos, and re-wrote entirely the RT-nano kernel. Recently, a very interesting approach called Xenomai branched off from RTAI. Xenomai is a real-time development framework cooperating with the Linux kernel, in order to provide a pervasive, interface-agnostic, hard real-time support to user-space applications, seamlessly integrated into the GNU/Linux environment [3]. Xenomai is based on an abstract RTOS core, usable for building any kind of real-time interfaces, over a core part which exports a set of generic RTOS services. Xenomai runs over seven architectures (namely ppc, blackfin, arm, x86, x86_64, ia64 and ppc64), a variety of embedded and server platforms, and can be coupled to two major Linux kernel versions (2.4 and 2.6), for MMU-enabled and MMU-less systems. The basic structure of Xenomai is similar to RTAI but provides a better integration with Linux. Some new features of Xenomai are Xenomai threads, Skins, UVMs. Interfaces supported in Xenomai are native, POSIX, PSOS, RTAI, μ-Itron, VRTX, VxWorks, rtdm (rt driver model ).

1.2 Interrupt Management in Xenomai

Xenomai uses an Interrupt pipeline from the ADEOS Project. In Xenomai a threaded interrupt model has been chosen in order to provide a way to prioritize interrupt handling by software and allow the interrupt code to synchronize with other system code using kernel mutex, thereby reducing the need for hard interrupt masking in critical sections. Xenomai’s nano-kernel exhibits a split interrupt handling scheme, in which interrupt handling is separated into two parts. The first part is known as the Interrupt Service Routine (ISR), the second being the Interrupt Service Task (IST). When an interrupt occurs, the ISR is fired in order to deal with the hardware event as fast as possible, without any interaction with the nano-kernel. If the interrupt service code needs to reenter the nano-kernel (e.g. to resume a blocked thread), the ISR may require an associated interrupt service task to be scheduled immediately upon return. The IST has a lightweight thread context that allows it to invoke the nano-kernel services safely. Interrupt management in Xenomai is done by Interrupt Management Services which in turn uses Native Xenomai API defined in the intr.c file which is also the part of the Xenomai project.The Interrupt management services of the Native Xenomai API Module of the Xenomai API contains a number of functions to deal with interrupts, such as create, enable, disable, and delete operations. It allows interrupt handling in kernel space and also in the user space. Xenomai uses an interrupt request indirection layer, also called nano-kernel, to isolate real-time tasks from Linux processes. According to this approach, when an IRQ occurs, the nano kernel forwards the request either to a real-time task or to a conventional Linux process. In the first case, the interrupt handler runs immediately. In the second case, the request is en-queued and is further delivered to Linux when there are no more pending real-time tasks. Whenever the Linux kernel requests disabling interruptions, the nano-kernel just makes the Linux kernel believe that interruptions are disabled. The nano-kernel keeps intercepting any hardware interrupt requests. The interrupt  requests targeted to Linux are kept en-queued until the Linux kernel requests enabling interruptions. Xenomai uses Adeos for interrupt which relies on two basic concepts: domains and hierarchical interrupt pipelines. A domain defines an isolated execution environment, according to which one can run programs or even a complete operating system. The hierarchical interrupt pipeline, called I-pipe, delivers interrupt request across different domains. When a domain is registered, it is stored in a specific position in the I-pipe according to its timing requirements. The interrupt indirection mechanism handles hierarchical IRQ deliveries following the priority associated to each domain. Real-time services in Xenomai correspond to the highest priority domain in the I-pipe, which is called the primary domain. The secondary domain refers to the Linux kernel itself, from which common Linux software libraries are available.

1.3 Critical comparison of the interrupt handling mechanisms in Linux with that of Xenomai

Although Linux is a popular and widely used OS, the standard Linux kernel [3] fails to provide the timing guarantees required by critical real-time systems [6, 1]. The conventional method used to minimize the impact of interruptions on the response time of processes is to divide the implementation of interrupt handlers into two parts. The first part, referred to as the critical section of the handler, runs critical operations immediately after its activation, usually with interruptions disabled. One may enable interruptions during some parts of a critical section in order to enable pre-emption. However, such an implementation must rely on locks to ensure controlled access to shared data. The second part of the handler is dedicated to non-critical operations. Its execution can be delayed and normally happens with interruptions enabled. Just after the end of the critical section of an interrupt handler, the associated softirq becomes able to be executed. However, between the instant at which the critical section execution terminates and the instant at which the deferred softirq begins to execute, other interruptions may occur, causing a possible delay in starting the softirq execution. These possible extra delays have direct impact on real-time operating systems, where timeouts or hardware events are used to trigger tasks, in a similar manner as softirqs. Interrupt handling in Linux is reasonably efficient. Activation latency (the time interval between the instant of the event occurrence and the consequent beginning execution of real time task) of Linux in load scenario is more than the Xenomai which confirms that Linux is not suitable for real time systems. Interrupt latency (the time interval between the instant at which the interrupt request is issued and the starting time of the execution of the associated handler) of Xenomai has higher predictability. This characteristic is of paramount importance when it comes to supporting real-time systems. It is worth emphasizing that for such systems predictability is preferable than speed. In Linux the load scenarios make the interrupt and activation latencies much larger than the same in the Xenomai. The latencies in Linux in worst case can be 100 micro seconds while in Xenomai it is less than 20 micro seconds. With a threaded model Xenomai proves better than Linux. Xenomai uses the flow of interrupts to give the real-time kernel a higher priority than the Linux kernel. If a program wants something to be done, but does not have the right privilege mode of operation, the general approach is to generate a special software interrupt (called a system call). The program is interrupted, and the interrupt is given to the kernel which will do the operation on behalf of the program. The message given along in the interrupt determines which operation, or which system call has to be executed. In the case of Xenomai we have two kernels running, the normal Linux kernel and the real-time kernel. For each specific kernel a unique software interrupt is assigned. So depending on the unique interrupt number we know if it is a system call for the Linux kernel or a system call for the real-time kernel. In Xenomai since the real-time kernel gets the interrupts first, so the real-time system calls will always be run first.

1.4 Future Directions for the improvement in the design of interrupt handling

Improvements should be done on the standard Linux latency which can help Xenomai too. Xenomai should try to adopt some features from PREEMPT RT as it is found better in some performance management. As Xenomai and ADEOS can communicate similar approach must be made to integrate PREEMPT RT too with Xenomai. Xenomai should try to reduce the layered approach and directly try to handle the interrupts instead of I-pipe doing the same which makes the latency bit slow.
1.5 Conclusion
Xenomai is a generic solution to achieve hard real-time capabilities in Linux for any dimension of the project which uses Linux. It provides different APIs for creating RT tasks, timers, synchronization objects, etc., and simulates various APIs called skins for real-time application, including POSIX interface, RTAI, VxWorks, etc., which allows easier porting of existing RT applications to Linux. Xenomai ships with an experimental real-time interface called Dualion. Dualion is an API running on top of the Xenomai nano-kernel, based on the direct message-passing paradigm. Such design is aimed at distributing more easily the application workload between kernel-based real-time threads and user space Linux processes by unifying these two domains messaging capabilities in a single and fast one. Xenomai real-time Linux extensions have the main advantages to emulate standard RTOS interfaces, compatibility with no real- time Linux. Such adoption can be very cost-effective for the overall system.

References
____________________________________________________________________
[1] Abeni,L., Goel,A., Krasic,C. ,Snow, J., and Walpole,J.(2002)A measurement-based analysis of the real-time performance of the linux kernel,p1–4.
[2] Barbalace,A., Luchetta,A.,Manduchi,G., Moro,M., Soppelsa,A., and Taliercio,C.(Feb 2008),Performance Comparison of VxWorks, Linux, RTAI,and Xenomai in a Hard Real-Time Application.IEEE TRANSACTIONS ON NUCLEAR SCIENCE, V(55-1)
[3] Bovet,D.P.and Cesati,(2005)M.Understanding the Linux Kernel. O’Reilly, 3rd edition.
[4]Corbet,J.,Kret-Hartman,G.and Rubini,A.(2005)Linux device Driver.O’Reilly,3rd Edition.
[5] Xenomai Documentation [Online] available from [ 18 February 2013]
[6]Marchesotti,M.,Migliardi,M.and Podesta,R.(June 2006)A measurement-based analysis of the responsiveness of the Linux kernel,V(10),p 397–408. IEEE Computer Society.