Jeff Garzik wrote:
Kok, Auke wrote:
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 like the general gist of it. My own suggestion would be
1) Create e1001.c, which is the SMALLEST POSSIBLE "it works" driver for
ICH9. No feature enablement (no TSO, no MQ, no IOAT, not even checksum
offload), just a rock solid, no frills driver. Think like e100.c :)
2) We review the hell out of e1001, and merge it. This enables ICH9
users, and ONLY ICH9 users, on e1001 in the upstream kernel, allowing us
to blithely ignore driver->driver migration issues present with other chips.
At this point, e1001 is out in the field and in the upstream kernel in
the absolute shortest amount of time. Users of chips NOT found in
current e1000 driver, and all future chips, can be enabled with little
impediments, in parallel with the steps below.
(all the "3^y" steps can occur in parallel)
3^1) Add features to e1001, enabling new gizmos on new hardware. This
can proceed in parallel with any e1000 work. This allows users to use
git-bisect to find driver bugs -- or even hardware bugs, since you have
a baseline working e1001 driver.
3^2) Add full ICH8 (8257x?) support to e1001.
4) Drop 8257x PCI IDs from e1000. See who complains. Lather, rinse,
repeat.
5) Figure out how the hell to clean up the current mess that is e1000,
and how to make sure e1000 and e1001 stay clean, long term.
This is not acceptable and hardly fair to expect from us.
It also exposes users to endless delays and uncertainties as to a final
resolution. Not to mention that writing a driver from scratch for (just) ich9
will take significant time, is silly since it's almost identical to ich8 etc..
I don't think that anyone besides you and maybe one or two others are interested
in doing this rewrite from scratch. The rest of us would rather see something
much more similar to my original suggestion which relieves the ich9-wishes for
everyone and provides a good starting point to go forward. Not to mention that a
lot of that code is already there, and at least cleaned up quite a bit already.
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
