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: > http://marc.theaimsgroup.com/?l=linux-kernel&m=107715308608606 > > 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.[0123]... 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. Mike
