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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ