Development process

Xenomai 4 components

The Xenomai 4 project works on three software components:

The Dovetail interface, which introduces a high-priority execution stage into the linux kernel logic, on which a functionally-independent companion software core may receive interrupts and run threads.
A compact and SMP-scalable real-time core - aka the EVL core - leveraging Dovetail’s capabilities, which is intended to be the reference implementation for other Dovetail-based companion cores. As such, the Dovetail code base progresses as much as the EVL core runs on the most recent kernel releases and exercises this interface, uncovering issues. The EVL core lives in kernel space, as an optional component of the linux kernel.
A library named libevl, which implements the system call interface between applications running in user-space and the EVL core, along with a few other basic services, utilities and tests.

On the kernel side:

We want to track the latest mainline kernel code as closely as it makes sense, while dealing with the issue of developing out-of-tree code from the standpoint of the mainline kernel.
The Dovetail code must be accessible to other projects for their own use, based on releases of the reference (mainline) kernel.
At any point in time, we maintain at least the following EVL-enabled kernel branches:
- one or two branches tracking (S)LTS kernel releases of our choosing. Currently, those branches are v6.12.y-cip-evl-rebase and v6.18.y-evl-rebase.
- one branch tracking the latest upstream release to date (i.e. kernel.org tip kernel). Currently, we are tracking the v7.0-evl-rebase tree.

The SLTS kernel releases we maintain in the long run are preferably picked from the Civil Infrastructure Platform project.

The EVL core is maintained in the following GIT repository:

This repository tracks the Dovetail kernel tree, which in turn tracks the mainline kernel. The current policy is:

since the EVL core is always based on a Dovetail port to a mainline kernel release, every EVL branch is initially based on a Dovetail branch. For instance v6.12.y-cip-evl-rebase in the EVL tree originates from v6.12.y-cip-dovetail-rebase in the Dovetail tree.
the content of *-rebase branches may be rebased without notice, so that Dovetail- and EVL-related commits always appears on top of the vanilla mainline code. All EVL branches are currently rebased, we have no merge branch yet.
EVL release tags are of the form:
- v<kversion>-evl<serial>-rebase if added to a rebase branch.

The strictly linear development workflow of libevl is plain simple:

the master branch contains the linear history of official libevl tagged releases. Tags look like r<serial>, with the serial number progressing monotonically as subsequent releases are issued. This branch is never rebased.
the next branch is where the development takes place. Over time, commits from this branch are merged into the master branch when we are happy with them. This branch can be rebased anytime.

A new libevl release is usually tagged whenever any of the following happens:

the ABI exported by the EVL core has changed in a way which is not backward-compatible with the latest libevl release. In other words, EVL_ABI_PREREQ in some release of libevl is not in the range defined by [EVL_ABI_BASE..EVL_ABI_LEVEL] anymore.
the API libevl implements has changed, usually due to the addition of new services or changes to the signature of existing routine(s). This should happen rarely, since libevl is only meant to provide a small set of basic services exported by the EVL core. The API version implemented by libevl is an integer, which is assigned to the __EVL__ C macro-definition. This information can also be retrieved at runtime by calling the evl_get_version() routine.

A particular libevl release might be usable with multiple subsequent EVL core releases and conversely, provided the ABI requirements are met.

Last modified: Thu, 14 May 2026 12:49:55 +0200