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:	Thu, 05 Jul 2007 11:32:27 -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
 ?)

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