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
