I think there are straightforward solutions to this. At the moment,
making a PCI driver Cardbus-aware requires adding a small block of
code in an #ifdef. Donald Becker has done it for a few of his drivers
already. I have to duplicate some code (like the 3c59x driver) in my
package because the version I've got is ahead of what is in the 2.0
and 2.1 trees. So here is an example where integration would create
new problems: by distributing my package separately, I can work around
the version-skew between Donald's latest drivers and the official
trees. I doubt that anyone would be happy about having multiple
versions of the 3c59x driver in different parts of the kernel tree.
There are definitely ways in which the design of the PCMCIA package
has been influenced by the fact that it isn't part of the kernel
tree. And if Linux gets a more featureful device configuration
management system, some of those design choices may well need to be
reconsidered.
> > It is only apparently-feasible at the moment because Linux doesn't
> > have all that many drivers. The driver subtree has roughly doubled in
> > going from 2.0.* to 2.1.*. I'd expect that trend to continue. What
> > do we do when vendors start taking a serious interest and start
> > writing drivers? (I've heard rumors that a number of major vendors
> > are now committed to developing Linux drivers)
>
> The ones I know are mostly very very keen to get their drivers in the
> standard tree actually.
I'd expect they would be, also... the problem I was thinking of is
that if we expect the exponential growth of Linux drivers to continue
(and I think it will, in part fueled by hardware vendor participation),
we'll continue to have exponential growth of the Linux kernel driver
subtree, and it will become increasingly hard to manage as a single
entity.
-- Dave Hinds
-
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/