[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <469110F6.2030902@linux.intel.com>
Date: Sun, 08 Jul 2007 09:29:42 -0700
From: Arjan van de Ven <arjan@...ux.intel.com>
To: Stephen Hemminger <shemminger@...ux-foundation.org>
CC: "Kok, Auke" <auke-jan.h.kok@...el.com>,
Francois Romieu <romieu@...zoreil.com>,
Jeff Garzik <jeff@...zik.org>,
Christoph Hellwig <hch@...radead.org>,
Andrew Grover <andy.grover@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jason Lunz <lunz@...lexsecurity.com>,
Mark McLoughlin <markmc@...hat.com>,
e1000-devel@...ts.sourceforge.net, netdev@...r.kernel.org,
"Ronciak, John" <john.ronciak@...el.com>,
"David S. Miller" <davem@...emloft.net>,
Andy Gospodarek <andy@...yhouse.net>
Subject: Re: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5
?)
Stephen Hemminger wrote:
>> I would really like to continue with my original plan that I posted that follows
>> Christoph's idea. I hope you can all agree with that so we can get on with this.
>
> I think rather than having a meta-discussion, which always seems to degenerate
> into finger pointing. Let's look at the code. The problem with popular drivers
> (as I too well know) is that user's seem to find every wart. There are lots of
> old drivers that never seem to get the same scrutiny, and if they did would
> be tarred and feathered.
I'd second this; also lets be honest and fair about things and use a
similar standard for all drivers; are we going to ask all driver
submitters to remove NAPI, TSO and other stuff? I would hope not. Are
all new drivers that have even a single bitfield going to be rejected?
That's be a new rule but ok, if it applies to all drivers it's fair.
So the question in my opinion should be "is this driver good enough
for merging, and if not, what specifically is wrong enough to hold of
merging" not "what would the perfect ideal
we-have-all-the-time-in-the-world driver be" and certainly not "how is
this going to work in an enterprise distro" since the later is the
problem for the enterprise disro that they get paid to solve, not for
kernel.org kernels.
What is there now is a driver that works, is relatively clean (and yes
if you look deep enough you can ALWAYS nitpick on any code, even
Linus' or Jeff's best code) and provides good performance with all the
features a modern ethernet driver is supposed to have.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists