"for crying out loud why isn't DKMS official tree code"
Because upstream kernel developers think that out-of-tree kernel code is disgusting and awful
and evil, and DKMS is unnecessary for in-tree code.
They don't mind the idea that, in order to use new hardware or use a newer driver, you need to
upgrade your entire fucking kernel, along with without user-space libraries and daemons and
tools occassionally get broken by those updates (hal, udev, and anything that uses the fluid
sysfs paths).
Not sure it's really worth it to whine about the kernel like that, though. It's the same deal
for a Linux distribution as a whole. Want a newer version of FooApp? Upgrade your whole
fucking OS to the next release, and then you also get all those undesired changes to your
desktop and other apps along with all the new bugs and breakage you didn't have to put up with
before.
Linux (both the kernel and the family of OSes) has always been based on one of two models: the
"compile shit directly from version control on a daily basis" model and the "you get a fixed
set of software snapshots in your OS appliance" model. If you dislike both of those models,
use a different OS.
Posted Dec 3, 2007 20:39 UTC (Mon) by drag (subscriber, #31333)
[Link]
Plus DKMS isn't a big deal when it comes to open source drivers.
The only thing that matters in terms of kernel would be things like DRM or AGPGART stuff. DRI
and Xorg XAA/EXA drivers have no dependancy on the kernel beyond that.
It's fairly trivial to manage multiple versions of the Intel driver or have compiled a Mesa
tree and DRI stuff outside your distribution-provided stuff.
It's even possible to switch between multiple versions of DRI drivers within the same X
session. It just requires LD_LIBRARY_PATH tricks to point applications at a different path.
for example:
export LD_LIBRARY_PATH=/path/to/xc/xc/exports/lib:$LD_LIBRARY_PATH
export LIBGL_DRIVERS_DIR=/path/to/Mesa/lib
It's not that hard at all.
With the 2D drivers you just copy over the *_drv.so file, and keep backups of the originals so
you can go back if it breaks something.
Occasionally you'll run into kernel-level dependancies for a new texture memory management
change or something like that. But for the most part they can be compiled into modules.