netdev - 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:	Tue, 03 Jul 2007 15:48:26 -0700
From:	"Kok, Auke" <auke-jan.h.kok@...el.com>
To:	Jeff Garzik <jeff@...zik.org>
CC:	Christoph Hellwig <hch@...radead.org>,
	"Kok, Auke" <auke-jan.h.kok@...el.com>,
	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>
Subject: Splitting e1000 (Was: Re: e1000: backport ich9 support from 7.5.5
 ?)

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