All of lore.kernel.org
 help / color / mirror / Atom feed
* Random libsensors redesign toughts
@ 2005-05-19  6:23 Philip Pokorny
  2005-05-19  6:23 ` Greg KH
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Philip Pokorny @ 2005-05-19  6:23 UTC (permalink / raw)
  To: lm-sensors

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)

^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-05-19  6:23 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-05-19  6:23 Random libsensors redesign toughts Philip Pokorny
2005-05-19  6:23 ` Greg KH
2005-05-19  6:23 ` Philip Pokorny
2005-05-19  6:23 ` Greg KH

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.