Xenomai 4 development process

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 sanity tests.

The following aspects are addressed in the way the code is currently maintained:

  • 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.

  • Maintaining the EVL core (and Dovetail) over multiple kernel releases should remain a tractable problem.

EVL core development and releases

The EVL core is maintained in the following GIT repository:

This repository tracks the Dovetail kernel tree, which in turn tracks the mainline kernel. Details of the current policy are as follows:

  • 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 v5.10.y-evl-rebase in the EVL tree originates from v5.10.y-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.
    • v<kversion>-evl<serial> if added to a merge branch.

libevl development and releases

The strictly linear development workflow of libevl is simpler in comparision to the EVL core. There is a single master branch in the libevl GIT tree where the development takes place. Over time, libevl releases are tagged from arbitrary commits into this branch. These tags look like r<serial>, with the serial number progressing indefinitely as subsequent releases are issued.

Alt text

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.

In any case, there is no strict relationship between a given EVL core release tag and a libevl release tag. A particular libevl release might be usable with multiple subsequent EVL core releases and conversely, provided the ABI requirements are met.

Last modified: Sun, 11 Aug 2024 11:54:19 +0200