Jean Delvare wrote: > Hi Ivo, > > On Thu, 22 Mar 2007 11:09:14 +0100, Ivo Manca wrote: >> Just a quick question (again ;)). Is it necesary for us to even think about >> supporting the 2.4 kernels? >> I'm asking this, because if our addition doesn't get included before >> libsensors 3.x, it seems like we only get to work with 2.6, isn't it? > > Side note: we are already at libsensors 3.x (unfortunately.) What you > refer to is lm-sensors 3.x, for which the libsensors version will be > 4.x. Actually I think we should jump to lm-sensors 4.x directly to sync > the lib version with the package version again - but Mark seems to like > lm-sensors 3.x. > >> If that is so, we can drop a table in our database. This is because we want >> to add the kernel versions a configuration is working for. The easiest way >> to implement this, is to just modify the minimum kernel version for that >> configuration. If there's no support for 2.4, we can just add a field with >> the minimum working 2.6 kernel verson, like 2.6.10. Else, we must also >> register the minimum 2.4 version, either as a field, or with a >> table/relationship. >> >> Just wondering :) > > We don't really care about 2.4 anymore. If you can support it for free, > alright. If it has a cost, just don't do it. > > One thing which you will have to handle though are the syntax changes > to sensors.conf. Two things are going to happen in a (more or less) > near future: > > * Mark Hoffman will add support for the "include" statement. Obviously, > the user will need libsensors 4.x if they download a configuration file > which uses such a statement. OTOH, I can't see any reason why an > include statement would be used in the configuration files for > motherboards, so maybe all you have to do is strip any include > statement before storing the configuration file in the database. > > * Once the library discovers the device features autmatically, > sensors.conf will have to use the standard feature names, instead of > the custom ones. This means we'll have to fork sensors.conf.eg into an > old-style version and a new-style version. The configuration files > stored in your database will have the same problem - they will work > with either the old library, or the new one, but not both. > > Note that it should be possible to translate old-style configuration > files to the new style automatically, using the same translation > rules which are used by libsensors today. A perl script would do. The > other way around is much more difficult, though, as you would need to > write an extensive reverse mapping table for every supported chip. > Wouldn't it be wise to target only 3.x / 4.x with the dmi-detect code, and thus assume dynamic chip support and the new syntax? I haven't been doing much lm-sensors related work myself lately, but I can make some time free to get the dyn chip support into the 3.0 branch asap, if that helps the dmi detect code to become future proof. I think only support 3.x / 4.x is easiest / best otherwise the code becomes convoluted with compatibility muck from the day it was written. Regards, Hans
