Rene Herman wrote:
This is an ABI breakage issue and an unfortunate one at that:
No it is not, in 2.6.26rcX, the acpi thermalzones have grown a hwmon interface,
that is they register a hwmon device so that "sensors" and other lm_sensors ABI
compliant using applications can read the zone temperatures using an existing
ABI instead of adding yet another ABI.
The problem is that the hwmon entries for the thermalzone device lack a
"device" symlink under /sys/class/hwmon/hwmonX, as they are not tied to a
specific device. lm_sensors-2.10.x barfs on this, which would not be a problem
if it would simply skip with the new hwmon which it does not understand
(because of the missing device link, which is not a part of the documented
ABI), but instead of skipping it, if I understand you correctly it aborts and
never gets to hwmon1 (which is 100% unchanged and should still work fine).
I wonder what just plain "sensors" (without the -s) does.
Still this is an issue that needs fixing, but not on the kernel side, but
rather on the lm_sensors-2.10.x side, I guess its time for a new 2.10.x release.
I'm pretty sure this caused by your lm_sensors using space being to old
to support the new thermalzone stuff. You need atleast 3.0.2 to support
the thermalzone driver.
I see. I was about to mark this up as Volkerding doing his usual "if it
has a lower version number it must be better" thing but in this case it
seems it's hwmon or ACPI which is to blame.
Actually its lm_sensors userspace which is to blame, as instead of skipping the
new hwmon device which it doesn't understand it aborts (atleast that is what I
understand from what you're telling us).
This is ABI breakage. I wouldn't care if my older lm_sensors userspace
couldn't handle the ACPI Thermal Zone, but I do care that even having it
breaks my other sensors;
Yes, and that is exactly the part which is an lm_sensors userspace bug.
Now, I'm actually usally a big fan of not dragging around old gunk
forever, ABI be damned, but in this case this really won't do. 2.6.10 is
a recent maintenance release and I see for the new 3.0 branch:
http://www.lm-sensors.org/wiki/Download
===
Most third party monitoring applications do not yet work with the
library in this package. We are encouraging authors to port their
applications to the new library. We already have patches for xsensors
0.60, gkrellm-2.3.0, net-snmp-5.4.1 (configure with
--with-mib-modules="ucd-snmp/lmsensorsMib" --with-ldflags="-lsensors"),
xfce4-sensors-plugin-0.10.99.2, kdebase-3.5.8(ksysguard),
sensors-applet-1.8.1 and ksensors-0.7.3-fedora-14.tar.gz (upstream is
dead this tarbal contains a version with all Debian's changes + 2
patches from Fedora, including lm_sensors-3.x support).
===
So it seems we have here a change to the kernel requiring a userspace
basically noone is ready for
Erm if you look at that same page you will notice there are links to patches
for almost every userspace package which uses lm_sensors, I know as I wrote
most of them, quite a few of them have been integrated by their resp. upstreams.
Also "noone is ready for"? lm_sensors-3.0.x is the default in both Fedora 9 and
OpenSuse 11.
But if not, .26 is around the corner and requiring libsensors-3.0 must
really not be.
I agree that requiring libsensors-3.0.2 for this is not a good solution, but I
don't want to be crippling the kernel for what I believe is a bug in 2.10.x either.
So we need todo 2 or 3 things:
1) Find out if this really is as big an issue as you make it, maybe
"sensors -s" is rightfully complaining about hwmon0 and then still happily
doing its job for hwmon1?
Again, what does plain "sensors" say? Does it still show the hwmon1
readings, and are the limits what they should be after sensors -s?
2) Fix this in the 2.10.x series (which are still supported) and do a new
2.10.x release.
3) If this really completely messes 2.10.x and in that case I'm afraid we will
have to make kernel side changes.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
