Re: using monotonic clok for timstamping

[Lars-Peter Clausen <lars@metafoo.de>]

On 02/09/2016 12:06 PM, Gregor Boirie wrote:
> To sump up, implementing timestamping clock selection support in IIO
> should be based on the following principles.
> 
> Selected timestamping clock is a per-device attribute which the userspace
> may access through a sysfs file.
> 
> It must be applicable to both buffered samples and events.

Just playing out ideas here to make sure we have everything covered, but
could be there be a setup where you'd want different timestamps for events
and buffers?

> 
> Userspace may choose amongst a subset of available POSIX clocks. A good
> starting point would be: CLOCK_REALTIME, CLOCK_MONOTONIC,
> CLOCK_MONOTONIC_RAW, CLOCK_REALTIME_COARSE,
> CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME and CLOCK_TAI.
> Please delete as appropriate if needed and see clock_gettime(2).
> 
> One remaining question is : how do we ensure sample and event timestamps
> consistency with respect to clock changes ? 2 suggestions:
> * reject the ability to select a new clock as long as an events chardev is
> opened
>   or a buffered samples channel is enabled ;
> * clock may be changed at any time since it could be implemented in an atomic
>   way (a simple atomic_t can hold an int / clockid_t if I'm no wrong).

Not sure if we need to prevent it. If somebody changes it during an active
measurement it is their problem I'd say.