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/