[Xenomai-core] Towards periodic mode over aperiodic timers

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]

Hi,

the conflict between skins preferring aperiodic timing vs. skin
requiring periodic mode popped up once again on xenomai-help. One way
out of this, likely THE way, is to map such tick-driven skins on a
periodic timer over aperiodic mode (and drop periodic low-level support
completely at the same time).

Let's start some discussion how this can be done, specifically as Gilles
and I are already turning the xntimer subsystem upside down (almost). If
we want co-existence of high-res timing of, say, the posix skin while
the vxworks skin runs over a tick-timer, we need some kind of "context"
for timing related functions.

Simple example: xnpod_suspend_thread() expects a timeout as "xnticks",
i.e. either in nanoseconds or in ticks of the underlying periodic timer.
This depends on the global timer mode of the pod, and that's a no-go for
concurrent modes as sketched above. Rather, the thread should encode
which kind of timing mode to use, even better the threads timers.

We currently dispatch xntimer_start globally to the different timer
subsystems (if periodic mode is enabled). What about deriving the start
function from the timer itself in the future? If a timer was created as
aperiodic, things happen as usual in aperiodic mode, and the timeout are
interpreted as nanoseconds. If the timer is periodic, we interpret the
timeout in ticks and map them on a second-level timing subsystem
(probably a wheel) that itself is driven by a single periodic timer in
the first-level system (just like the host tick).

Am I heading in the right direction? Is it feasible? Any other ideas?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]