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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
