[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <485F9877.1060902@keyaccess.nl>
Date: Mon, 23 Jun 2008 14:35:03 +0200
From: Rene Herman <rene.herman@...access.nl>
To: Jean Delvare <khali@...ux-fr.org>
CC: Hans de Goede <j.w.r.degoede@....nl>, linux-acpi@...r.kernel.org,
Zhang Rui <rui.zhang@...el.com>,
"Mark M. Hoffman" <mhoffman@...htlink.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
lm-sensors@...sensors.org
Subject: Re: LMSENSORS: 2.6.26-rc, enabling ACPI Termal Zone support costs
sensors
On 23-06-08 13:57, Jean Delvare wrote:
> On Mon, 23 Jun 2008 12:24:06 +0200, Rene Herman wrote:
>> No Jean, this is totally unacceptable. No matter how you want to call
>> things, 2.6.26 is going to break important functionality on millions of
>> systems and you simply do not get to do that.
>
> No, it's not going to be the end of the world that you predict. Please
> stop being alarmist, it really doesn't help.
>
> We are going to break hardware monitoring for users who upgrade to
> kernel 2.6.26 by themselves and have enabled option "THERMAL"
Which is an option selected by ACPI_THERMAL, for which I quoted the help
text earlier. Basically everyone with ACPI enabled will have it enabled.
Rather wide-spread, that is.
> and are using lm-sensors <= 2.10.6. I suspect this is a relatively
> small number of users
Yes, right. All not completely new systems, all completely new slackware
and derived systems... "relatively" is a word very much needed here.
I really cannot believe you guys are actually arguing this. It seems
that me being tired and short pulled this in to senseless country but
can we please concentrate on the issue?
libsensors dictated the ABI rule that the hwmon directories must have
device backlinks; the new ACPI Thermal Zone hwmon interface breaks that
bit of ABI. It is not relevant that that ABI may have gotten to be as a
result of unfortunate programming on the userspace side -- the only
thing relevant is that it IS. lm-sensors 2 is on millions of systems out
there. This is not meant agressively, or whatever you guys seem to want
to read in my words, it's un undeniable fact.
> and these are also the ones who are presumably skilled enough to go
> to http://www.lm-sensors.org/, find the patch they need, and apply it
> to libsensors themselves.
At times there can obviously be situations where it's fine to require
new userspace but in this case we have a new userspace which hasn't even
been released yet, we have a ton of _different_ userspace depending on
that bit of core userspace, we have breakage of the important kind (as
you no doubt know, sensors can be pretty vital, although admittedly it's
not silent breakage at least) and we have an opportunity to just say
"okay, we'll apply a 1 line patch and be done with it" which avoids any
and all problems. Why are you arguing this?
>> Can you comment on the last patch posted? It's trivial:
>>
>> http://lkml.org/lkml/2008/6/22/243
>
> It's trivial and wrong, so thanks but no thanks. The bug is in
> libsensors, we fix it in libsensors.
This cannot be the reason, because it's not wrong. We just need a device
backlink. Basically, any single one will do. It's just about keeping
lm-sensors 2 happy.
Rene.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists