Re: PATCH 2.3.23 pre 2 compile fixes

Richard Dynes (rdynes@varcom.com)
Thu, 21 Oct 1999 09:19:56 -0400


Linus Torvalds wrote:
>
> On Wed, 20 Oct 1999, Richard Dynes wrote:
> >
> > One of features of tulip is how many different variants of the tulip
> > chip is handles. But it isn't just the different pci-ethernet
> > variants (eg 21140,21143, pnic, etc...), but also the physical
>
> Note that we've had that happen before for other drivers, and the sane way
> to handle it tends to be to split the driver up.
>

I agree. I would first create generational epochs from the driver:
21140 class, 21143 class, etc, things clearly distinguishable by the
chip's capabilities. The 21140 doesn't support Nway, as an example,
so there are many branches in tulip.c v0.9x that aren't appropriate.

This would solve issues around the stability of older systems with
newer kernels, which I agree is an absolutely paramount objective.

For tulip (which I know best, Donald has 20 something drivers out
there), v0.89H is actually exactly that. It would just need to be
trimmed to only handle the 21140 class devices that it can handle.
I've had horrible experiences with it attempting to handle 21143s.

The new PCI resource scheme actually makes this easier to manage.

> Often source
> duplication is a much lesser evil, and the evil of trying to handle
> everything with one approach can be a complete disaster.
>

I agree again. I think classification by similarity is actually an
evil thing, not because it doesn't work the first time, or the first N
times, but because the flow and logic of the driver becomes contorted,
and side effects begin to appear, and then maintenance becomes a
serious issue, and suddenly you hit the wall. I view the
all-tulip-work-alikes in one single driver as an example.

> Do one thing, and do it well, even if it means that you need to
> have another driver for a card that isn't really all that similar any
> more.
>
> Splitting a driver tends to mean that the support for old cards stagnates.
> But that's fine - old cards do not change over time, and it makes it
> easier to change both the new and the old driver without having to worry
> about breaking the "other" one, because they are now independent.
>
> It's happened to many drivers over time, and if somebody really is willing
> to try to clean it up, I just want to say that at least as far as _I_ am
> concerned, I don't think it is a bad idea to have several drivers for
> similar hardware. You can try to share as much code as you reasonably can
> (see for example the 8390 driver that does this fairly successfully),
> without thinking that there has to be ONE driver that handles ALL 8390
> cards.
>

Dividing code is a normal and logical thing. To use a poor analogy,
flowers grow, and at a certain point the gardener divides the plant to
allow it to keep growing. I've been thinking this about tulip.c for a
while, but I wasn't going to instigate anything.

What holds me back is my respect for Donald: he has been very generous
of his time with me, and he has created an enourmous body of code that
is very sucessful. I agree with your comments on the process, and want
to fix it without pissing on Donald.

-Richard

-- 
    Richard Dynes
    rdynes@varcom.com

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/