All of lore.kernel.org
 help / color / mirror / Atom feed
From: ppokorny@penguincomputing.com (Philip Pokorny)
To: lm-sensors@vger.kernel.org
Subject: Random libsensors redesign toughts
Date: Thu, 19 May 2005 06:23:58 +0000	[thread overview]
Message-ID: <3EE25772.9010305@penguincomputing.com> (raw)

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)

             reply	other threads:[~2005-05-19  6:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-19  6:23 Philip Pokorny [this message]
2005-05-19  6:23 ` Random libsensors redesign toughts Greg KH
2005-05-19  6:23 ` Greg KH
2005-05-19  6:23 ` Philip Pokorny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3EE25772.9010305@penguincomputing.com \
    --to=ppokorny@penguincomputing.com \
    --cc=lm-sensors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.