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] [day] [month] [year] [list]
Message-ID: <48600697.4080800@keyaccess.nl>
Date:	Mon, 23 Jun 2008 22:24:55 +0200
From:	Rene Herman <rene.herman@...access.nl>
To:	Len Brown <lenb@...nel.org>
CC:	Hans de Goede <j.w.r.degoede@....nl>, linux-acpi@...r.kernel.org,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	lm-sensors@...sensors.org,
	"Mark M. Hoffman" <mhoffman@...htlink.com>,
	Zhang Rui <rui.zhang@...el.com>,
	Jean Delvare <khali@...ux-fr.org>
Subject: Re: [lm-sensors] [REGRESSION, ABI] Re:  LMSENSORS: 2.6.26-rc, enabling
 ACPI Termal Zone support costs sensors

On 23-06-08 22:07, Rene Herman wrote:

> On 23-06-08 19:54, 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?
>>
>> just let me know.
> 
> Thank you for the reason. Yes, people upgrading libsensors would be 
> preferred and this issue should show up in google now.
> 
> Frankly, if I had gone to the lm-sensors homepage and had seen a fixed 
> 2.x version available I'd no doubt have shrugged it off then and there 
> so I might as well do so now that Delvare announced that it's _going_ to 
> be there real soon. 2.10.7 should be painless enough as an upgrade, it's 
> needing lm-sensors 3.0(.2) and all its listed accompanying patches to 
> programs depending on libsensors which triggered this thread.
> 
> So, <shrug>. I know how to fix my own systems, others will be able to 
> find out and once lm-sensors 2.10.7 is available, it's not a big deal 
> anymore.
> 
> That said, here's the "make it optional" patch tweaked according to your 
> comments. Feel free to drop it on the floor...

Typo(s) in the feature-removal-schedule (only change).

Rene.

View attachment "0001-acpi-thermal-allow-disabling-of-thermal-zone-hwmon.patch" of type "text/plain" (4416 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ