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/