GitLab

Timer name and handler name are redundant. Drop the latter, but assign
it as the timer's default name until xntimer_set_name() is called.

Applying a single gravity value for anticipating on all timer shots -
regardless of what the issuing timer is being used for - falls short
of considering the proper latency attached to the context. This leads
to poor tuning, with either negative latencies (i.e. early shots)
observed on measuring the jitter for irq handlers, or higher latencies
than expected for user-space threads when using too optimistic
(i.e. small) clock gravities.

Typically, the distance between the core clock handler and the
associated kernel-based handler the former calls, is much shorter than
what has to be traversed for switching in a kernel thread. It is even
shorter than the latency incurred for switching a user-space thread
from the core clock handler.

To solve this, we differentiate timers on the final context they
activate, between irq(handler), kernel and user threads, using the
appropriate gravity value when planning for the next shot, on a
per-timer basis, instead of using a single per-clock gravity as
previously.

Two additional contexts (irq and kernel) are added to the clock
gravity settings. The user can pass a hint to xntimer_init() for
indicating which kind of context will be activated by this timer (see
XNTIMER_[IKU]GRAVITY).

There are side-effects for this change on the procfs support:

- the information previously available from the xenomai/timer entry is
  now obtained by reading xenomai/clock/coreclk. In addition, the
  clock gravity values are reported.

- the former contents of xenomai/clock/* entries (i.e. the list of
  active timers running on the associated clock) is now available from
  the new xenomai/timer/* entries, also indexed on the clock name.

Writing to an entry under xenomai/clock/* can be used to change the
gravity values of the associated clock.

/* change the user gravity (default) */
echo 3000 > /proc/xenomai/clock/coreclck
/* change the IRQ gravity */
echo 1000i > /proc/xenomai/clock/coreclck
/* change the user and kernel gravities */
echo "2000u 1000k" > /proc/xenomai/clock/coreclck

See http://www.xenomai.org/pipermail/xenomai/2014-July/031236.html.

This service returns the per-task kernel pid of a local pthread.

Starting a periodic timer with an absolute date specification in the
past nevertheless plans for ticking at the next valid date on the time
line, with xntimer_start() still returning -ETIMEDOUT.

Time-relative or one-shot timers are not affected by this change.

To match the GNU extension equivalent, pthread_set_name_np() is
renamed to pthread_setname_np(). For consistency with the previous
change, pthread_set_mode_np() becomes pthread_setmode_np().

The former calls will be available from the upcoming transition kit.

Gilles Chanteperdrix authored Jun 24, 2014 and Philippe Gerum committed Jun 30, 2014

As has been discussed on the mailing list, making RTDM syscalls
conforming + adaptive makes more sense than current + adaptive. Since
the "probing" shorthand is only used for RTDM syscalls, make probing
be conforming + adaptive.

Send SIGDEBUG to the thread being denied a suspension/sleep state due
to XNTRAPLB, if the atypical/abnormal detection feature is armed.
The new SIGDEBUG_LOCK_BREAK alert code matches this case in the
siginfo data conveyed by SIGDEBUG.

At this chance, the related TCB state and information flag names have
been updated to better reflect the semantics:

XNTRAPSW -> XNWARN (SIGDEBUG warning enabled for atypical/abnormal
conditions)

XNSWREP -> XNPIALERT (Priority inversion alert sent [via SIGDEBUG])

The new rtdm_task_join() service may be called regardless of the
current execution mode, therefore rtdm_task_join_nrt() becomes
pointless and will be phased out in the next release.

We have no more in-tree users of these calls.

With the introduction of services to support real-time signals, those
two non-portable calls have become redundant. Instead, Cobalt-based
applications should set up a periodic timer using the
timer_create()+timer_settime() call pair, then wait for release points
via sigwaitinfo(). Overruns can be detected by looking at the
siginfo.si_overrun field.

Alternatively, applications may obtain a file descriptor referring to
a Cobalt timer via the timerfd() call, and read() from it to wait for
timeouts.

In addition, applications may include a timer in a synchronous
multiplexing operation involving other event sources, by passing a
file descriptor returned by the timerfd() service to a select() call.

Mainly,

- Fixup TOC hierarchy grouping Cobalt-specific interfaces
- Fixup core tags for more clarity
- Update RTDM documentation in the wake of rtdm_fd introduction

Mainly,

- Replace former "Environment" sections by context tags
- Fixup TOC hierarchy
- Remove license blocks from documentation group details

Some scheduling policies are implemented as variants of the core
SCHED_FIFO class, sharing its runqueue (e.g. SCHED_SPORADIC,
SCHED_QUOTA).

This means that we have to do some cascading to call the right pick
handler eventually.

Gilles Chanteperdrix authored Jun 01, 2014 and Philippe Gerum committed Jun 02, 2014

Because timer period is converted to clock ticks when starting a
periodic timer, round-off errors may accumulate at each timer tick
causing the timer to drift. Fix this by keeping the timer period as a
count of nanoseconds and convert to clock ticks at each period. This
adds some overhead, but is more correct.

include/asm-generic/xenomai/wrappers.h was pulling in all sorts of
unrelated header files, which have become useless as we dropped most
wrappers.

This caused a bunch of implementation files to rely on implicit
inclusion of some common kernel headers, which is wrong. Fix this.