linux-kernel - Re: [PATCH][RFC] Kill off legacy power management stuff.

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: <Pine.LNX.4.64.0704181940260.5400@localhost.localdomain>
Date:	Wed, 18 Apr 2007 19:45:42 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Len Brown <lenb@...nel.org>
cc:	davej@...emonkey.org.uk, Stephen Rothwell <sfr@...b.auug.org.au>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH][RFC] Kill off legacy power management stuff.

On Wed, 18 Apr 2007, Len Brown wrote:

> On Wednesday 18 April 2007 16:23, Robert P. J. Day wrote:

> > ok, i get it now and -- correct me if i'm wrong -- all my legacy PM
> > removal patch was doing was exposing a design boo-boo in which
> > APM/ACPI contention was being handled by a macro in a subsystem even
> > older than either of them, right?
>
> yeah, it didn't start out that way, the bug was added when the
> CONFIG_PM_LEGACY #define was added.
>
> > so all that needs to be done is add back in a contention solution
> > of some kind that doesn't rely on that ancient system, yes?
>
> Yes, it is a matter of making the variable not go away when the
> #define goes away.
>
> > as for that thinkpad t30 situation, well, that's just borked, and
> > should be fixed.
>
> yes, the actual failure is that APM mode on the T30 hangs -- and
> that is independent of the issue at hand.  However, there could be
> other failures on other machines when both APM and ACPI think they
> are active.

at this point, i think the proper approach is to locate and remove all
dependencies on the legacy PM code, which includes making sure there's
a reliable contention mechanism for APM and ACPI that doesn't need
anything out of the legacy code or header files.  once that's done,
the legacy deletion itself should be trivial.

the obvious place for the contention stuff is, i would think,
include/linux/pm.h, yes?

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
-
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/