Jean Delvare wrote: > Hi all, > > As announced last week, I released a first release candidate (rc1) of > lm-sensors 3.0.0. The API is supposedly OK now, so it's time for > application authors to try and port their applications to the new > library and send us feedback. > > Important changes compared to lm-sensors 2.10: > * lm-sensors 3 only supports kernels 2.6.5 and later. > * It is now a user-space-only package, it no longer contains kernel > drivers. > * The i2c tools have been moved to a separate package (surprisingly > named i2c-tools). > * libsensors version was bumped to 4.0.0, as it has a completely new > API we had to increase the .so version. This new library contains > no chip-specific knowledge, it assumes that hardware monitoring > drivers follow the standard sysfs interface. > * The "sensors" binary has temporarily been renamed to "sensors3", so > that you can keep the old version around for comparison purpose. It > will be renamed back to "sensors" just before lm-sensors 3.0.0 is > released. > * sensors.conf is not fully compatible between the old and the new > library. The lm-sensors 3 package includes a conversion script > from the old format to the new one. > > There's one remaining open task for lm-sensors 3.0.0: > http://www.lm-sensors.org/ticket/2174 > Mark, this is yours. If you don't think you'll have the time to > implement it quickly, please move it to milestone 3.0.1. > > lm_sensors-3.0.0-rc1.tar.gz is not signed yet. Phil, do you want to > keep signing the archives for the lm-sensors 3 series? If you want to > do it, please proceed. If you prefer that I take over, just say so and > I'll do it. > > Notes to application authors: > * The new library has no chip-specific knowledge. As a result, the > <sensors/chips.h> header file is gone. > * Pretty much all functions of the old API are gone or work > differently. If you need to test for the new library in some > configure script, sensors_get_features, sensors_get_all_subfeatures > and sensors_get_subfeature are good candidates. Alternatively, you > can test that the libsensors_version string starts with "3." or > explicitly ask for libsensors.so.4. > * Reloading the configuration file with sensors_init() is no longer > supported, you need to explicitly call sensors_cleanup() before you > can call sensors_init() again. > * There's no porting guide available. The new API is so different from > the old one that you're probably better looking at an application > using the new API to get an idea how it works. It's not very > difficult. The "sensors" and "sensord" applications that are part of > the lm-sensors package have been ported to the new API already, so > they are good examples. "sensors" in particular is very simple. > > I've ported xsensors already, the patch is available here: > http://jdelvare.pck.nerim.net/sensors/xsensors-libsensors4.patch > Excellent work Jean! I've given this a test run on all my systems / test rigs and it works great everywhere. I'll create patches for ksensors, gkrellm, and gome's sensors-applet as time permits. I'm afraid this will take a while as currently I'm very busy with stuff regarding the upcoming Fedora 8. Talking about Fedora as soon as the development branch gets unfrozen for the F-9 cycle I'll put this new lmsensors in Fedora's development branch (together with patches apps), so that it can get a good amount of testing there, this won't happen for a while though. Regards, Hans
