Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 21 Oct 1999 13:34:55 -0400 (EDT) | From | Donald Becker <> | Subject | Re: PATCH 2.3.23 pre 2 compile fixes |
| |
On Thu, 21 Oct 1999, Richard Dynes wrote: > Jeff Garzik wrote: > > > > On a related note, what are the functional differences between tulip.c > > and de4x5.c? > I don't know is the short answer. I looked at the driver several > months ago, and it appeared to not be actively supported. A glance at > the code indicates that Nway is missing, but that's just a glance.
There are many issues. The most obvious is that it recognizes all of the Digital chips, but works with relatively few boards. So you have a driver that claims boards that it doesn't work with (and it doesn't know it won't work).
The proposals to split up tulip.c into multiple drivers that supports individual chips demonstrates a lack of understanding of the problem.
I understand driver splits -- the 8390 code was split way back in '92. In that case there were multiple boards with lots of very different circuitry around a 8390 chip. OTOH the tulip driver supports lots of chips that all tried to be mostly work-alikes, with "minor" changes in some aspect. It's most like the NE2000 clone support -- those work-alikes are all slightly different/broken, but each in their own way.
The most complicated parts are those driven by changes in the real Digital chips and design recommendations, not by the clone chips. The biggest, ugliest chunk of code is parsing the media selection in the EEPROM, which was revised endlessly by Digital and is shared by most chip types, but not used by all boards.
A split would end up like the BSD drivers that have been added in the past few months -- a half dozen mostly-identical drivers. That will bloat the kernel code even more. Following this path will mean that we end up with about a hundred more drivers like drivers/net/am79c961a.[ch], which supports only a single chip type, pointlessly duplicating the support already in lance.c. The current problem is that Linus will always accept bloat like that. There is no way to say "it is not there because it should not be there".
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.
Donald Becker Scyld Computing Corporation, and USRA-CESDIS, becker@cesdis.gsfc.nasa.gov
- 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) |