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

Powered by Openwall GNU/*/Linux Powered by OpenVZ