The EVL 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 several kernel releases should remain a tractable problem for a project with limited resources so far.
Currently, up to three kernel branches are maintained in parallel into the linux-evl GIT repository:
the EVL core development proper takes place into the evl/master branch (which includes the Dovetail code for that matter). This branch contains the bleeding edge EVL core implementation, tracking the development tip of linux mainline as closely as it makes sense.
finally, the dovetail/master branch is the reference code for
the Dovetail interface on top
of the latest mainline kernel
it is a basic subset of the
evl/master branch, which does NOT
include the commits related to the EVL core.
e.g., from the linux-evl repository:
$ git branch dovetail/master /* dovetail only, tracking mainline master */ evl/master /* EVL core on top of mainline master */ evl/v5.4 /* EVL core on top of stable LTS, e.g. v5.4.24 */ $ git tag -l 'v5.4-evl[0-9]*' v5.4-evl1 v5.4-evl2 v5.4.26-evl1 ...
the EVL core is gradually rebased on linux
evl/master branch, as the mainline kernel progresses
through -rc releases. This means that
evl/master may be rebased when
the first upstream candidate release (i.e. -rc1) is out at the
earliest, never during the merge window. From that point, the EVL
development goes on into
evl/master during the rest of the current
upstream development cycle, which is about 6-8 weeks. During this
period, some commits to
evl/master may be backported to the LTS
release branch. Because developing the EVL core may entail adding
features to or fixing the Dovetail interface in the process, some
evl/master may be cherry-picked into
once the mainline
reaches a final vX.Y.0 release,
evl/master is rebased on it. The
EVL core development keeps going on that rebased branch for a while,
until the next upstream kernel cycle issues the release candidate we
are interested in.
eventually, time has come to rebase the EVL core on a candidate release available for the next kernel development cycle, closing the previous cycle for EVL, which triggers the following actions:
the current HEAD of
evl/master is tagged in order to point
at the most recent EVL core commit for the closed kernel cycle,
which represents the tip of the EVL core based on the .0
upstream release (vX.Y-evl1 ).
evl/master is rebased on the selected candidate release,
which is usually -rc1. A later candidate could be picked
instead, although not later than -rc3 under normal
the current HEAD of
dovetail/master is tagged in order to
point at the most recent Dovetail commit for the closed kernel
cycle, which represents the tip of Dovetail based on the .0
upstream release (vX.Y-dovetail). There is no serial number on
these tags because a single kernel release is tracked for
Dovetail strictly speaking at any point in time.
dovetail/master is rebased on the same upstream
candidate release than
evl/master was rebased on at step 2.
Therefore, you may expect
always be based on the same upstream baseline.
At this point, the next EVL development cycle starts anew from step 1.
Over time, arbitrary commits from the current LTS branch may be tagged, marking an “official” EVL core release. These tags look like vX.Y[.Z]-evl<serial>, named after the mainline release they are based on. The serial number progresses as subsequent releases are issued based on the same mainline LTS branch; this number is therefore reset to 1 whenever the mainline LTS release changes.
Each time a new mainline LTS release is selected upstream, a new LTS release branch for the EVL core is created. The older LTS branch is closed, and the new one receives the next EVL updates.
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, “official” 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 may be tagged whenever any of the following happens:
the ABI has changed in evl/master in a way which is not backward-compatible with the latest libevl release. In other words, EVL_ABI_PREREQ in the latest release of libevl is no more 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.
evl/master reaches a .0 kernel release, if commits
are pending on top of the latest libevl release.
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.
If you need features from
libevl which have not been
released yet, then your best and only option is to build this library
master branch directly.
Last modified: Mon, 01 Jan 0001 00:00:00 UTC