Jeff Garzik wrote:
Ignoring small potatoes, the merge stoppers in my mind are:
1) Transition plan. I strongly oppose switching all e1000 users en
masse to a new driver, especially so soon. Flag day transitions to
unproven drivers suck. Defaults don't work: users use the old driver
until the default changes, which means the new driver gets little field
testing.
Regardless of my opinion of old-e1000 maintainability, top priority is
to keep users running on a stable driver until new driver is stable. I
would propose merging a new driver with only the PCI IDs not already in
the kernel, get that stable, then consider moving the rest of the
PCI-Express PCI IDs (or others?).
I would strongly vote for taking a stripped down e1000new then, mask out all the
pci id's except ich9, remove all code for pre-pci-e silicon and remove the most
annoying and needlessly complexing code like the semi-implemented multiqueue
code that is in there.
How we are going to improve the internal api then can subsequently be done
upstream in steps: implement using phylib, reorganize the code. This would give
the community a view on the progress.
I fear that if I spend yet another 2 months offline working on making a minimal
ich9 driver I will lose even more time and patience: Even though the current
driver (with pre-pci-e stripped) might not be as nice as you want, at least we
can work together on it. I would rather go with something I know that works,
isn't too bad, and we have time and start reviewing upstream immediately.
2) Internal API. An "it can do anything" API is a hint that the driver
should be structured differently. Perhaps a divorce between pre-PCIe
and PCIe will help things (or 8257x vs other?). I tend to think that
both e1000 and e1000new could be cleaned up substantially by such a
split. Also, specifically for PHYs, we already have a phy layer that
can be used a focal point for PHY modularity.
Agreed. All current e1000 pci-e hardware is based on the same mac, so it's the
logical split. The differences are PHYs and manageability, but the interface is
rather similar throughout, as well as features.
Overall, within minor chip revs you'll probably create standard
branches. But within major chip revs, you really should be looking at
separate code paths rather than trying to shoehorn a wide variety of
chips down the same (highly modular!) hot path. That slows down
everybody to the same speed (least common denominator), and makes it
more difficult to follow the code path for a single chip.
looking at this with respect to e1000e (a pci-e only e1000 driver) - this would
make perfect sense: most of the irq and rx/tx paths are identical across the
board. So this confirms IMO that we should not split beyond this.
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
