Generic Chip support

The core idea is that in kernel 2.4, the kernel drivers provided the sensor data, but not enough details about the chip "structure" (number and type of inputs and features). For this reason the structure info was put in libsensors. In kernel 2.6, the drivers provide both the structure and the data, so the structure is redundant between the drivers and libsensors. For now we try hard to keep both in sync, and that sucks.

The long term solution is to kill all structure information from libsensors, which will make it MUCH smaller and reduce the maintenance work to basically nothing. When we do that we say bye-bye to 2.4 support.

But for now we can start by adding this generic support in the library.

Step 0

add individual alarm and beep files to all 2.6 drivers Not shown on my sketch because I remembered it the day after. This is the last step to a truly standard sysfs interface to hwmon chips.

Status: Work in progress

Step 1

let libsensors scan /sysfs to discover the chip features from there we can generate a structure like the ones hard-coded in lib/chips.c. With this alone we should be able to use "sensors -u" on any 2.6 driver. Not user friendly though.

Status: Done

Step 2

Add sensor type information to the structure - For now the library is type-agnostic. This worked as long as we had dedicated printing routines for every chip in "sensors", but the goal of a chip-independent library is to have completely generic user-space tools as well. We could let each user-space tool guess the sensor type from the symbol name, but this would incur redundancy across tools. So better have libsensors generate this information, and add a function to the library interface for user-space tools to query for data type.

I'm waiting to see an implementation of this to actually decide if it's the right thing to do.

Status: Done

Step 3

Add generic printing routines to sensors - We want a function to print voltages, one for temperatures, one for fan speed, and a few others. If libsensors provides the type for every symbol, we can easily branch to the correct printing routine for every set of symbols. We have some functions like this already, the idea is to make them even more generic. For example temperature sensors can come with many different type of limits (low, high, critical, hysteresis) and depending on the ones available for a given chip we need to display everything in the right order with proper formatting. At this point we should be able to have something like "sensors -u" but with per-sensor-type formatting so much nicer.

Status: Done

Step 4

New sensors.conf.eg - We need to use the standard symbol names in sensors.conf.eg. So far we used the old symbol names (from 2.4) and libsensors was converting to the new ones for 2.6 drivers. These old symbol names make no sense if the driver interface is probed at runtime.

Status: Done

Step 5

Take care of the 2.4 part of things - What to do here is not completely clear yet... Mark suggested killing everything right away, but I think it's a bit early at this point. I'd rather tweak the library as needed to allow the new "sensors -u" (which should become the default) to work even with 2.4, so we can kill all chip specific code in "sensors" to start with. And kill lib/chips.[ch] only later.

Status: Done

Most of these steps are in fact independent and could be done in a different order or even by different persons, however each change by itself isn't really useful so we'll need to synchronize the efforts.