mfedyk at matchmail.com
Sun Feb 29 08:51:49 CET 2004
Jean Delvare wrote:
>>You have to be kidding me. Are you saying that with your patches to
>>libsensors it won't support 2.6.3 style sensor sysfs names?
> Yes I am. This isn't a fundamentally new problem. Each Linux 2.6 has
> had its matching libsensors version that was not backward compatible
> (with earlier 2.6 kernels; it's still fully compatible with 2.4).
> Keeping newer versions of libsensors compatible with all early 2.6
> kernel versions would make it incredibly more complex, with no
> significant benefit IMHO.
> The facts are that the sysfs interface to i2c chips is just stabilizing.
> Greg's original naming scheme had many drawbacks (also we can't blame
> him for that, since nobody objected before me), as I have been
> explaining in a previous post on LKML. Also, many chip drivers did not
> comply with it in early 2.6 kernels, and new chip drivers wouldn't fit
> in it anyway.
> The new interface is required if we want to write a chip-independant
> libsensors someday. I estimate that this is worth breaking the
> compatibility. The impacted kernels (later 2.5 and earlier 2.6) will
> obviously not be used anymore within a short time anyway.
> I invite you to read my original post here:
> I explain the problems of the current interface and my goals with the
> new one. If you can think of a better solution to the problem, please
> speak up.
Working from the premise that there is a current (old-style with mostly
chip dependent code), libsensors has 2.4 /proc support, and each
specific release supports one of 2.6....
I'm glad I'm not the maintainer of libsensors for a distribution. Since
you have effectively pushed the compatibility work to them. Just think
of angry customer complaints about this. :(
Since there is going to be an effective libsensors-new library with chip
independent code, I suggest you put the compat code into the old library.
More information about the lm-sensors