Re: [IIO] Proposal for sysfs attributes

[Jonathan Cameron]

Hi Alan,

>>> 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.
> 
> FP isn't needed you can let the drivers do fixed point quite happily -
> the Intel compass driver intentionally does this.
True.
> 
> Using milli is asking for problems. There are lots of units where "milli"
> is actually quite big (millifarad, millihenry) and others where its
> stupendously small (eV for example). It works for hwmon because hwmon
> covers such a narrow range of devices and units.
Agreed, but as has been suggested before, we want to minimize the number
of interfaces in kernel.  I have no issue at all in using SI units for
things that haven't turned up before (and IIO does).  For the processed
inputs (like your compass driver or light sensors with nasty conversion
functions) we have _input parameters as per hwmon.  Given it was their
interface first we want to keep to their units where they apply.
The question Manuel was raising is do we extend this (for consistency)
to the _raw and _scale combination (as per your option 2).
> 
> So I'd favour FP because I think there are three choices
> 
> 1.	Encode the value, define the scaling factor in the ABI (not
> 	future proof)
> 
> 2.	Encode the value and scaling factor as two fields in the ABI
> 	(more future proof)
That's what we are currently doing.  Mainly for exactly the reason
you suggest below.  We want to use the same logic for the buffered
and direct (e.g. sysfs attribute) reads. Basically we need to export
the scale factor anyway so why not use it for both and keep the driver
as simple as possible.  Userspace can almost always just cache the scale
value anyway (it won't change in any current device unless userspace
tells it to do so).  I guess we might have an autoranging device to
deal with in the future.  Perhaps we just mandate that such a device
gives _input style outputs.  For buffer route on that it is going to
require an extension to the interface anyway.
> 
> 3.	As 2 but use the normal encoding for this which involves
> 	putting a "." in the right place and using one field (ie FP)
> 
> Drivers are simply going to end up doing this with sysfs values
> 
> 	snprintf(buf, sizeof(buf), "%d.%02d", v/100, v%100);
> 
> or similar - or in many cases
> 
> 	snprintf(buf, sizeof(buf), "%d0000000000", v);
> 
> neither of which is a big cost.
> 
> For a ring buffer you probably need to encode the scaling factor and
> field width in some sort of interface description query and the values in
> the bitstream.
Agreed.  Bitstream doesn't change format (without userspace telling it to
do so), hence sysfs attrs are perfect for doing this.
> 
> Which raises an interesting question. The natural way to deal with sysfs
> is decimal fixed point internally. If drivers are going to do both
> sysfs and rings then really you want to be able to encode powers of 10
> shifts not just bitshifts.
I'm afraid I have lost you here.  Why restrict to powers of 10?  The buffered
route is going to ship whatever the chip actually produces. We don't want to
touch them at all in kernel.  The scale factor could then be pretty much anything.
Typically for sysfs route we don't care how much we have to do to the data
so we could do your option 3, but given it is trivial for userspace to deal
with option 2 I'm more inclined to keep things consistent across the two interfaces
and go with that.

Thanks,

Jonathan


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