netdev - Re: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5 ?)

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:	Sun, 08 Jul 2007 14:06:20 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Arjan van de Ven <arjan@...ux.intel.com>
CC:	Stephen Hemminger <shemminger@...ux-foundation.org>,
	"Kok, Auke" <auke-jan.h.kok@...el.com>,
	Francois Romieu <romieu@...zoreil.com>,
	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
 ?)

Arjan van de Ven wrote:
> 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 

That was merely a suggestion.  My general meaning was "small driver is 
easier to get into the kernel and into the field."


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

That's one of a gazillion checklist items that a new driver has to pass 
through.  You know how it works for new drivers.

"it looks better than our last try" and "it looks better than that ugly 
driver over there" does not grant you a free pass on review.

I'm not asking for perfection, just something other than

* e1000 gets feedback
* Intel disappears for months
* Intel reappears with e1000 rewrite
* Intel fights tooth and nail when the driver is not accepted verboten

And specifically I worry that three years down the road we will reach 
the same point again, when e1000new is even more complex.

Will Intel shrug its shoulders and decide its time for another rewrite?


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

Is this is the attitude, what's the point of even posting the driver for 
review?  Intel posted e1000new on June 29.  Feedback was then posted. 
Ten days later, without a single revision, Intel declares its own driver 
clean and working and good enough for merging as-is.

	Jeff



-
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