[just to save this early-Saturday-morning insight]

I think the xntimer interface is not yet ready to represent all required
scenarios. What kind of timers are there? Let's start with POSIX:

1. Realtime timers      - use realtime clock as base, re-tune
                          absolute(!) expiry dates if the realtime clock
2. Monotonic timers     - use monotonic clock as base, don't re-adjust
                          during runtime

Now what we have in current trunk:

3a. Realtime xntimers   - use wallclock_offset to calculate absolute
                          expiry dates, don't re-adjust during runtime
4a. Monotonic xntimers  - use raw jiffies/TSC as base, don't re-adjust
                          during runtime

And this is what we planed to introduce soon:

3b. Realtime xntimers   - use wallclock offset to calculate absolute
                          expiry dates, re-adjust if the offset changes
                          during runtime
4b. Monotonic xntimers  - same as 4a

3b and 4b almost perfectly match POSIX, one only has to pass relative
realtime timers as monotonic ones (Linux does so too). But there are a
lot of skins that potentially rely on 3a! At least the whole native
skin, I would say. So we may actually need two knobs when starting an

 A) Take wallclock offset into account when calculating internal expiry
 B) Re-tune the expiry date during runtime if the offset changes?

Reasonable combinations are none of both ("POSIX monotonic"), A
("Xenomai realtime"), and A+B ("POSIX realtime"). Am I right? Please

Moreover, it looks to me like the monotonic API I introduced is not very
handy (fortunately, there is no in-tree user yet). It has a sticky
property, i.e. you set a persistent flag in the xntimer object if it
ought to be monotonic. As xntimer structures are typically also
persistent, you easily end up saving the current mode, setting your own,
and restoring the old one once the timer fired -- to keep other users of
the timer happy. E.g., think of RTDM doing some monotonic timing with a
task while the owning skin may prefer realtime mode. I'm almost
convinced now that passing a non-sticky mode on each xntimer_start
(along with XN_ABSOLUTE/RELATIVE in the same parameter) will be more useful.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to