Dale Ghent wrote:
On Aug 26, 2009, at 1:05 AM, Dale Ghent wrote:
6874785 e1000g driver should be forked into a legacy version and new
e1000e driver
I was under the impression that the driver that is superseding e1000g
is igb. Are we going to have a fourth driver for Intel gig-e chipsets
now (iprb, e1000g, igb, and e1000e?)
Woops, make that fifth... I forgot about ipge.
Wrong. Sixth. :-) dnet supports Intel 21145 devices. (Granted the
2114x family was acquired from Digital....) Of course, those (along
with iprb) are 10/100. Then you have the 10g driver ixgbe. :-)
I've not looked at the bug yet, but IMO, trying to have a single driver
cover every possible variant of device, especially when the devices
differ in significant ways, is often not ideal. The problems with such
a unified driver:
1) the risk of a change for one part breaking things for another
part increases significantly
2) as the number of chip-specific hacks or workarounds increases,
the maintainability of the driver decreases. (and the code size
increases significantly.) The Linux tulip driver is a good example of this.
3) it becomes nearly impossible to do end-of-life management
properly for older devices (I submit the NVIDIA graphics devices as an
example where a single unified driver has forced undesirable EOF
characteristics from the IHV onto Solaris customers)
4) older devices may often impose inferior design choices, such that
better designs or newer techniques can't be used for fear of breaking
compatibility with older devices. (For example, adding "conditional"
support for Crossbow or PCI SR-IOV might be very very troublesome.)
So, IMO, it doesn't matter how many different drivers we have to support
a family of technologies from a vendor, as long as there sufficient
variation in the parts to make the driver split worthwhile. A good
example would be a device that adds SR-IOV. Another good example would
be a device with a completely different descriptor layout. A bad
example would be a device that needs a different tunable programmed into
some fifo threshold. Finding the balance
between these is something that the engineer needs to figure out.
Note that I believe that it *is* the case that such a decision to split
out a new driver should be made at the boundary of a new part. Its not
a good idea, IMO, to change the name of a driver that is used for a
specific device, after that device (and the original supporting driver)
have already shipped.
- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
