This package consists of many parts. This document offers a small tour around the most important pieces. Not all aspects are discussed exhaustively, but it should be enough to give you the feeling you understand what you are seeing happen. When you want to communicate with a piece of hardware, you need a kernel driver (well, that is not quite true, but it is in most cases the only way to do it safely). In the past, this meant you had to patch the kernel and recompile it. These days, you can use kernel modules. We support both approaches. We have chooses for a very modular (no pun intended) setup. There are a few general-purpose base kernel modules, which you always need. In addition, there is one kernel module for each piece of hardware - whether this is an I2C bus adapter, an SMBus adapter or a sensors chip. The kernel modules communicate their information through both the /proc and sysctl interfaces. To keep things uncomplicated, the sensor chips always advert their measurements 'as is'. This means that the values they report are not immediately relevant to you - they must first be scaled and translated to correspond to the real world. It is also possible to communicate directly with chips on an I2C bus or SMBus. This is done through /dev files. This is useful if you quickly want to test how a certain chip behaves, without having to write a kernel driver. It is also dangerous; several applications could access the same chip at the same time. Note that all other parts of this package function in so-called user-space. This is important, because bugs in kernel-space might crash your computer or do other bad things. And kernel memory can not be swapped out! Applications could (and can) directly read the sensor values through the /proc or the sysctl interfaces. This is harder then it sounds; because no two chips are the same, the information they communicate may also be very unlike. This would mean that every application would have to know about every type of chip. But there is a better solution. libsensors is a (shared or static) library of access functions. It knows about every type of chip supported by the kernel modules (or it should, if it is up-to-date). It offers a simple-to-use interface for applications to access the sensor chip readings, to set new limits, and all other commonly needed things. From the application's point of view, there is no need to know very much about a specific sensors chip. Having some inside information can still be useful, but it is possible to write a generic fall-back function that takes care of newer, unknown chips, and to display all really important information. libsensors takes care of one other thing. The kernel modules report so-called 'as is' values. They have to be scaled or translated to be relevant in the real world. libsensors reads a configuration file (usually /etc/sensors.conf) which specifies how this translation should be done (with some other things). Again, the application does not have to know about it. And because the configuration file is reread each time a new application is started, you can change configuration values without having to recompile anything. This package does not contain a nice graphical monitor. Look at the file doc/useful_addresses for pointers to such programs. It does contain an example console program that reports all current sensors values. This program is called 'sensors'. You can use it as a reference implementation for more intricate programs. There are many, many kernel modules in this package, and there are lots of different sensor chips supported. Sometimes, it can be hard to determine what chips and adapters you have, and which modules correspond to them. Fortunately, there is a user-space application 'sensors-detect' that should tell you exactly what is available, and what you need to do. This perl script uses the /dev interface, and you may use it as an example how you can do this.