Xenomai:Roadmap
From Xenomai
Contents |
[edit] Roadmap
[edit] Introduction
This document presents the general roadmap for the Xenomai project.
Xenomai was born in 2001, out of a basic idea: support traditional RTOS APIs over a Linux-based real-time framework, so that existing industrial applications coming from the proprietary world could migrate easily to a GNU/Linux-based environment, while keeping stringent real-time guarantees. To this end, the core Xenomai technology exhibits an abstract real-time nucleus, which provides generic building blocks for implementing real-time APIs, aka "skins". This way, a skin can emulate a proprietary API efficiently, based on a reusable real-time core.
Today, 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. Supported real-time APIs include POSIX 1003.1b, VxWorks, pSOS+, VRTX and uITRON.
[edit] Background
[edit] Integrating Hard Real-Time into Linux
Albeit the real-time Linux ecosystem is usually keen on dividing itself between the "co-kernel" and "native real-time preemption" approaches, fact is that such distinction is not relevant when it comes to Xenomai.
Firstly, Xenomai has been designed to separate into distinct layers the generic RTOS features it provides (e.g. basic thread abstraction and real-time scheduling properties), from the arch-dependent real-time enabling capabilities it needs from the hosting hardware to implement them (e.g. context switch support and deterministic interrupt latency). For instance, this separation allows to run the Xenomai core and interfaces over a simulation engine, which in turn provides a fully virtualized real-time environment. In other words, Xenomai is able to use the most appropriate real-time enabling technology available with the underlying target to support its API personalities, or skins.
Secondly, the project keeps investing time and energy to get the highest possible level of integration between the real-time sub-system it provides, and the native Linux environment it is based on. Keeping the usual programming model for real-time applications has always been considered as much as important as guaranteeing the lowest latency figures achievable on any given platform. For instance, even when underlaid by a co-kernel technology, application developers relying on Xenomai can still use native debugging tools such as GDB.
[edit] Xenomai 1
Started during the summer of 2001, this effort has built the foundations of the project. Xenomai 1.1.1, the last release of this branch, already featured most of the generic RTOS abstractions we are still using today. It was able to run various traditional RTOS skins built over the generic core, which were usable by applications embodied into kernel modules. By mid-2002, the system could run over different real-time enabling layers, such as Adeos, or the event-driven simulation engine still available today.
[edit] Xenomai 2
The technology exhibited by the v2.x series has been started during the summer of 2003. For two years, Xenomai has established a close cooperation with the RTAI project, in order to create an industrial-grade framework for building real-time applications over the GNU/Linux environment. The resulting work, once known as the RTAI/fusion development branch, was exclusively based on the Adeos and Xenomai technology cores. Since October 2005, the Xenomai project is pursuing this goal independently again, still driven by the same international team of contributors who have participated to this effort since its inception.
Xenomai 2 has focused on getting a high level of integration with the GNU/Linux environment, so that the regular user-space programming model is preserved when writing real-time applications. In parallel, a major refactoring has taken place, in order to ease the porting effort to other architectures, as a result of which, Xenomai 2 is currently running over six architectures with Linux 2.4 and 2.6 kernels, whilst Xenomai 1 would only run over 2.4/x86.
Additionally, Xenomai 2 has extended the set of real-time interfaces available to user-space applications:
- The POSIX 1003.1b skin guarantees ultra-low latencies to user-space applications, and conforms to the ubiquitous standard for real-time programming.
- The RTDM (Real-Time Driver Model) interface provides a skin-independent framework for writing real-time device drivers, and accessing them through a POSIX interface. RTDM helps to follow the well-known design principle of clean separation between hardware interface and application program, also when strict deterministic behaviour is required.
- The native Xenomai skin provides a rich API, which leverages the capabilities of the underlying real-time core, with semantics close to the traditional RTOS APIs.
We also made sure to enable Xenomai for use with key debugging tools:
- KGDB and GDB, respectively for kernel-based and user-space debugging.
- The I-Pipe tracer, used to uncover latency spots or to trace kernel execution at microlevel.
- The ability to run the entire Xenomai core and APIs over an event-driven simulation system, for host-based development, testing and debugging.
- The preliminary support for coupling the Xenomai core to LTTng.
[edit] Toward Xenomai 3
While we were working hard on Xenomai 2, two major trends have been emerging. Firstly, the effort for adding native real-time capabilities to the Linux kernel has reached a critical mass with Ingo Molnar's PREEMPT_RT patch series. Secondly, a growing number of industrial applications are being ported to GNU/Linux, which translates into large amounts of legacy source code, projects need to accommodate with.
[edit] Preserving the heritage
The co-kernel technology Xenomai currently uses is based on Adeos/I-pipe, a lightweight and mature real-time enabling layer for the Linux kernel, which is available for various architectures at low engineering and maintenance cost. Porting the I-pipe to a new architecture is fairly simple, and the overhead induced by this simple and straightforward interrupt virtualization layer is small.
A co-kernel based architecture has some distinct advantages we want to keep providing to Xenomai users:
- It decouples Xenomai from the development cycle of standard Linux, thus allowing to pick the desired (or required) kernel version more freely.
- It can simplify the worst-case analysis and keeps the results valid over update cycles of the vanilla kernel.
- It allows to fine-tune the non-real-time part for throughput without negative impact on the real-time job.
[edit] Goals of Xenomai 3
This said, the undergoing PREEMPT_RT effort opens a promising path to get short bounded latencies natively, for a variety of applications, on selected hardware platforms for which this technology is available and efficient. In this respect, PREEMPT_RT creates opportunities to extend the relevance of Xenomai as a migration tool.
Xenomai 3 will focus on supporting both co-kernel and native preemption as real-time enabling technologies, and provide more traditional RTOS skins.
This evolution is going to be three-fold:
- Allow our real-time nucleus to either rely on the co-kernel technology (i.e. Adeos) or PREEMPT_RT-based native preemption, to provide its services to the APIs built over it. Such duality will be seamlessly integrated, so that implementation-wise, it will be confined to the nucleus and architecture-dependent layers. When running over a PREEMPT_RT kernel, Xenomai will not require any interrupt virtualization add-on such as Adeos anymore.
- Extend the number of available traditional RTOS APIs mimicked by Xenomai skins, to open more options for migrating existing applications to a GNU/Linux environment.
- Enhance the RTDM layer and enrich the RTDM-based driver collection hosted by Xenomai.
[edit] Evolving RTDM in Xenomai
With porting Xenomai over PREEMPT_RT, RTDM will be given the unique chance of providing a driver framework for both native and co-scheduling real-time Linux. Whenever this development will demand careful adjustments to the current API, these revisions will be tagged and clearly documented as before.
And while RTDM will go on enhancing its interfaces, also to provide user-space driver support as seamlessly as feasible, the design will always follow the maxim to keep features reduced to the required minimum for real-time device drivers. Straight interfaces and concise core services help to review critical drivers as well as the driver framework itself with respect to functional and temporal correctness.
We will furthermore continue integrating contributed high-quality industrial drivers or driver stacks into the main repository. And we will foster the specification of additional device profiles that provide hardware independent APIs, while keeping the door open for vendor-specific extensions.
[edit] Conclusion
To sum up, the way Linux gets real-time capabilities, either by native real-time preemption or a co-kernel approach, is not the most significant issue to us. What really matters are the interfaces Linux will provide on top of those capabilities, especially to ease the migration process from legacy real-time systems to GNU/Linux.
[edit] Links
- Xenomai Task Market: list/schedule of enhancements, fixes, refactorings, or wishes to improve Xenomai in future versions
