Jean Delvare wrote: > 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. > Is this really worth it? The problems with the one register chip won't be stopped by this as one read transaction is all it takes to foobar things there. Also speed is hardly an argument, it is not like sensors-detect takes a long time to run. And as long as it stays within 5 minutes speed is irrelevant IMHO. > * 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.) > I agree, with udev etc, bus numbers simply won't be stable so we should not rely on them being stable. > * 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. > All in all this sounds very good to me, I esp. look forward to having some dmi based probing in sensors-detect, I'm afraid I have little time to spare lately but I would be happy to do testing. Regards, Hans
