Some time ago Dell introduced the dynamic kernel module support (DKMS) to automatically recompile kernel modules during kernel updates. Now the first average-user apps supporting dkms emerged: VirtualBox and ATI graphics drivers.
The Dynamic Kernel Module Support (DKMS) was introduced around 2003 as a way for Dell’s customers to automatically and sanely recompile kernel modules after kernel updates. This was and is necessary even for small kernel updates and for every module which is not part of the kernel. Previously to DKMS the customers had to use their own scripts or recompile the modules manually after each update.
While today many kernel modules are shipped in the vanilla kernel and some missing ones (like uvc) are added later on by the distributors, some kernel modules are not shipped yet and might never be shipped with the mainline kernel. Common examples are proprietary graphic driver modules, modules written in C++ or drivers in an experimental state.
Now, several years after DKMS was first introduced to the world it finally starts to appear at different places: the newest ATI graphics driver is shipped with DKMS support now. Also VirtualBox (which has a C++ written kernel module afaik) included DKMS support with version 1.6.
The advantage is now that, as soon as a kernel update comes down the pipe, the modules are automatically recompiled – there is no need to take care of that on your own. It is also needless to provide recompiled modules in the repositories: these usually lack behind the main kernel updates (and can also be a bit problematic due to licence reasons in some cases) which can be very annoying for the user. With DKMS the module is compiled on the user side and is available directly after the new kernel was installed.
The technical heart of DKMS is the dkms command. It is used to build, install, manage and also remove kernel modules. An article at linuxjournal gives a detailed insight into the inner workings of dkms. To check if a given system already utilizes dkms, a status query can be done:
# dkms status vboxdrv, 1.6.0, 2.6.24.5-85.fc8, i686: installed vboxdrv, 1.6.0, 2.6.24.7-92.fc8, i686: installed
In this example the VirtualBox kernel module is managed by dkms, and the need to recompile the module after each kernel update is not existent anymore. Given that dkms is accepted by other projects as well the handling of external kernel modules will be much easier in the future.
Of course, DKMS needs to be included with the distribution, but that is the case for almost all bigger ones. Also, DKMS only works as long as the module can actually be recompiled with the new kernel. Especially graphics drivers might be a problem here. However, most distributions don’t update their kernel during a life cycle of a distribution version, so that shouldn’t be a problem for normal users. Also, the best solution for driver development and management is of course when to develop everything inside the vanilla kernel. But as mentioned above there are several exceptions where that is simply not possible.
/home/liquidat 
This is good news! However, DKMS has some significant non-technical disadvantages. If you are tracking kernel development, or even just a rapidly updated kernel like in Fedora or Ubuntu, there is a good chance that the actual ABI will change, and the automated DKMS rebuild will fail.
Having DKMS support also might discourage developers from doing the work of getting their modules into the upstream kernel where it belongs (except in the case of closed source drivers). Fedora in fact has the proposal that
DKMS be used only for “experimental” modules that need to be updated more frequently than the kernel:
http://fedoraproject.org/wiki/JefSpaleta/DKMSProposal
There is also a summary of the discussion in the “Kmods Clarified” section of Fedora Weekly News 99:
http://fedoraproject.org/wikinew/FWN/Issue99#Kmods_Clarified
Due to the MediaWiki migration, after Wednesday the link should become
http://fedoraproject.org/wiki/FWN/Issue99#Kmods_Clarified
Lastly, I’d like to state that DKMS has been an invaluable tool in getting updates RAID drivers from Dell which it what it was originally designed to do! (And they do push it upstream by the way, that just takes time.)
Joshua, the problem of the changing APIs was mentioned within the last paragraph: in such a case the driver cannot be compiled, and of course dkms is useless in such a case.
Also, I did of course state that dkms is only sub-optimal in cases where the driver can be included with the mainline kernel.
But for Fedora: I don’t think that Fedora should add dkms modules at all. That should be up to the developers (like VirtualBox). I prefer Fedora’s old position there: if it has to be shipped with Fedora, than include it with the kernel directly!
Mandriva uses DKMS for a few years now, but it also has two major disadvantages when using dkms on the end-user machine. First, you need the kernel sources (or at least a part of it) and the whole toolchain to compile/build programs which represents quite a lot of disk space and is almost useless as long as you’re not a developer. Second, everytime you install a new module, it has to be compiled which may seems acceptable for a high-end desktop machine, but for all other types, it’s making installing a new module a real pain. And it’s becoming worse if you need to update your kernel : all your modules have to be recompiled which takes an extensive amount of time.
Mandriva tried to address this issue by pre-compiling dkms packages for the most common kernels and falling back to uncompiled dkms packages (also known as dkms-source) when it’s impossible to use pre-compiled (aka dkms-biary) dkms packages.
yoho, the issues you mention do show that dkms can only used as an alternative if the modules are not part of the vanilla/distribution kernel. And that matches with my point that it is still the best to develop modules with the vanilla kernel instead of using dkms only. That would be stupid.