GitLab

Prioritization of timers in timer queues dates back to the Dark Ages
of Xenomai 2.x, when multiple time bases would co-exist in the core,
some of which representing date values as a count of periodic ticks.
In such a case, multiple timers might elapse on the very same tick,
hence the need for prioritizing them.

With a single time base indexing timers on absolute date values, which
are expressed as a 64bit monotonic count of nanoseconds, the
likelihood of observing identical trigger dates is very low.

Furthermore, the formerly defined priorities where assigned as
follows:

1) high priority to the per-thread periodic and resource timers
2) medium priority to the user-defined timers
3) low priority to the in-band tick emulation timer

It turns out that forcibly prioritizing 1) over 2) is at least
debatable, if not questionable: resource timers have no high priority
at all, they merely tick on the (unlikely) timeout condition. On the
other hand, user-defined timers may well deal with high priority
events only some EVL driver code may know about.

Finally, handling 3) is a fast operation on top of Dovetail, which is
already deferred internally whenever the timer management core detects
that some oob activity is running/pending.

So we may remove the logic handling the timer priority, only relying
on the trigger date for dispatching. This should save precious cycles
in the hot path without any actual downside.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>