|
|
|
|
|
|
|
# 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. |
Philippe Gerum <rpm@xenomai.org>