Random libsensors redesign toughts
greg at kroah.com
Thu Jun 12 20:21:38 CEST 2003
On Wed, Jun 11, 2003 at 06:29:10PM -0700, Philip Pokorny wrote:
> Greg KH wrote:
> >On Sat, Jun 07, 2003 at 02:21:54PM -0700, Philip Pokorny wrote:
> >>As a follow up to my previous e-mail I thouht I would document some other
> >>thoughts I had recently about the interface between the new sysfs based
> >>drivers and libsensors and user-space applications.
> >>Not that any of these are particularly good ideas, I just wanted to get
> >>them out there...
> >>1. If the library is to be able to deal with any value in a consistent
> >>way, it needs to know if that value is in milli-degC, mVolts or whole
> >>counts. While saying that all temperatures would now *have* to be
> >>reported in milli-degC makes all temperatures consistent, there is still
> >>the problem that all values are not scaled identically (fan's are in
> >>whole RPM's). If each reading came with a scaling factor (1 to 1000 or
> >>more) it would be possible to have a generic routine for converting a
> >>driver integer to a user-space floating point value.
> >>I see two possibilities...
> >>Include the scaling in the same file with the reading:
> >Ick, no.
> >What's wrong with just using the same units always?
> Because not every reading has the same scaling. RPM's are unit scaled,
> voltages are milli-volt scaled, temperatures will now be milli-degC
> scaled. But the VRM spec is 10 scaled (8.1, 9.1, 10.0 etc) and auto fan
> control will require time values for some parameters. milli-seconds for
> all time parameters is not appropriate. Other values may require
> different scaling as well.
Why is milli-seconds not appropriate for all time parameters? Having
constant units makes things a _lot_ easier for the user.
> And for the library, it would be nice if the interface to sysfs didn't
> have to worry about what "type" a reading was and make some arbitrary,
> compiled in, decision about what the scaling for that value should be.
> It is *much* more flexible and appropriate for the driver to inform the
> library what the scaling for a given value is.
Yes, it's more flexible. But we aren't going to allow multiple values
per sysfs files, and I don't think you really want to add yet more sysfs
files per sensor value :)
More information about the lm-sensors