Random libsensors redesign toughts

Random libsensors redesign toughts

[Philip Pokorny]

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:

     # cat in0
     3433 1000
     # cat fan0
     2323 1

Or have the scaling in a different file associated with the reading:

     # grep '.' in0*
     in0: 3433
     in0_scale: 1000
     in0_min: 3300
     in0_max: 3500
     in0_alarm: ALARM

2. I think we should strive to make it easier to add drivers and change the 
output text of a driver.  The "relation" and mapping information in the table 
that is currently compiled into libsensors could be moved to a config file.

3. sensors and sensord should be one program.  I view sensord as an example of 
how libsensors has not lived up to it's mission to provide an interface to 
lm_sensors for user programs.  You have to duplicate too much code from 
sensors into sensord when adding a new driver.  A framework for formatting and 
printing temperaturs and voltages is needed.  With this, then either sensord 
becomes a simple program to log readings without needing to know the specifics 
of chips, or else the RRD code is integrated into sensors.

4. An API that allows a user space program to request a list of all 
temperatures (regardless of which chip is measuring them) or voltages, or fans 
would be nice.  Many of the motherboards I'm working with have multiple 
monitoring chips and if I were writing a GUI interface, I'd like to be able to 
get all the values of a similar type organized together.  This would be the 
same interface that sensord needs.

5. We'll probably need to define some data types.  Some ideas:

    temp_min_max
    temp_over_hyst
    voltage_min_max
    fan_min
    pwm
    voltage

These can then be associated with user-specifiable output format strings. 
Then if a user want's the output of sensors in French or German, they can just 
change the sensors.conf file.

Just some random thoughts...

:v)

Random libsensors redesign toughts

[Greg KH]

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?

thanks,

greg k-h

Random libsensors redesign toughts

[Philip Pokorny]

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.

You can't use the same scaling for every reading.

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.

:v)


-- 
Philip Pokorny, Director of Engineering
Tel: 415-358-2635   Fax: 415-358-2646   Toll Free: 888-PENGUIN
PENGUIN COMPUTING, INC.
www.penguincomputing.com

Random libsensors redesign toughts

[Greg KH]

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 :)

thanks,

greg k-h