It actually works both ways: a feature your driver depends on is much
more likely to survive if its use is plainly visible via grep than if
that driver is only known to those who use it.
Another advantage is education: whenever I need to touch areas of the
kernel I haven't touched before or not for a long time, I look at
what other code in those areas does. If the most actively maintained
drivers are maintained outside of the kernel tree, it will be hard to
find good examples for new or changed functionality. (This gets
particularly bad if I need to decide between competing features, e.g.
the various list handlnig functions. Getting drivers from a single
author may be quite misleading in this case.)
The main problem I perceive with drivers in the mainstream kernel
tree is that changes may happen without the respective maintainer
knowing why. Maybe it would be good if people get into the habit of
marking changes they make to other people's code with a short
comment. Disadvantage: the original maintainer has to issue a patch
every once in a while just to remove the markings, increasing the
overall patch load.
> The strategy of putting all device drivers in the kernel tree is
> fundamentally unscalable.
Unfortunately, yes.
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/- 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/