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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 6 Sep 2010 14:32:56 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Jonathan Cameron <kernel@...23.retrosnub.co.uk>
Cc:	Manuel Stahl <manuel.stahl@....fraunhofer.de>,
	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

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

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.

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)

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.

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.

Alan
--
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/