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

From: "Kok, Auke" <[email-masked]>
Date: Tue, 03 Jul 2007 15:48:26 -0700

Christoph Hellwig wrote:
> On Fri, Jun 29, 2007 at 07:31:55PM -0700, Kok, Auke wrote:
>> all the pci-express adapters that are supported are extremely similar:
>>
>> - they all support 2 queues
>> - the register sets are (almost entirely) identical
>> - there is minimal feature variance between 82571/2/3, esb2lan, ich8/9
>>
>> The major differences between 82571/2/3, esb2lan and ich8/9 are PHY-based 
>> (4 different PHY's basically, one for 82571/2/3, one for esb2lan and 2 for 
>> ich8/9, excluding fiber and serdes here) and NVM/EEPROM.
>>
>> ich8 and 9 are consistent with 82571/2/3 - on-board nic's based on the 
>> 82571 design with different PHY's, and added features for the newer 
>> demands. A driver split here would be possible but not justified IMHO.
> 
> Sounds like the perfect split to me.  I'd suggest you rip out support
> for older hardware from your new driver and do the resulting simplification
> and post a new e1000e driver for this hardware, removing existing support
> from e1000 at the same time.  Later you can do the feature flags and similar
> improvements to the old driver driver in an incremental fashion without the
> burden of having to keep up with new hardware.

Jeff,

it seems that this is the preferred path to go including "e1000e" as the new 
driver name for all 8257x family based adapters. Just for the record I'd like 
your acknowledgement on the following plan:

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 have no idea how internally this is going to get accepted, there will 
certainly be some fireworks around here soon :).

Auke

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/