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.
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.
The EVL core is maintained in the following GIT repository:
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>-rebaseif added to a rebase branch.
v<kversion>-evl<serial>if added to a merge branch.
The strictly linear development workflow of libevl is simpler in comparision to the EVL
core. There is a single
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.
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,
in some release of
is not in the range defined by
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
C macro-definition. This information can also be retrieved at
runtime by calling the evl_get_version()
In any case, there is no strict relationship between a given EVL core
release tag and a libevl
release tag. A particular
release might be usable with multiple subsequent EVL core releases and
conversely, provided the ABI requirements are met.