linux-kernel - Re: LMSENSORS: 2.6.26-rc, enabling ACPI Termal Zone support costs sensors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <485FD8F1.7070307@keyaccess.nl>
Date:	Mon, 23 Jun 2008 19:10:09 +0200
From:	Rene Herman <rene.herman@...access.nl>
To:	Matthew Garrett <mjg59@...f.ucam.org>
CC:	Jean Delvare <khali@...ux-fr.org>,
	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 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.
--
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/