On 02/14/2016 06:43 PM, Lars-Peter Clausen wrote:
On 02/13/2016 03:14 PM, Jonathan Cameron wrote:
On 11/02/16 10:04, Gregor Boirie wrote:
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 3c66248..4602006 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -32,6 +32,13 @@ Description:
Description of the physical chip / device for device X.
Typically a part number.
+What: /sys/bus/iio/devices/iio:deviceX/clockid
+KernelVersion: 4.5
+Contact: linux-iio@xxxxxxxxxxxxxxx
+Description:
+ Identifier (clockid_t) of current posix clock used to timestamp
+ buffered samples and events for device X.
As it's been written into a sysfs attribute I'd normally prefer to see a
descriptive string for something like this. What do others think?
clockid_t is clearly fixed abi so this makes reasonable sense. Are there
other sysfs attributes to select the clock already present elsewhere in the
kernel?
Very same thoughts here. clockid_t is already ABI so we don't have to be
afraid exposing values that might change, but at the same time a string
would be more suitable for sysfs.
I was driven by simple userspace implementation at the cost of sysfs
conventions.
Moreover, no kernel side parsing is needed in this way.
Using a stringifi'ed clockid_t allows trivial clock selection with
following libiio based
code snippet:
</code>
int err;
...
err = iio_device_attr_write(indio_dev, "clockid",
STRINGIFY(CLOCK_MONOTONIC));
if (err < 0)
goto error;
<code/>
And even simpler retrieval and use of current clock:
</code>
int err;
long long clockid;
struct timespec tspec;
...
err = iio_device_attr_read_longlong(indio_dev, "clockid", &clockid);
if (err < 0)
goto error;
...
clock_gettime((clockid_t) clockid, &tspec);
...
<code/>
Implementing this with a descriptive string is no big deal anyway. I can
modify this
part if you feel sysfs conventions respect prevails.
gregor.
--
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
