linux-kernel - Re: [IIO] Proposal for sysfs attributes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 06 Sep 2010 14:02:05 +0100
From:	Jonathan Cameron <kernel@...23.retrosnub.co.uk>
To:	Manuel Stahl <manuel.stahl@....fraunhofer.de>
CC:	LKML <linux-kernel@...r.kernel.org>,
	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
	Jean Delvare <khali@...ux-fr.org>, Greg KH <greg@...ah.com>,
	Mike Frysinger <vapier.adi@...il.com>
Subject: Re: [IIO] Proposal for sysfs attributes

On 09/06/10 09:41, Manuel Stahl wrote:
> Hi all,
> 
> there were some sysfs userspace questions on linux-iio where we would like to get some more comments on.
> 
> First thing, there are some attributes describing the layout of a
> ring buffer that can be read out via a char device. The buffer
> contains several entries with each containing so called scan
> elements. All entries have the same layout. It is described in a
> directory scan_elements (see below) that contains three attributes
> per scan element.
> 
>> 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.
>>
>> To be compatible with future extensions we could have:
>>    |- /sys/bus/iio/device0/buffer0/scan_elements/
>>       |- accel_x_en    (0 or 1)
>>       |- accel_x_type  (i.e. s14/16, see *)
>>       |- accel_x_index (position inside the buffer entry)
>>
>> * 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.
> 
> Is the 's14/16' self explaining or should we use some other format?
> Is 'type' a good postfix for the attribute?

One additional point here.  What we currently have that the enable
parameters are currently [m]_accel_x_en etc with m being an indicator
of the position of a parameter within the buffer.  Note not all channels
are enabled at a time.  For all devices we have so far, the ordering
is fixed, so this naming is constant.  Basically we roll the accel_x_index
attribute into the naming of the enable attribute.  Manuel, could you summarize
what you have against that approach? (I'm not particularly tied to it, but
it is in place and it does work).
> 
> 
> Next question: how strictly we want to resamble the hwmon ABI?
> 
> To sum up the discussion:
> Hwmon has files with the postfix _input to read values scaled to
> reasonable units for fixed point representation. So the units are
> sometimes scaled down to 'millis' e.g. millivolt, millidegree Celsius.
> We agreed that we want to keep this, whenever we use the _input postfix.
> For IIO there is also the postfix triple _raw, _scale and _offset,
> where the final value is calculated by (_raw + _offset) * _scale.
> Floating point values are allowed for any of these files.
(other than _raw obviously!)
> 
> The question in place was:
> Do we want to resemble the 'milli' units or should we stick to
> standard SI units (radians, kelvin, etc.) as floating point math is
> necessary anyway.
I've cc'd a few people who have contributed to previous abi discussions
for IIO in ways that make me think they may have opinions on this.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/