[lm-sensors] Future plans for sensors-detect

[Jean Delvare]

Hi all,

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:
  http://www.lm-sensors.org/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:
  http://lists.lm-sensors.org/pipermail/lm-sensors/2007-January/018749.html
  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
  names.

* 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.

Thanks,
-- 
Jean Delvare