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. -- Jean Delvare
