GitLab

There is no vDSO support with Valgrind. Detect when running on top of
such virtual machine using the Valgrind API, picking the fallback
clock_gettime() implementation if so.

This is not a problem since the EVL core does intercept and honor this
syscall directly from the out-of-band stage as needed. The incurred
overhead is negligible compared to what Valgrind already adds anyway.

Also, provide a placeholder for valgrind/valgrind.h which should be
picked when Valgrind is not installed on the build system.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

The syscall form used for issuing requests to the companion core is
based on ORing __OOB_SYSCALL_BIT to the syscall register for tagging
an out-of-band syscall, which is outside of the valid in-band range
for syscall numbers.

Unfortunately, this method has a major drawback: tools like Valgrind
which track system calls issued by applications may choke on
out-of-band system calls since these do not belong to the common set
it recognizes. Although adding syscall wrappers to Valgrind might be a
solution, this would not be the most practical one for dual kernel
syscall interfaces. The most practical approach would be to piggyback
on an existing system call which Valgrind (and others) already
recognizes. For this reason, Dovetail introduced a new syscall form
based on the regular prctl(2) syscall.

In order to benefit from this feature, EVL syscalls are now folded
into a prctl() request, which the core receives.

This change introduces ABI #27. Recent revisions of the EVL core
support both the former ABI and the new (prctl-based) one
indifferently.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

A receiver could get a spurious empty tube status, due to
receive_tube() racing with send_tube(). See the added comments into
the code for details about the resolution.

At this chance, guard against load/store tearing on shared pointers.

Pending issue: we still have a potential connectivity issue between
the prep and finish ops when pushing to a tube.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Refrain from inlining core services, so that interposing on them via
dynamic linking tricks is made easier.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

evl_get_current() contains implementation details which are definitely
not part of the API and the way this works should not be exposed.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Refrain from inlining core services, so that interposing on them via
dynamic linking tricks is made easier.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

What evl_read_clock() does is non-trivial, enough to call for an out
of line implementation.

In general, refrain from inlining core services, so that interposing
on them via dynamic linking tricks is made easier.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

We have no more in-tree users of these. Besides, let's assume that the
CPU's branch predictor always has better clues than we might have when
assessing the likeliness of a condition.

Bonus: this clears a recurring source of namespace clashes with C++
frameworks like Boost.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

In user-space at least, we'd be better off trusting the CPU's branch
predictor, instead of relying on our limited perception when it comes
to determining the likeliness of a condition, or every compiler to do
the right thing with respect to efficient branching.

We only have a couple of likely predictions in-tree on straightforward
conditions from the tube implementation code, which we can remove
safely.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

This mode measures the delay between the moment a synthetic interrupt
is posted from the oob stage and when it is eventually received by its
in-band handler. When measured under significant pressure, this gives
the typical interrupt latency experienced by the in-band kernel due to
local interrupt disabling.

Therefore, this is an in-band only test which measures IRQ latency
experienced by the common kernel infrastructure, _NOT_ by EVL.

Measurement is requested with '-s' option.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Do build them unconditionally though.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Since ABI 23, the core is able to channel T_WOSS, T_WOLI and T_WOSX
error notifications through the offender's observable component if
present.

Convert all SIGDEBUG_xxx cause codes to the new EVL_HMDIAG_xxx naming,
so that we have a single nomenclature for these errors regardless of
whether threads are notified via SIGDEBUG or their observable
component.

The API rev. is bumped to #17 as a result of these changes.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Since ABI 23, the core provides the new observable element, which
enables the observer design pattern. Any EVL thread is in and of
itself an observable which can be monitored for events too.

As a by-product, the poll interface can now be given a user-defined
opaque data when subscribing file descriptors to poll elements, which
the core passes back on return to evl_poll().
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Open-coding oob_ioctl() calls to set/clear mode bits in apps is
unhandy and fairly ugly. Let's provide sanctioned services for these
requests, namely evl_set_thread_mode() and evl_clear_thread_mode()
respectively.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Starting with ABI 22, we can ask for the core to unblock a thread from
a wait state, which may include forcing it out of any real-time
scheduling class by demoting it to SCHED_WEAK in the same move.

Export evl_unblock_thread() and evl_demote_thread() as the
corresponding wrappers.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

An equivalent of sched_yield().
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Since core ABI 21, users can decide whether a new element should be
made public or private depending on the value of clone flags added to
the new long form of all element creation calls, i.e. evl_create_*().
All evl_new_*() calls become a shorthand for their respective long
form with reasonable default arguments, including private visibility.

As a shorthand, libevl also interprets a slash character leading the
name argument passed to these services as an implicit request for
creating a public element. In other words, this is the same as passing
EVL_CLONE_PUBLIC in the clone flags.

A public element appears as a cdev in the /dev/evl hierarchy, which
means that it is visible to other processes, which may share it. On
the contrary, a private element is only known from the process
creating it, although it does appear in the /sysfs hierarchy
regardless.

e.g.:

efd = evl_attach_self("/visible-thread");

total 0
crw-rw----    1 root     root      248,   1 Apr 17 11:59 clone
crw-rw----    1 root     root      246,   0 Apr 17 11:59 visible-thread

or,

efd = evl_attach_self("private-thread");

total 0
crw-rw----    1 root     root      248,   1 Apr 17 11:59 clone
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Given that evl_sched_control() was hardly usable prior to the latest
fixes to the scheduler control code in the core and no feedback ever
happened about such issues, we may assume that such call has no user
yet. Take this opportunity to fix a naming inconsistency in the API.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

sched_priority is implemented as a macro by glibc which serves as a
wrapper to the real attribute field in schedparam. Some architectures
may use this trick to hide the actual identifier from the user code,
so make sure to always pull <sched.h> before referencing
sched_priority in uapi/ headers, so that such wrapping also happens
when struct evl_sched_attrs is defined.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

These changes fix up the argument passed to the core system calls in
order to abide by the new ABI allowing 32bit applications to issue
requests to 64bit kernels.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

uapi/evl should not directly depend on uapi/linux from the same kernel
release. The kernel definitions we need in uapi/evl should be limited
to linux/types.h, as available from a current toolchain. Revert the
uapi/linux export introduced by commit #5f68658b8.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

This set of changes makes libevl y2038-safe by switching to the ABI
revision 19 of the EVL core, which generalizes the use of a 64bit
timespec type. These changes also go a long way preparing for the
upcoming mixed 32/64 ABI support (aka compat mode).

The changes only affect the internal interface between libevl and the
kernel, not the API.  Nevertheless, the API was bumped to revision 10
with the removal of the evl_adjust_clock() service, which neither had
proper specification nor defined use case currently, but would stand
in the way of the sanitization work for y2038. At any rate, any future
service implementing some sort of EVL clock adjustment should
definitely not depend on the legacy struct timex which is
y2038-unsafe.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Instead of matching whatever ABI we might be compiled against like
previously, define the kernel ABI we need as a prerequisite
(EVL_KABI_PREREQ), checking for sanity at build time and runtime.

This prerequisite is matched against the range of ABI revisions the
kernel supports (from EVL_ABI_BASE to EVL_ABI_CURRENT). In the
simplest case, the kernel implements a single ABI with no backward
compatibility mechanism (EVL_ABI_BASE == EVL_ABI_CURRENT).

This addresses two issues:

- the fact that libevl might build against a given set of uapi/ files
  does not actually mean that the corresponding kernel ABI found there
  is fully compatible with what libevl expects. Specifying a
  compatible ABI prereq explicitly addresses this problem.

- we can obtain services from EVL cores supporting multiple ABI
  revisions (i.e. providing backward compat feat).
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

evl_udelay() was an annoying misnomer for people with kernel
development background, as this relates to a busy wait loop, not to a
sleeping call, which evl_udelay() actually was.

Rename this call to evl_usleep(), converging to the glibc signature
for usleep(3) in the same move.

No need to mention TUBE in canister macro declarators, there is no
other type of canisters in the API but those flowing through tubes
anyway.