Re: using monotonic clok for timstamping

[Jonathan Cameron <jic23@kernel.org>]

On 09/02/16 20:52, Lars-Peter Clausen wrote:
> 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?
I hope not..
> 
>>
>> 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.
A fair point if we document it clearly as 'HERE BE DRAGONS!'
Won't typically crash anything, just give crazy answers :)
>