Whether it is a pain maintenance-wise depends very much on what you
need to do. I think the vast majority of users would be much happier
to be able to get new drivers and driver updates without having to
upgrade their kernel to the latest and greatest (which is usually a
development kernel, not a stable release, and which may require
upgrading a variety of user-level tools). On the other hand,
standalone driver distributions are inconvenient for people who want
to follow the latest kernel developments.
As the PCMCIA maintainer, I can tell you that for every person I hear
complain about PCMCIA not being in the kernel tree, I've probably had
several hundred support issues that have been resolved by PCMCIA (and
not kernel) upgrades.
It is easier to maintain unmaintained drivers when they are in the
kernel tree. That is, if a driver doesn't have an active maintainer,
the only way it will be kept up to date with respect to kernel API
changes is if it is in the kernel tree and can be updated by the usual
global find-and-replace style of update. For drivers that are under
active development and have active maintainers, I know that people
like me, Donald Becker, and probably others, find this style of
"maintenance" very frustrating. Active driver development requires
that an author maintain their own source tree independent of what is
in the kernel (whether it can actually be built standalone or not is a
separate issue). The current big-kernel-tarball approach encourages
kernel API drift (since some developers are indifferent or oblivious
to the impact of changes on things that are not in the kernel tree)
and version skew between what is in the kernel tree and what is in our
driver development trees.
The strategy of putting all device drivers in the kernel tree is
fundamentally unscalable. It has been adequate until now, but with
the exponential proliferation of device drivers we've seen, the time
will come, I'd guess in the next two years or so, when people will
realize that this just won't work any more. No one is going to want
to hand propagate kernel API changes through 1000 (or 5000) device
drivers in the kernel tree just to get a clean build, or even to wade
through that many kernel config options to find the ones they want.
Device manufacturers are going to start distributing Linux drivers
(they already have started), and this is also going to perturb the
current driver maintainer model.
-- 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/