From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757077AbYDITdu (ORCPT ); Wed, 9 Apr 2008 15:33:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753959AbYDITdk (ORCPT ); Wed, 9 Apr 2008 15:33:40 -0400 Received: from srv5.dvmed.net ([207.36.208.214]:40457 "EHLO mail.dvmed.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753595AbYDITdj (ORCPT ); Wed, 9 Apr 2008 15:33:39 -0400 Message-ID: <47FD19F5.9020509@garzik.org> Date: Wed, 09 Apr 2008 15:33:09 -0400 From: Jeff Garzik User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Ingo Molnar CC: "Kok, Auke" , Matthew Wilcox , Linux Kernel Mailing List , NetDev , e1000-list , linux-pci maillist , Andrew Morton , "David S. Miller" , Linus Torvalds , Jesse Brandeburg , "Ronciak, John" , "Allan, Bruce W" , Greg KH , Arjan van de Ven , "Rafael J. Wysocki" Subject: Re: [regression] e1000e broke e1000 References: <47F69965.7030303@intel.com> <20080408083606.GA20863@elte.hu> <47FB9ABB.9080403@intel.com> <20080408183921.GA20803@elte.hu> <20080408193245.GG11962@parisc-linux.org> <20080408195123.GA28148@elte.hu> <47FBCE00.2020309@garzik.org> <20080408200652.GC28148@elte.hu> <47FBD620.1080508@intel.com> <20080409191256.GB9276@elte.hu> In-Reply-To: <20080409191256.GB9276@elte.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Report: SpamAssassin version 3.2.4 on srv5.dvmed.net summary: Content analysis details: (-4.4 points, 5.0 required) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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