Jan Kiszka <[email protected]> writes:
> On 22.06.21 09:49, Julien Blanc via Xenomai wrote:
>> Le mardi 22 juin 2021 à 09:38 +0200, Philippe Gerum via Xenomai a
>> écrit :
>>>
>>> With this in mind, assuming that we have previously sanitized the
>>> clock
>>> identifier, doing this:
>>>
>>> #define get_timestamp(__clock) \
>>> ({ (__clock) == CLOCK_MONOTONIC ? rtdm_clock_read_monotonic() :
>>> rtdm_clock_read(); })
>>>
>>> may end up being faster than:
>>>
>>> xnticks_t (*__get_timestamp)(clockid_t clock);
>>> #define get_timestamp(__clock) __get_timestamp(__clock)
>>
>> Is really a runtime switch necessary ? Since relying on the realtime
>> clock is inherently broken, my understanding is that it should be kept
>> as compatibility purpose only.
>
> Again: The real-time clock is not a broken clock per se. It is the basis
> of many services (POSIX...) and - if managed properly - it is as sound
> clock to build upon. If you need absolute timestamps to calculate
> absolute timeouts (like users of the existing code do), this is the
> clock to go, also in future versions.
Definitely correct, for timeout specs.
> Also if you want to use
> PTP-sync'ed clocks across systems (TSN...), it is THE way to go. At that
> point, monotonic timestamps will lose relevance in practice.
>
We are not there yet. So, let's all agree than we need both clock bases,
and a flexible way to select the current one.
--
Philippe.
