Skip to content

GitLab

Last edited by Philippe Gerum
Page history

Common_Xenomai_Platform

A Common Xenomai Platform

Introduction

The dual kernel approach for running real-time applications on a Linux-based platform has distinctive advantages over native preemption:

  • the architectural isolation of real-time and non real-time code paths brings clarity and efficiency when designing the time-critical software. Running a dedicated real-time core independently from the common kernel activities, with a compact and well-defined set of APIs and system calls, is a crucial asset to applications with stringent latency requirements.

  • the real-time core can be extended and customized in order to support legacy or special workloads, like particular scheduling policies, real-time API flavours etc.

  • although it might help in some cases to getting even closer to bare metal latency figures, complex tuning of the regular runtime system is not a requirement. Once enabled in the kernel, the real-time core delivers its services out of the box to applications.

As an archetypal implementation of those principles, Xenomai has enabled countless real-time Linux projects over the years in the industry, despite its low-key media profile. However, Xenomai has also been facing challenges:

  • difficulties keeping the pace with the mainline kernel development, upgrading the real-time core to newer kernel releases, which is a major cause of technology obsolescence.

  • too high a barrier on entry for people to contribute to the Xenomai project beyond its core team, which is a long-standing risk on the sustainability of the project.

  • some design choices and/or limitations inherited from its inception two decades ago which have to be overcome for Xenomai to stay relevant, such as a poor SMP scalability on multi-core CPUs.

4th Age Of Xenomai

To address these issues, we want to evolve Xenomai with the following goals in mind:

  • recentre on the dual kernel approach exclusively.

  • focus on simplicity, streamline the feature set.

  • address the technical limitations of Xenomai 3.x (e.g. SMP scalability).

  • preserve the user investment in Xenomai 3.x to the largest possible extent while overcoming its limitations.

  • keep the pace with the mainline kernel development at an affordable engineering cost.

  • enable easier contributions to forward ports and their stabilization by constantly improving the documentation and structure, specifically of the core patches and commits.

These goals will require Xenomai to evolve significantly once more, for the fourth time in the project history. In parallel, we also want to keep Xenomai 3.x as a viable option, with a well-marked upgrade path to Xenomai 4.

To this end, we need a Common Xenomai Platform to be defined (CXP for short), which shall define a set of common features and interfaces all Xenomai releases starting from 3.3 would share.

What should be part of the CXP?

The following basic aspects must be covered by the Common Xenomai Platform definition:

  • a single common kernel programming interface which may be used for implementing real-time capable drivers (*).

  • a common set of supported device types and their real-time capable drivers (e.g. SPI, GPIO, UART etc).

  • a single common user API for applications to issue requests to the real-time core and device drivers (*).

  • a common set of tools usable in the course of developing a real-time application (e.g. tracers, debugger).

  • a common set of inspection features, exporting the runtime status of the real-time system (currently obtained from the /proc/xenomai interface with Xenomai 3.1 and earlier).

  • a common set of command line utilities for querying the real-time system status (e.g. list of real-time tasks and their runtime settings).

  • a common set of tests and benchmarking tools for assessing the system sanity and performance (e.g. smokey testsuite, 'switchtest' and 'latency' programs with Xenomai 3.1).

This enumeration is not exhaustive. The specification process may result in adding more items to the above list.

(*) This should not preclude particular Xenomai releases from providing additional programming interfaces as they see fit.

Timeline

Working on the CXP starts on December 1, 2021. March 31, 2021 is our deadline for completing the specification process.

CXP Specifications

Common user API

A common API available to applications is required for issuing requests to the real-time core. Specifying such interface does not preclude other APIs from co-existing in particular releases. However, use of this common API only guarantees portability across Xenomai releases starting from 3.3.

The POSIX services available from libcobalt in Xenomai 3.1 form the common API defined by the CXP. As a consequence, Xenomai 4 will provide two direct interfaces to the underlying EVL core: via the libevl API [1] which is readily available, and its own implementation of libcobalt as part of a CXP compliance.

                  Applications
      ......................................
      libalchemy            libevl libcobalt
           |                  |      |
           |                  |      |
      libcopperplate          |      |
           |                  |      |
           |                  |      |
       libcobalt              |      |
           |                  |      |
           v                  v      v
     (Cobalt core)           (EVL core)
      -----------            ---------
      Xenomai 3.x            Xenomai 4

[1] https://evlproject.org/core/user-api/

Imprint & Privacy Policy