Re: [IIO] Cleanup userspace

[Manuel Stahl <manuel.stahl@iis.fraunhofer.de>]

[-- Attachment #1.1: Type: text/plain, Size: 5638 bytes --]

Hi Jonathan,

Am 27.08.2010 16:24, schrieb Jonathan Cameron:

>>> As things currently stand these are in iio:device[n]/scan_elements. I guess we could move
>>> them into iio:device[n]/buffer0  It is a bit of a pain in code as the buffer directory is
>>> completely managed by the buffer implementation rather than the driver. Still I guess this
>>> could be passed to the buffer initialization code.  Things are a bit tricky as there are
>>> other attributes caused by the buffer it self. It cleans up the abi at the cost of further
>>> messing up the separation between buffer implementation and device driver and some complexity
>>> in driver.  It would be easier to move the scan_elements directory into the buffer directory?
>>> Perhaps that is the better option?
>>> What do others think on this?
>>
>> I have no problem with moving the whole directory.
> Cool.  I'll have a look to see how clean we can make the move.  It is going to break
> a lot of drivers in the Analog devices tree so it might be worth delaying it for now
> (perhaps updating the abi and saying the old location is deprecated).

Indeed I did that for the last few hours. A patch is coming on Monday.


>>>> - Endianess of the buffers:
>>>>     * Device specific? Then we need a sysfs file to publish this info.
>>>>     * CPU native byte order?
>>> It is currently cpu native for all software ring buffers. Agreed this may
>>> change and hardware buffers may do either.  So you are quite right, we
>>> need an attribute for this.  So I guess we support 3 options, cpu native, big endian,
>>> little endian. So what shall we call it?
>>>
>>> byte_order - [big little native]  Mostly read only, though sooner or later I expect
>>> we will get some device that allows this to be controlled.
>>
>> Do we really need native? I think the driver can figure out what the native order is, and just give that one (even at compile time).
> Good point.
>> Another possibility is to let the driver always convert to native.
> Bad idea.  In a hw ring buffer case that adds a lot of overhead for straight logging applications where we just want
> to store what the data is rather than do anything with it live.
>   At least that's what most userspace software want's to have. I recently sent a patch for sca3000 to the linux-iio list.
> Strange, those never made it to my inbox.  I'm guessing my iio subscription must have borked.  I'll get them
> from the archive.
>
> On those patches, I'm happy to ack the first (not sure when that bug snuck in and I'm not in a possition
> to test the fix today).
>
> As per this discussion I'd rather avoid the data munging of the second. That's a job for userspace.
> Obviously we'll be needing the stuff you specify below for that though.

OK, will be my next task.

>>> Probably not using the current ring buffer. As you say a big issue is how
>>> to describe a packed storage particularly if not all of it is packed.
>>> (so say 2 x 11 bit readings in 3 bytes - for say a 4 channel device, this is a better
>>> bet than packing it tightly into 44 bits.)  So far we haven't had a hardware
>>> ring device giving us packed data, but I'm sure one will turn up and force
>>> this element sometime in the future.  I think we leave this until a user comes
>>> along then pin it down then. I agree it is definitely something we need to consider,
>>> just not now!  Still if you want to lay out some guidance for discussion feel
>>> free.
>>
>> OK, no packed buffers for now, but we should implement variable
>> sample sizes for standard types. Indeed we already have this for the
>> timestamp, which is always 64 bit.
>
> 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.

>> 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.

Regards,
-- 
Dipl.-Inf. Manuel Stahl
Fraunhofer-Institut für Integrierte Schaltungen IIS
- Leistungsoptimierte Systeme -
Nordostpark 93                Telefon  +49 (0)911/58061-6419
90411 Nürnberg                Fax      +49 (0)911/58061-6398
http://www.iis.fraunhofer.de  manuel.stahl@iis.fraunhofer.de

[-- Attachment #1.2: manuel_stahl.vcf --]
[-- Type: text/x-vcard, Size: 170 bytes --]

begin:vcard
fn:Manuel Stahl
n:Stahl;Manuel
email;internet:manuel.stahl@iis.fraunhofer.de
tel;work:+49 911 58061-6419
x-mozilla-html:FALSE
version:2.1
end:vcard


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 6148 bytes --]