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 :) > -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
