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 PHC | |
Open Source and information security mailing list archives
| ||
|
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
Powered by blists - more mailing lists