linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Gregor Boirie <gregor.boirie@parrot.com>,
	Lars-Peter Clausen <lars@metafoo.de>,
	linux-iio@vger.kernel.org
Subject: Re: [RFC PATCH v1 1/3] iio:core: timestamping clock selection support
Date: Wed, 17 Feb 2016 19:38:21 +0000	[thread overview]
Message-ID: <56C4CC2D.6010608@kernel.org> (raw)
In-Reply-To: <56C19D6A.4020905@parrot.com>

On 15/02/16 09:42, Gregor Boirie wrote:
> 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@vger.kernel.org
>>>> +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.

Sorry to be a pain, but I think that it is worth the somewhat silly jumping through
hoops to sysfsify it.  Keeping sysfs as 'self documenting' as possible is always a good
aim.

Thanks,

Jonathan
> 
> gregor.
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


  reply	other threads:[~2016-02-17 19:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-11 10:04 [RFC PATCH v1 0/3] iio: introduce timestamping clock selection Gregor Boirie
2016-02-11 10:04 ` [RFC PATCH v1 1/3] iio:core: timestamping clock selection support Gregor Boirie
2016-02-13 14:14   ` Jonathan Cameron
2016-02-14 17:43     ` Lars-Peter Clausen
2016-02-15  9:42       ` Gregor Boirie
2016-02-17 19:38         ` Jonathan Cameron [this message]
2016-02-18  9:25           ` Gregor Boirie
2016-02-11 10:04 ` [RFC PATCH v1 2/3] iio:core: timestamping clock resolution support Gregor Boirie
2016-02-11 10:04 ` [RFC PATCH v1 3/3] iio: make drivers use new timestamping clock API Gregor Boirie
2016-02-13 14:19   ` Jonathan Cameron
2016-02-15  9:11     ` Gregor Boirie
2016-02-13 14:12 ` [RFC PATCH v1 0/3] iio: introduce timestamping clock selection Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56C4CC2D.6010608@kernel.org \
    --to=jic23@kernel.org \
    --cc=gregor.boirie@parrot.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).