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 12:30:48 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Len Brown <lenb@...nel.org>
Cc:	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

* 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.

> Okay, I can delay this way:
> 
> 2.6.39:
> 	feature-removal.txt targets 2.6.42 removal
> 	depend on CONFIG_EXPERT
> 
> 2.6.40, 2.6.41:
> 	WARN once on run-time access
> 
> 2.6.42:
> 	remove.

Regardless of removal, i'd suggest a "this code is not supported" kind of 
WARN() message to the APM code today, into .39 - to see whether it pops up 
anywhere - and mark it for -stable as well.

.42 removal might be too fast, considering the typical release schedule of 
Linux distributions. And i'm still doubting the removal itself: we are adding 
lots of special-purpose subarch drivers to arch/x86/ as we speak (the embedded 
mess coming to x86) - which drivers will be tomorrow's APM code. On what 
grounds do we treat APM support differently?

Our general compatibility with old hardware is an *asset* that we should value.

Thanks,

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