All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@cam.ac.uk>
To: Manuel Stahl <manuel.stahl@iis.fraunhofer.de>
Cc: "Song, Barry" <Barry.Song@analog.com>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	"uclinux-dist-devel@blackfin.uclinux.org"
	<uclinux-dist-devel@blackfin.uclinux.org>
Subject: Re: [IIO] Cleanup userspace
Date: Fri, 27 Aug 2010 16:09:30 +0100	[thread overview]
Message-ID: <4C77D52A.6090606@cam.ac.uk> (raw)
In-Reply-To: <4C77CC28.6020604@iis.fraunhofer.de>

...
>>
>> Agreed. These ought to be in there and will be needed
>>
>>> To be compatible with future extensions we could have:
>>>    |- /sys/bus/iio/ii0/buffer0/scan_elements/
>>>       |- accel_x:en    (0 or 1)
>>>       |- accel_x:type  (i.e. s14/16, see *)
>>>       |- accel_x:index
>>>
>>
>>> * s14/16 means signed 14 bits, stored in 16 bits, right aligned. If
>>> it's left aligned we can just modify the scale attribute and give the
>>> 16 bit interpretation in <channel>:raw.
>> That is quite a neat way of doing it though I'm not sure 'type' is the
>> ideal name.  My immediate thought is that type would be 'acceleration'!
>> We definitely want this on list.  We'd also want to drop the precision
>> attribute as that will just confuse things.
> 
> I'm open for any other name.
Lets see if anyone else has a suggestion...
> 
>>> I don't like the index prefix any more, even I had proposed this
>>> once. This is because for devices with more than 10 channels
>>> (adis16400) we have to get a leading 0 in the name to maintain
>>> alphabetical sorting, which is nearly impossible with the current
>>> macros.
>> Does alphabetical sorting really matter? + Doesn't putting 01 etc
>> in the macro give the right name?  I thought it was stringified in the
>> first step (could be wrong, that macro stuff always gives me a headache).
>> We definitely need the prefix or equivalent so this is worth clearing up.
> 
> If it doesn't sort alphabetically, there no point in having a prefix.
> It was thought as a helper for the human user. Currently the number
> is a preprocessor definition and used both as prefix and as number.
> If there's a 0 in front, it will be interpreted as octal number.
Ah. The octal bit hadn't occurred to me.

The prefix isn't for the helper user at all.  It is to tell userspace
code reading from the ring buffer which element is which.  Without it there
is no way userspace can know the order.  Frankly I don't think a human browsing
that directory will care what the ordering in a buffer record is!

Jonathan

  reply	other threads:[~2010-08-27 15:05 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-27  8:57 [IIO] Cleanup userspace Manuel Stahl
     [not found] ` <4C77AC01.3090204@cam.ac.uk>
     [not found]   ` <4C77B68B.4060805@iis.fraunhofer.de>
2010-08-27 14:24     ` Jonathan Cameron
2010-08-27 14:31       ` Manuel Stahl
2010-08-27 15:09         ` Jonathan Cameron [this message]
2010-08-30 10:55           ` [PATCH 1/2] staging:iio rename ring attributes Manuel Stahl
2010-08-30 12:28             ` Jonathan Cameron
2010-08-30 10:55           ` [PATCH 2/2] staging:iio move scan_elements into ring buffer Manuel Stahl
2010-08-30 12:58             ` Jonathan Cameron
2010-08-30 13:37               ` Manuel Stahl
2010-08-30 14:09                 ` Jonathan Cameron
     [not found]                 ` <4C7BD886.3060109@cam.ac.uk>
2010-08-30 16:31                   ` Manuel Stahl
2010-08-30 16:48                     ` Jonathan Cameron
2010-08-30 14:03             ` [PATCH 1/3] staging:iio update documentation Manuel Stahl
2010-08-30 14:23               ` Jonathan Cameron
2010-08-30 14:24                 ` Manuel Stahl
2010-08-30 14:49                   ` Jonathan Cameron
2010-08-30 14:03             ` [PATCH 2/3] staging:iio sync drivers with current ABI Manuel Stahl
2010-08-30 14:44               ` Jonathan Cameron
2010-08-30 15:00                 ` Manuel Stahl
2010-08-30 15:42                   ` Jonathan Cameron
2010-08-30 15:48                     ` Manuel Stahl
2010-08-30 16:07                       ` Jonathan Cameron
2010-08-30 16:28                         ` Manuel Stahl
2010-08-30 16:43                           ` Jonathan Cameron
2010-08-30 14:03             ` [PATCH 3/3] staging:iio:hmc5843 change ABI to comply with documentation Manuel Stahl
2010-08-30 14:58               ` Jonathan Cameron
2010-08-31 12:16                 ` Datta, Shubhrajyoti
2010-09-04 17:26           ` [IIO] Cleanup userspace 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=4C77D52A.6090606@cam.ac.uk \
    --to=jic23@cam.ac.uk \
    --cc=Barry.Song@analog.com \
    --cc=linux-iio@vger.kernel.org \
    --cc=manuel.stahl@iis.fraunhofer.de \
    --cc=uclinux-dist-devel@blackfin.uclinux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.