> 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]... Correct, that's mostly that. > 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. :( Again, this is a temporary situation. I'm struggling for a better future, at the cost of a slightly chaotic present, admittedly. That said, I think that most packaging systems support that kind of dependency. Since we clearly advertise the correct combinations of lm_sensors and Linux kernel, they should be able to handle it quite nicely (although I admit it has to represent some work for them). The compatibility problems brought by libsensors are not new. From the very beginning, each new version of lm_sensors had kernel modules, libsensors and sensors program that mostly only worked well together. It wasn't to the point of what we are experiencing today, of course, because things were mostly (but not always) backward compatible. Still, supporting each and every new driver or "kind" of chip would require upgrading to new libsensors and sensors program. This is precisely what I want to avoid with my proposal. > 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. Note that there is no effective plan for such a library as of today. I am "simply" defining an interface such that writing such a library will be possible. I don't think I have the skills to write it at the moment, but I have no doubt that people will do (I'm in particular thinking to the gkrellm folks who neved liked the old library and wouldn't use it at all, at the cost of frequent compatibility issues). That said, if nobody seems to go on working on it within a reasonable amount of time, it's likely that I will learn what I need to know to do it myself, since I'm so interested in seeing it exist. I do not plan to spend time to provide compatibility with early 2.6 kernels. First, because it would bloat the current libsensors even more. Second, because I believe that these kernels will stop being used within a few months or even weeks. Distributions or individuals running 2.6 kernels these days know pretty well that things are not fully stabilized yet. Granted, the sensors area seems to be the more unstable realm of them all at the moment. But I just don't think that people need to have, say, a 2.6.1 and a 2.6.3 kernel running perfectly on their system. We never had any request in that direction so far. What they most likely want is to have a 2.4 and a 2.6 kernel working, and we do provide this compatibility. If you really believe that we have to support all early 2.6 kernel releases and are able to write a not-too-bloated patch for libsensors that does this, we'll consider applying it. But it's unlikely that any of us will want to spend time on such a patch. Thanks. -- Jean Delvare http://www.ensicaen.ismra.fr/~delvare/
