Skip to content
GitLab
  1. 14 Jan, 2023 2 commits
  3. 05 Jan, 2023 1 commit
  5. 31 Dec, 2022 3 commits
    • Philippe Gerum's avatar
      libevl r42 · 9c0ec4b6
      Philippe Gerum authored 
      

Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
      9c0ec4b6
    • Philippe Gerum's avatar
      lib/flags, lib/sem: add broadcast, disjunctive/conjunctive wait · 4918e512
      Philippe Gerum authored 
      Applications were missing some features from semaphores and flags in
order to make it easier to use them as building blocks of other
synchronization mechanisms, which ABI 32 adds to address the issue. As
a result, the API evolves as follows:

- a semaphore may be broadcast using evl_flush_sem(), which is
  essentially a way to unblock all waiters atomically, returning with
  -EAGAIN to denote the condition.

- evl_broadcast_flags() sends a given bit mask to all waiters
  present. This feature makes it simpler to implement gang-based logic
  in applications, when all members from a group of threads need to be
  notified atomically using a particular bit pattern (which a
  mutex+event combo does not allow easily).

- evl_{timed_, try_}wait_some_flags() takes the set of bits to match
  in a disjunctive way (OR mode). Conversely, evl_{timed_,
  try_}wait_exact_flags() calls provide for conjunctive wait (AND
  mode). evl_{timed_, try_}wait_flags()...
      4918e512
    • Philippe Gerum's avatar
      libevl: remove shim API over POSIX · 978593b8
      Philippe Gerum authored 
      

The shim EVL layer over the vanilla POSIX interface (e.g. glibc) was
supposed to help during the early stage of application development by
emulating the EVL API in a desktop-based environment.

Such emulation has become pointless in this day and age, when bringing
up a virtual machine on any desktop is almost trivial, with the added
benefit of having the real EVL core in the picture. Besides, the shim
layer already had some limitations in terms of call emulation which
could only have increased over time, causing it to depart from the
original API behavior too much to stay relevant.

Let's drop this unloved and now useless shim layer.

Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
      978593b8
  7. 05 Dec, 2022 2 commits
  9. 28 Nov, 2022 2 commits
  11. 21 Nov, 2022 1 commit
  13. 20 Nov, 2022 1 commit
  15. 14 Nov, 2022 1 commit
    • Philippe Gerum's avatar
      tests: sched-tp-overrun: fix false positive · d8097758
      Philippe Gerum authored 
      

Only the first time frame is significant when checking for a schedule
overrun notification, the test code drifts too much for the subsequent
ones to be in sync. Prevent false (error) positive by running the test
loop only once, which is enough for basic validation of the mechanism.

Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
      d8097758
  17. 13 Nov, 2022 1 commit
  19. 12 Nov, 2022 2 commits
  21. 06 Nov, 2022 6 commits
  23. 05 Nov, 2022 1 commit
  25. 31 Oct, 2022 6 commits
  27. 29 Oct, 2022 2 commits
  29. 27 Aug, 2022 3 commits
  31. 26 Aug, 2022 1 commit
  33. 23 Aug, 2022 1 commit
  35. 30 Jul, 2022 1 commit
  37. 24 Jul, 2022 1 commit
    • Philippe Gerum's avatar
      lib/event: straighten behavior upon interrupted wait · c55ea95f
      Philippe Gerum authored 
      

There are multiple reasons for evl_[timed]wait_event() to be
interrupted while waiting, either forcibly via evl_unblock_thread() or
by a signal, either while waiting for the event or trying to acquire
the mutex back once done. Each of these causes should be handled
differently.

These changes build on the differentiated wait statuses introduced by
kernel ABI #28. However, they are compatible with kernel ABI #27,
although no improvement on dealing with the interrupt status would be
observed in this case, resorting to the old behavior which is to
report -EINTR to the caller in any case.

With these changes, -EINTR is reported only if the caller was forcibly
unblocked (e.g. by calling evl_unblock_thread()) while waiting for the
event. In all other cases, evl_[timed]wait_event() retries the
interrupted operation until complete.

Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
      c55ea95f
  39. 18 Jul, 2022 1 commit
  41. 16 Jul, 2022 1 commit
    • Philippe Gerum's avatar
      tests: monitor-event: check for WOLI management · 1b30808a
      Philippe Gerum authored 
      

Until [1] went to the EVL kernel tree, we would receive the LKSLEEP
notification when attempting to sleep on the tested event guarded by a
mutex, unless T_WOLI is forcibly disabled, which we used to do. This
whole logic was pretty silly, since we should not have been subject to
receive this error notification in the first place, which [1] fixes.

With this fix in place, we can take the opposite steps: force enable
WOLI+HMSIG, to make sure we never get this notification while
attempting to sleep on the event.

The side-effect is that older kernels which do not have that fix will
happily notify the new test code, leading to the related assertion to
fail. For good measure, give a clear hint about the reason why the
test may now fail with older kernels.

[1] evl/wait: prevent LKSLEEP HM notification upon sleep on a gated event

Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
      1b30808a

Imprint & Privacy Policy