https://wiki.archlinux.org/api.php?action=feedcontributions&user=Egon.geerardyn&feedformat=atomArchWiki - User contributions [en]2024-03-29T12:26:51ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Dynamic_Kernel_Module_Support&diff=225326Dynamic Kernel Module Support2012-09-26T18:16:53Z<p>Egon.geerardyn: /* Package name */ it makes no sense to prefix non-DKMS packages with dkms-</p>
<hr />
<div>[[Category:Kernel]]<br />
{{stub}}<br />
<br />
[[Wikipedia:Dynamic_Kernel_Module_Support|Dynamic Kernel Module Support]] allows one to compile and install kernel modules without recompiling the entire kernel.<br />
<br />
== Installation ==<br />
<br />
Install package {{pkg|dkms}} in the [[Official Repositories]].<br />
<br />
==Guidelines==<br />
Here are some guidelines to follow.<br />
<br />
===Package name===<br />
Since it is likely that the DKMS package duplicates a non-DKMS package, I am prefixing the DKMS-enabled package with "dkms-".<br />
If I were to package something that didn't have a non-DKMS counterpart, I would still use the "dkms-" prefix.<br />
<br />
===Where should source go?===<br />
DKMS by default uses ''/usr/src/'', but [namcap] complains that is a non-standard directory. (Even though the FHS reference namcap uses states that ''/usr/src'' is "optional".<br />
One could place the source in ''/opt/<package>'' and then sym-link it (which is what some non-DKMS packages do.)<br />
<br />
Currently, I am just putting the source in ''/usr/src/<package>'' under the "true package name" (which is usually the PKGBUILD $_pkgname variable, which is the $pkgname minus the "dkms-" prefix)<br />
<br />
===Where should patches be applied?===<br />
One could patch the source either in the PKGBUILD or through DKMS.<br />
Since non-DKMS packages patch from the PKGBUILD, and to keep the DKMS PKGBUILD as close to the non-DKMS version, I am patching in the PKGBUILD.<br />
<br />
===Should the .install file attempt to modprobe/rmmod the module?===<br />
I don't know which way to go on this. I like the idea of the module coming up once the package is installed, but based on what I have seen, most packages do '''not''' do this.<br />
Right<br />
<br />
===How to create .install / dkms.conf files?===<br />
Try to avoid updating things like version numbers in multiple files. <br />
Try to avoid cluttering up PKGBUILDs/.install files with DKMS-specific stuff. (This keeps them closer to the non-DKMS files).<br />
<br />
I've just started using a simple bash script to create the ''dkms.conf'' file and to replace text in an ''install.template'' file. This leads to much cleaner and easier to understand files.<br />
<br />
===DKMS breaks the ABS===<br />
Sort of, yes. The problem is that the resulting modules don't belong to the package, so pacman can't track or report on them.<br />
<br />
I don't think that's a show-stopper, but it probably puts DKMS out on the fringe a bit.<br />
There is some talk about pacman adding similar support through pacman hooks. [https://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks].<br />
I think you could might "fake" the ownership, by installing the module as normal (or even a "dummy" file) and just letting DKMS overwrite it. <br />
<br />
===namcap issues===<br />
As mentioned earlier, namcap complains if you put source in ''/usr/src''.<br />
Also, namcap can not detect that dkms is a dependency. (I guess maybe it's not technically a dependency, but...)<br />
<br />
Basically, take the dependencies of the non-DKMS version, add 'dkms' and remove 'linux-headers' (since dkms optdepends on that)<br />
<br />
==See Also==<br />
*[http://linux.dell.com/dkms/manpage.html Dell's DKMS man page] Official site.<br />
*[http://manpages.ubuntu.com/manpages/karmic/man8/dkms.8.html Ubuntu's DKMS man page] (Documents some officially un-documented bits.)<br />
*[http://www.linuxjournal.com/article/6896 Exploring Dynamic Kernel Module Support]</div>Egon.geerardyn