Messages in this thread | | | Date | Wed, 20 Oct 1999 15:15:02 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: PATCH 2.3.23 pre 2 compile fixes |
| |
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 > interfaces: mii, sym, serial, etc.... Then throw in EEPROM formats, > different assignments of hardware control bits, etc... > > That's a big space to cover in one driver. All of this makes tulip > relatively large and complex as drivers go. IIRC, the source is > 100k+. And it has *worked* for me quite well. However I'm on the more > modern hardware that gets the most attention. Testing for side effects > against older hardware under these circumstances is at once tedious > and difficult.
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/
| |