Re: [Xenomai-core] Question about getting system time

[Wolfgang Mauerer <wolfgang.mauerer@domain.hid>]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Just like it seems to be the case for Steve (unless I misunderstood his
>>>> reply), it is very useful for us being able to time-stamp events in RT
>>>> context that need to be correlated with events stamped in non-RT
>>>> (including non-Xenomai) parts or even on other systems: (offline) data
>>>> fusion, logging, tracing. I even bet that this is currently the major
>>>> use case for synchronized clocks, only a smaller part already has the
>>>> need to synchronize timed activities on a common clock source. But there
>>>> is huge potential in the second part once we can provide a stable
>>>> infrastructure.
>>> I already had such issues, and I did not solve them by modifying Xenomai
>>> core.
>>>
>>>> Even a "third clock" would have to be delivered for more archs than x86,
>>>> no question. We would basically need a generic but slow syscall variant
>>>> and per-arch syscall-less optimizations (where feasible).
>>> So, you would add a syscall which would becomre useless when you have
>>> implemented synchronized clocks properly? Yet another reason for
>>> avoiding this solution.
>>>
>> Could be "CLOCK_LINUX" - ie. no need for a new syscall.
> 
> I am Ok for this solution (and now that I think about it, I wonder if we
> did not already have this discussion). Anyway, I would go for
> CLOCK_HOST_REALTIME, in case someone wants to implement
> CLOCK_HOST_MONOTONIC. The advantage is that we can return EINVAL in the
> timer_create or clock_settime calls, to indicate clearly that using this
> clock for timing services is verboten. And when/if the full
> synchronization is implemented, the ID simply becomes a #define.

okay, so let's pursue this path. Patches will follow.

Best, Wolfgang