A choice was made for the EVL core to rely exclusively on /sysfs for exporting the core state information, excluding /procfs entirely. After all, we have only a handful of element types there, each instance is backed by a regular kernel device, so using /sysfs attributes to export information about them to user-space is just the obvious thing to do.
This said, some work remains to review the attributes already defined
by the EVL core, improve and possibly add more of them. This work is
most likely to be paired with the following task about writing
Missing attributes which come to mind:
thread/<pid>/wchan, which would dump the stack backtrace of the corresponding thread if it currently sleeps on an EVL wait channel (
Also, the sysfs element nodes EVL creates appear directly at the top
of the /sys/class hierarchy (e.g.
/sys/class/thread), which is
clumsy. sysfs does not formally support sub-classes, so I see no
obvious way for having all element classes rooted at
instead. Any idea would be welcome.
As a matter of fact, we have absolutely no handy tool for inspecting the current runtime status of the EVL core. A ps-like command is direly needed for instance, that would read the /sysfs attributes exported by the currently running threads to send out some useful information.
The code for an umbrella command named
evl is already there in
libevl/commands/evl.c, which like its
git counterpart, serves as a
centralized command router for executing ancillary scripts or
binaries. Such a script available from the same directory called
evl-trace illustrates the interface logic with the
The file descriptor polling feature is represented by a file
descriptor in userland too, so a polling object may be used to poll
other polling objects and so on. The core should make sure not to
accept too deeply nested monitoring requests. The case of cyclic
graphs is detected ok, but non-cyclic deep nesting is definitely not
as the algorithm there is pretty naive.
is where to look for this.
There are some unit tests exercising the EVL core in the library, but we need many more:
error injection is mostly absent from those tests.
there is no test verifying the sanity of the condition variable implementation.
the file descriptor polling feature is only lightly tested, so is the cross-buffer element.
This lock was inherited from the Xenomai code base (aka nklock there). This is a massive bottleneck on the road to efficient SMP scalability with more than 6 CPU cores running real-time load.
Some significant preparatory work has taken place in the EVL core for taking this lock out:
we don’t synchronize the timer events on it anymore, every CPU now has its own time base lock, which improves serialization.
the scheduler core has been simplified significantly, reducing the scope of the code which still requires to be covered by the ugly big lock.
However, we are not there yet. Some complex stuff remains to be sorted out for eliminating this lock entirely, specifically in the thread-to-scheduler interface points.
The EVL core defines a number of FTRACE-based tracepoints, which for the most part have been inherited from Xenomai’s Cobalt core, there is root for improvement in order to better fit the EVL context. In addition, the new code represents 2/3rd of the code base, which is not instrumented at all.
If we could exclude Dovetail’s spinlocks from CONFIG_LOCKDEP using a debug option, we could run the lock validator for detecting glitches with in-band locking exclusively, without causing massive latency spots.
We need an equivalent, passing the trace data back to userland via debugfs.
The latmus test should do a quick check about not receiving a stage migration signal as a result of calling clock_gettime(). We have to make sure that we go through the vDSO for reading timestamps, without incurring any in-band syscall. In the ARM case, switching in-band when calling clock_gettime() would denote a system clocksource which was not enabled for user MMIO access, which is bad.