public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rene Herman <rene.herman@keyaccess.nl>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Jean Delvare <khali@linux-fr.org>,
	Hans de Goede <j.w.r.degoede@hhs.nl>,
	linux-acpi@vger.kernel.org, Zhang Rui <rui.zhang@intel.com>,
	"Mark M. Hoffman" <mhoffman@lightlink.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	lm-sensors@lm-sensors.org
Subject: Re: LMSENSORS: 2.6.26-rc,  enabling ACPI Termal Zone support costs sensors
Date: Mon, 23 Jun 2008 19:10:09 +0200	[thread overview]
Message-ID: <485FD8F1.7070307@keyaccess.nl> (raw)
In-Reply-To: <20080623143112.GA4160@srcf.ucam.org>

On 23-06-08 16:31, Matthew Garrett wrote:

> On Mon, Jun 23, 2008 at 02:35:03PM +0200, Rene Herman wrote:
>> 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.
> 
> No, libsensors made an assumption about the ABI that turns out not to be 
> true. The ABI hasn't changed, libsensors is just being exposed to a case 
> it didn't previously see.
> 
> We've had this kind of change before. The ACPI backlight code changed in 
> such a way that scripts that blindly wrote values instead of (correctly) 
> reading the maximum brightness value broke. mmap's behaviour changed in 
> such a way that it was no longer possible for vm86 to execute code that 
> wasn't mapped as executable, breaking libx86. The applications in 
> question were undeniably buggy. Those are examples that I was personally 
> involved with - I'm sure there are others. Where userspace has made 
> false assumptions, it's not the kernel's responsibility to continue to 
> support those assumptions.

We are not going to agree. In this, it's not a random application, but the
one and only interface to sensors that's in use that breaks. It is all of
sensors support that breaks, all user interfaces, as they all depend on the
one libsensors. Sure, if some random application makes bad assumptions the
remedy is fixing the random application. If the one and only interface to
something breaks, it's the ABI that breaks.

And if people really insist on calling it FNOOZLEGLUM breakage instead of
ABI breakage, all for it. I love exciting words. Its just that I'm really
more interested in the "breakage" bit than anyone else in this thread it
seems.

Rene.

  reply	other threads:[~2008-06-23 17:09 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
2008-06-23 20:07           ` [lm-sensors] [REGRESSION, ABI] " 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 [this message]
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=485FD8F1.7070307@keyaccess.nl \
    --to=rene.herman@keyaccess.nl \
    --cc=j.w.r.degoede@hhs.nl \
    --cc=khali@linux-fr.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.org \
    --cc=mhoffman@lightlink.com \
    --cc=mjg59@srcf.ucam.org \
    --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