[lm-sensors] Future plans for sensors-detect
khali at linux-fr.org
Wed May 21 11:40:13 CEST 2008
As discussed before the 3.0.2 release, I have plans to change
sensors-detect significantly. As I do not want these changes to affect
the users of 2.10.x legacy tree, this means that we are no longer
trying to keep sensors-detect in sync between both branches. This
doesn't mean that it's forbidden to add detection for new devices in
the 2.10.x one if you want - but keeping both copies as identical as
possible is no longer the goal.
Here is a random and incomplete list of things I have in mind. It will
take some time before I can implement everything, and maybe some points
will not be implemented in the end if they don't seem to be needed or I
don't have the time to implement them.
* Drop Linux 2.4 support. lm-sensors 3.0.x only supports Linux 2.6, so
if we no longer keep sensors-detect versions in sync, there's no point
in supporting 2.4 kernels in the lm-sensors 3.0.x one. This will make
the script somewhat smaller and simpler.
* Revert the order of the probes. This it ticket #2322:
The idea is to start with the less risky probes, and stop by default
when we think we have found what we were looking for. The user will
still be able to continue with the detection if he/she wants.
* SMBus read cache. I submitted something already over one year ago:
But nobody reacted so I never committed my work. The speedup
generated by this patch alone seemed worth the extra code. Another
reason now is that limiting the hardware access to these devices
seems to be a good idea in the light of recent reports we had about
I2C/SMBus chips reacting to probes in odd ways. The most important
protection measures have been implemented in 3.0.2 already, but I
believe that caching the register reads in sensors-detect would
further prevent the possibility to break something accidentally.
* Get the bus driver names from the kernel. The Linux 2.6 kernel tells
you which kernel module provides support for a given driver, so we can
stop guessing it with tricky regexp matching against the i2c bus
* Fix the bus numbering prediction magic. There's some old code to
attempt to figure out how I2C bus will be numbered after next reboot,
so that the "ignore" module options are correct. This code is broken
in more than one way. It assumes that it knows about all drivers which
create i2c buses, which is not true (all graphics and multimedia
adapters in particular are missing.) It assumes that the user will
reboot after running sensors-detect. It assumes that i2c bus drivers
don't autoload, while they almost all do by now. And it assumes that
the bus numbering is stable over reboot, which is not necessarily the
case (I can't think of a fix for this one though.)
* DMI integration. This is needed for automatic configuration file
download, and could also be welcome to explicitly skip some probes
on selected motherboards. Recent kernels export the DMI data so we
should not even need to depend on dmidecode. Either way I don't want
to add a hard dependency for DMI, so if it's there we use it, if not
we'll just do as before.
* Unload i2c-dev at the end of the probe if we loaded it ourselves?
That's all I can think about at the moment but there is certainly more.
I would welcome comments on any of the points above.
More information about the lm-sensors