Date:	Fri, 06 Jul 2007 17:14:49 -0700
From:	"Kok, Auke" <auke-jan.h.kok@...el.com>
To:	Jeff Garzik <jeff@...zik.org>
CC:	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>,
	'Stephen Hemminger' <shemminger@...ux-foundation.org>,
	Andy Gospodarek <andy@...yhouse.net>,
	Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5
 ?)

Jeff Garzik wrote:
> Kok, Auke wrote:
>> 1a) We post an e1000e driver that implements support for all 8257x 
>> (ich8/9, es2lan etc) devices.
>> 1b) We post a patch that drops support for all of these devices in the 
>> form of a pci-ID removal (no code removed) for e1000.
>>
>> 2) we post patches that remove code support for non-8254x devices at a 
>> later stage.
>>
>> 3) we backport any and all cleanups and flags from e1000e to e1000 where 
>> applicable.
>>
>>
>> This plan leaves a significant gap that I'm worrying about: after step 
>> (1) we basically have forced everyone to switch without providing a 
>> fallback (allthough we have our out-of-tree driver, but no in-kernel 
>> version in case issues exist).
>>
>>
>> Comments?
> 
> I like the general gist of it.  My own suggestion would be
> 
> 1) Create e1001.c, which is the SMALLEST POSSIBLE "it works" driver for 
> ICH9.  No feature enablement (no TSO, no MQ, no IOAT, not even checksum 
> offload), just a rock solid, no frills driver.  Think like e100.c :)
> 
> 2) We review the hell out of e1001, and merge it.  This enables ICH9 
> users, and ONLY ICH9 users, on e1001 in the upstream kernel, allowing us 
> to blithely ignore driver->driver migration issues present with other chips.
> 
> 
> At this point, e1001 is out in the field and in the upstream kernel in 
> the absolute shortest amount of time.  Users of chips NOT found in 
> current e1000 driver, and all future chips, can be enabled with little 
> impediments, in parallel with the steps below.
> 
> (all the "3^y" steps can occur in parallel)
> 
> 3^1) Add features to e1001, enabling new gizmos on new hardware.  This 
> can proceed in parallel with any e1000 work.  This allows users to use 
> git-bisect to find driver bugs -- or even hardware bugs, since you have 
> a baseline working e1001 driver.
> 
> 3^2) Add full ICH8 (8257x?) support to e1001.
> 
> 4) Drop 8257x PCI IDs from e1000.  See who complains.  Lather, rinse, 
> repeat.
> 
> 5) Figure out how the hell to clean up the current mess that is e1000, 
> and how to make sure e1000 and e1001 stay clean, long term.


This is not acceptable and hardly fair to expect from us.

It also exposes users to endless delays and uncertainties as to a final 
resolution. Not to mention that writing a driver from scratch for (just) ich9 
will take significant time, is silly since it's almost identical to ich8 etc..

I don't think that anyone besides you and maybe one or two others are interested 
in doing this rewrite from scratch. The rest of us would rather see something 
much more similar to my original suggestion which relieves the ich9-wishes for 
everyone and provides a good starting point to go forward. Not to mention that a 
lot of that code is already there, and at least cleaned up quite a bit already.


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