Re: using monotonic clok for timstamping

[Gregor Boirie <gregor.boirie@parrot.com>]

On 02/09/2016 09:52 PM, 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'm not familiar enough with events to tell.

>> 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.
I like this way of keeping it simple. However, wouldn't this make the API
inhomogeneous ? After all, many channel related operations return
-EBUSY while flowing samples...