The biggest problem with splitting the driver into different versions
for different cards is probably going to be that the user will have to
try 15 drivers before he finds the right one. Like Donald has said many
times, even chips that look alike aren't alike, and the same goes for
boards. You can buy tulip clone boards from the same manufacturer a
month apart and find that they are different. We've got probably 100
cards/boards with tulips on them, and Donald's newest driver has
_almost_ always worked better than or as well as the version that comes
with the kernel. For Cardbus cards, this usually requires an update to
the latest pcmcia-cs version as well. If you split the drivers, does
anyone have a good idea how to automatically sense which driver will
work if there are multiple versions of tulip.c? The job is even harder
when the chip is on the motherboard. At least with a board, you can
look at the serial and model numbers...
Jeff Garzik wrote:
>
> Donald Becker wrote:
> > 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.
>
> Source code bloat is the least of anybody's worries. Very few compile
> many net drivers into a kernel image. And for the modules case, only
> that which is needed gets loaded, generally.
>
> > 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".
>
> Yes, this is a problem: no kernel maintainer for the net driver
> subsystem.
>
> If someone stepped up to fill this role, they can say tell the person
> submitting a new am79c961a driver that support already exists in
> lance.c. Until such a thing happens, you will continue to see problems
> like you describe. Further, a net driver subsystem maintainer could
> work with authors of existing modules to fold their duplicate code into
> lance.c, tulip.c, etc. That would get rid of a big complaint of yours.
>
> > 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.
>
> The bottom line is that drivers don't make it into the standard kernel
> all that often. What can we change about the process to get test
> releases into the kernel on a fairly regular basis?
>
> No matter how much you test on your own, the user audience of the
> standard kernels will always be far greater. It will greatly benefit
> the quality of your --already high quality-- drivers if kernels are
> updated regularly.
>
> Regards,
>
> Jeff
>
> -
> 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/
--Lawrence ~ ------------------------------------------------------------------------ Lawrence MacIntyre Center for Information Infrastructure Technology lpz@ornl.gov http://nrg.cind.ornl.gov/~lpz 423.574.8696
- 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/