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>
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>
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>
Normal (i.e. non-recursive) mutexes timed on the monotonic clock are
the most common form of locks used by applications. Allow people to
write more compact code by providing creation calls and static
initializers aimed at building these directly:
- evl_new_mutex(), EVL_MUTEX_INITIALIZER() for PI locks timed on the
monotonic clock.
- evl_new_mutex_any() and EVL_MUTEX_ANY_INITIALIZER() for building any
supported type of lock (normal/recursive), specifying the protocol
(PI/PP) and the base clock.
Some creation calls have to return the file descriptor of the new
element because there is no in-memory descriptor associated with the
latter where we could stick the former. So for consistency, just have
all evl_new_*() calls return the file descriptor referring to the new
element.
Likewise, all evl_open_*() calls now do the same.
Philippe Gerum