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

["Kok, Auke" <auke-jan.h.kok@intel.com>]

Kok, Auke wrote:
> 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).

Actually, this plan temporarily allows users to manually bind "e1000" to 
pci-express adapters in case they wish to do so, thereby providing a fallback 
driver for everyone.

If we leave the "e1000" driver untouched (not removing code support for pci-e 
adapters) for at least a full kernel release, this should be reasonable for 
everyone I hope. After we have gained some confidence in "e1000e" we can start 
removing code from "e1000" for pci-e adapters.

How does that sound?

Auke