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]

Message-ID: <46914382.8090801@linux.intel.com>
Date:	Sun, 08 Jul 2007 13:05:22 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Jeff Garzik <jeff@...zik.org>
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
 ?)

Jeff Garzik wrote:
> 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."

it didn't quite come across as a suggestion, but if it was only a 
suggestion then ok; it's not really a practical option.

>> 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 know how it works for new drivers; they need to be good enough to 
maintain forward and form a burden on the stack/maintainers. Any 
remaining items need to be small enough to not be a 'risk' for users.

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

and feedback is being incorperated.

> Ten days later, without a single revision, Intel declares its own driver 
> clean and working and good enough for merging as-is.

No. Arjan looked at driver and sees a rather clean driver compared to 
some of the other recently merged drivers, sees a list of relatively 
simple todos (some of which obviously aren't merge stoppers, others 
are) and hopes that this driver will be treated objectively without 
the appearance of having different levels of bars depending on what 
your email address ends with.
-
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