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.
For example, see the IDE driver. It has core IDE functionality, but then
multiple "sub-drivers" to do tuning etc. That may not be required for the
tulip driver, but if the driver is starting to look fragile, then by all
means at least give it some serious thought as an option. Often source
duplication is a much lesser evil, and the evil of trying to handle
everything with one approach can be a complete disaster.
Remember: the UNIX philosophy is to NOT try to create the "GNU Emacs of
drivers". 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.
See how the ncr53c7,8xx SCSI driver is handled: there are actually two
drivers, where the newer driver only handles the newer cards, and as a
result BOTH drivers are simpler (and the newer driver can be noticeably
faster because it doesn't have to worry about issues that only happen with
the old and arguably broken cards).
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.
For example, to just point out that this is not a problem just for network
drivers: the same thing is definitely apparently happening with the PCMCIA
host controllers. They are all just "similar enough" that one driver tries
to handle them all, but as a result that one driver is quite fragile, and
when somebody tries to fix an old ISA card that can break cardbus support
and vice versa.
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.
Linus
-
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/