public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Len Brown <lenb@kernel.org>
Cc: Rene Herman <rene.herman@keyaccess.nl>,
	linux-acpi@vger.kernel.org,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	lm-sensors@lm-sensors.org,
	"Mark M. Hoffman" <mhoffman@lightlink.com>,
	Hans de Goede <j.w.r.degoede@hhs.nl>,
	Zhang Rui <rui.zhang@intel.com>
Subject: Re: LMSENSORS: 2.6.26-rc,  enabling ACPI Termal Zone support costs sensors
Date: Mon, 23 Jun 2008 21:54:42 +0200	[thread overview]
Message-ID: <20080623215442.0a536bf4@hyperion.delvare> (raw)
In-Reply-To: <alpine.LFD.1.10.0806231333030.2984@localhost.localdomain>

Hi Len,

On Mon, 23 Jun 2008 13:54:56 -0400 (EDT), Len Brown wrote:
> Rene,
> Thank you for reporting this.
> 
> I agree that this failure is an unwelcome surprise to those users
> who upgrade to 2.6.26 but are still using libsensors <= 2.10.6.
> 
> Jean, Mark, Hans,
> 
> I'm actually fine with adding a temporary kernel config option
> along the lines Rene suggested to ease the  migration
> to linux-2.6.26 for those users.
> 
> But the config option would need to be scheduled for removal
> after a certain period (say 6 months) so we don't have to maintain
> it forever.
> 
> More importantly, I think it would also have to be disabled by default
> so that it would not have a negative impact on what we think are the
> majority of properly configured systems.  After all, we fixed this
> bug in user-space about out 4 months ago and as you point out, the
> distro upgrade path is actually quite well looked after.
> 
> So I'm not sure how useful it would be to the target users.
> After they run into the problem, they'd probably google it
> and find that they can either tweak a kernel config option
> or upgrade libsensors.  And we'd prefer that they do the
> later rather than the former, yes?

If the option defaults to thermal zone being enabled, and users have to
rebuild their kernel to disable it, then I don't think it has any
value. Patching and rebuilding libsensors is no harder than
reconfiguring and rebuilding the kernel, so we can as well tell the
users to do the former.

If the option defaults to thermal zone being disabled, then it makes
some sense as a way to smooth the transition. If the help text is clear
enough (clearly saying for which versions of lm-sensors users can
enable the option and for which versions they would rather not) it
should work. The drawback being that users in a hurry might stick to
the default without reading the help text, and miss an opportunity to
have the ACPI thermal zones magically integrated into their favorite
monitoring application.

Whether avoiding the risk of easily fixable breakage for some users is
worth the temporary loss of new functionality for other users, I can't
really say. I think I wouldn't do it myself, but I'm not the only one
to decide. If we decide to do it, I have no objection.

Thanks,
-- 
Jean Delvare

  reply	other threads:[~2008-06-23 19:55 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-22  0:47 LMSENSORS: 2.6.26-rc, enabling ACPI Termal Zone support costs sensors Rene Herman
2008-06-22  7:28 ` [lm-sensors] " Hans de Goede
2008-06-22 13:15   ` [REGRESSION, ABI] " Rene Herman
2008-06-22 13:23     ` Rene Herman
2008-06-22 14:29     ` [lm-sensors] [REGRESSION, ABI] " Hans de Goede
2008-06-22 15:26       ` Rene Herman
2008-06-22 18:07         ` Hans de Goede
2008-06-22 18:25           ` Rene Herman
2008-06-22 21:58             ` Rene Herman
2008-06-23  1:44               ` Zhang Rui
2008-06-23  5:21                 ` Hans de Goede
2008-06-23 10:40                 ` Rene Herman
2008-06-23 11:06                 ` Jean Delvare
2008-06-23 10:56             ` Jean Delvare
2008-06-23 17:54         ` [lm-sensors] [REGRESSION, ABI] " Len Brown
2008-06-23 19:54           ` Jean Delvare [this message]
2008-06-23 20:07           ` Rene Herman
2008-06-23 20:24             ` Rene Herman
2008-06-22 15:43       ` Rene Herman
2008-06-23 10:08       ` Jean Delvare
2008-06-23 10:24         ` Rene Herman
2008-06-23 11:57           ` Jean Delvare
2008-06-23 12:35             ` Rene Herman
2008-06-23 13:47               ` Jean Delvare
2008-06-23 14:06                 ` Rene Herman
2008-06-23 14:31               ` Matthew Garrett
2008-06-23 17:10                 ` Rene Herman
2008-06-23 13:51             ` Hans de Goede
2008-06-22  7:30 ` [lm-sensors] " Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080623215442.0a536bf4@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=j.w.r.degoede@hhs.nl \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.org \
    --cc=mhoffman@lightlink.com \
    --cc=rene.herman@keyaccess.nl \
    --cc=rui.zhang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox