Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 21 Oct 1999 12:31:06 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: PATCH 2.3.23 pre 2 compile fixes |
| |
On Thu, 21 Oct 1999, Donald Becker wrote: > > The proposals to split up tulip.c into multiple drivers that supports > individual chips demonstrates a lack of understanding of the problem.
Note that "split up" does not necessarily mean what you think it means.
For example, it might be as simple as splitting up the detection and EEPROM code and the tranceiver code from the "real" tulip code.
For example, all drivers would probably have the same actual code that accesses the ring buffer, because thats is all done by the actual tulip chip itself. So start_xmit, rx and tx would be completely shared. Those aren't the ones that have been particularly fragile.
But the timeout handling and the media handling could probably be considered a separate driver altogether. Basically, the functions tend to be big case statements anyway, and maybe that should be be made more modular, so that it would be clearer what code is for the DC21041 and what is for the DC21142, because they have different routines to handle them.
Note that I don't personally think the tulip driver is all that confusing, there are certainly much worse drivers out there. It just came up as an example by Richard as being prone to break in subtle ways, and splitting up the parts that break and making them more independent of each other is probably a good maintenance strategy.
> Keep in mind that the issue isn't just about tulip.c, or even the dozen > other PCI network drivers I updated to remove the backwards compatibility at > the request of Linus. It's about the process. I've been developing drivers > this way, with supporting web pages, mailing lists and levels of test > releases, for many years. I see people claiming that the process isn't > transparent when they aren't on the mailing lists and obviously haven't > looked at how much work and discussion have passed.
Note that nobody is suggesting that you dismantle the mailing lists. Instead, people are suggesting that you should _also_ make the thing more available, together with more history of what has been going on, and be aware that a driver on its own is useless - you as a driver writer would probably prefer it if the rest of the system stayed at 1.2.13 forever so that you wouldn't have to be part of a whole.
But the fact is that no driver is an island. Even if you'd like them to be.
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/
| ![\](/images/icornerr.gif) |