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/