linux-kernel - Re: [PATCH] x86 APM: delete Linux kernel APM support

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:	Fri, 25 Mar 2011 23:33:23 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Len Brown <lenb@...nel.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>, x86@...nel.org,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] x86 APM: delete Linux kernel APM support

On Friday, March 25, 2011, Ingo Molnar wrote:
> 
> * Len Brown <lenb@...nel.org> wrote:
> 
> > > Thus from a maintenance POV APM has not been much of a drag on the x86 
> > > maintainer side. Sure, we do not test it, but that's the case with most of 
> > > the obsolete drivers in the kernel.
> > > 
> > > The principle is that as long as there's no ongoing drag, the cost of 
> > > carrying obsolete drivers is minimal - and the unknown cost of screwing 
> > > someone in a big way by removing hardware support is hard to measure 
> > > reliably. So we are cautious and err on the side of supporting too much 
> > > hardware.
> > 
> > I think this reasoning would apply in 2006, but that was 5 years ago.
> 
> I cited a few real examples:
> 
>  > > Beyond the lack of a upstream-visible feature-removal-schedule entry, we 
>  > > still have an Arcnet driver which hardware was obsoleted by Ethernet in the 
>  > > late 80s, and we still have i486 support and those are *much* older than 
>  > > APM.
> 
> So how does your reasoning not apply to those drivers? There's several which 
> are older than APM support.
> 
> We had this really big battle about x86/Voyager two years ago, which x86 
> subarchitecture literally had just a single user left, and the code was more 
> intrusive than APM. Even there after much flaming the eventual consensus was 
> that we'd accept it back if it was done cleanly, as part of the new-style 
> x86_platform code.
> 
> Given that APM fits into the current PM frameworks there's no such problem here 
> that i can see.

Well, it kind of does but not really. :-)

The main problem with APM is that nobody really works on it and I'm not sure
if there are any active users.  At least no one reports any problems with it,
which is kind of surprising, given the number of chages we've made in the PM
core for the last couple of years.  So quite likely it's just become
non-functional over time anyway, but we have no confirmation.

Thanks,
Rafael
--
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/