linux-kernel - Re: [regression] e1000e broke e1000

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: <47FD19F5.9020509@garzik.org>
Date:	Wed, 09 Apr 2008 15:33:09 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	"Kok, Auke" <auke-jan.h.kok@...el.com>,
	Matthew Wilcox <matthew@....cx>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	NetDev <netdev@...r.kernel.org>,
	e1000-list <e1000-devel@...ts.sourceforge.net>,
	linux-pci maillist <linux-pci@...ey.karlin.mff.cuni.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	"Ronciak, John" <john.ronciak@...el.com>,
	"Allan, Bruce W" <bruce.w.allan@...el.com>,
	Greg KH <greg@...ah.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [regression] e1000e broke e1000

Ingo Molnar wrote:
> The most common distro setup is E1000=m and E1000E=m. The most common 
> embedded setup is _one_ of the two drivers as =y.

Agreed, and agreed.


> So i'm not sure why 
> you are arguing about all this. Please just fix this bug, simple as 
> that.

I haven't said NAK, but I think the suggested fix is a waste of time because

1) it breaks (by disallowing) a valid setup based on one report

2) it only happens to experienced kernel hackers with weird configs

3) the suggested fix binds together more tightly two drivers we are 
trying to keep separate

4) it is a temporary situation that will go away in 2.6.26 anyway

So from my point of view, your request is to pick the breakage you don't 
care about (#1, above) to fix the breakage you do care about.

It's a "pick your poison" choice, from my POV.

Given that POV, that's why I lean towards avoiding your Kconfig fix -- 
viewing this as a transition issue, and not something to be fixed by 
limiting the choices of others.

But if everyone strongly agrees with you... go ahead and patch, I won't 
NAK it.

I dislike the Kconfig system growing "temporary" hacks, which tend to 
accumulate false dependencies over time.  But I readily admit that's a 
general principle and not a hard rule...

	Jeff


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