[arc-discuss] can a new driver qualify for self-review?

[James Carlson]

Garrett D'Amore writes:
> In the case of afe, the driver is similar to dnet in any respects.  
> However nearly all tulip chips have significant differences in a few areas:
> 
>     1) mac address programming and retrieval
>     2) multicast filter programming
>     3) media/link status programming/checking

I wasn't trying to open that discussion here.  This isn't the right
place to have it, and if we do, we'll just have to do it over again
for the ARC.

I was pointing out that this is the sort of thing you'd be likely to
hear at ARC review, and that you'd do best to have some sort of clear
answer for it.  (Preferably as part of the materials you present, so
that the question doesn't even have to get asked.)

> Trying to support all the tulip varieties leads madness.  It is the
> example that has been done by Linux, and frankly, I consider all the
> other attempts to follow Linux in this regard, misguided.  The tulip
> differences are a substantial portion of the driver (as seen above!),
> and the fact that they all use the same basic DMA descriptor layout does
> not bring them so close together that I think we should try to merge
> them all into a single driver.

There's a balancing act here, no doubt.  Sometimes there are different
chipsets that are compatible enough that having two drivers would be
silly.  Sometimes there are "revisions" within a single chipset family
that require forks.

On the whole, though, we have some very painful examples of drivers
that were forked for what the authors thought were "good" reasons, but
that turned out to be very bad decisions over time.  It's almost
always an invitation to:

  - confusion among users (why does card X from vendor A have this
    feature, but card Y from vendor A doesn't?)

  - bugs that are only partially fixed (person fixing a bug doesn't
    realize or perhaps care that it's generic to all drivers derived
    from similar source)

  - pain for other projects (if you need to change the driver
    framework, changing 5 drivers costs less than changing 50)

So, as I said, there's a bias here to avoid unnecessary forks.

> (There is also the cost of support with respect to QA and change
> management.  If you have 50-some-odd variants supported by a single
> driver, it becomes very expensive to rest them all when you make a change.)

That's the one argument from which I'd _suggest_ shying away.  It
opens up the counter-argument that the expense of having project teams
making changes among large numbers of like-kind drivers becomes much
higher, and that's unfortunately not an uncommon activity.

It's also an opening for someone to say, "oh, well, then how do we
test any of our builds?  Or do we just not bother to do that?"

The arguments based on the actual differences among the chip sets (and
lack of substantial commonality) are much better.

-- 
James Carlson, KISS Network                    <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677