[lm-sensors] lm-sensors benefits

Hans de Goede j.w.r.degoede at hhs.nl
Fri May 29 09:36:25 CEST 2009

On 05/28/2009 04:00 PM, Rob Bloom wrote:
> Many thanks to Hans, Mark and Jonathan for answering my previous email
> on specific hwmon chips (turns out 3 of the 4 I questioned are not (yet)
> supported by lm-sensors). I’d like to back-up a bit and ensure I
> understand what lm-sensors will do for us in our project:
> Essentially, we want to be able to read our temp and power monitor chips
> every 10 seconds and evaluate the values read (pass them for review to
> our own customized health monitoring system). I’ve been tasked with
> explaining the benefits of using lm-sensors package vs. not using it.
> Hopefully my questions do not seem too naive but I’m asking them from
> the perspective of having to write drivers (or, at least, assisting) for
> unsupported chips:
> - As I understand it, the drivers for these chips are not part of
> lm-sensors; one must develop the code for the chip in the kernel, if not
> already supported by the kernel. This driver work, if needed, is done
> whether or not one chooses to use lm-sensors, correct?

Correct, in the end you will always need some code to talk to the IC's

> - The libsensors library makes things easier by offering an interface
> for apps to access chip readings, configure them and convert them to
> real-world values. It works in conjunction with the /etc/sensors.conf file.
> o Is libsensors part of lm-sensors or are they developed and retrieved
> independently?

libsensors is part of lm_sensors, one could even argue that libsensors *is*
what lm_sensors is all about, and that the sensors application included
is an example application of how to use libsensors.

> o Is lm-sensors considered one of the “apps” mentioned above that opt to
> use libsensors to make things easier?

The sensors application which is part of lm_sensors (as is libsensors)
is one of the apps yes. And libsensors is not only about making things
easier, but also about providing a single unified interface that many
different applications can use, while having all the configuration data
(which pin is connected to what, what are the scaling factors if any) in
a central place for all of them, this is what /etc/sensors.conf is for.

> o Can I choose to write my own app to interface with libsensors and the
> hwmon chips?

Yes you can easily write your own app.

 > One of my colleagues asked “why can’t we simply read the
> chip registers with simple i2c calls over the bus?”.

Sure you can do this, but the advantage of writing a proper driver and
then using libsensors is that your app becomes independent of the
IC's, so if you ever do another revision of the product, or a whole new
product you could reuse your application without needing to change it.
And chances are that if in the new product you choose already
supported IC'd, you don't need to write any driver code either.

> - I skimmed over the lm-sensors source code. I know that it was made
> generic. So, how does it know what chips it needs to monitor? I assume
> this is through the sensors.conf file. I’m looking for the:
 > o lm-sensors source code that discovers the chips that it has (does it
 > read the sensors.conf file? Where is the lm-sensors code that does this?)

libsensors will give you access to all hwmon IC's the kernel knows about,
all drivers which implement the hwmon interface register themselves as
being part of the hwmon class, you can find out which IC's you have
by looking under /sys/class/hwmon

Then it finds out what sort of inputs the IC has (and what sort of
settings (min / max limits for alarms, alarm, etc) by looking at the files
under /sys/class/hwmon/hwmon#/device, these files follow the hwmon
sysfs API which is documented in the kernel tree, you can find it
online here:

Only then it looks at sensors.conf, to see if there is anantry for the
IC it found and within that entry an entry for the input. If it finds such
an entry that can tell it 3 things.
1: This input should be ignored (in which case it will forget about the input)
2: The label for the input (a pretty name to show for this)
3: A conversion formula to go from the raw pin measurement to what is actually
    being measured.

> o lm-sensors source code that utilizes the kernel drivers that sit in
> /drivers/hwmon directory. Could you point me to this code?

That code lives under the lib directory. But all it basically does is
read the files under /sys/class/hwmon/hwmon#/device, and when
a scaling formula is given in sensors.conf apply that and then return
the value.



More information about the lm-sensors mailing list