Kernel Korner - Exploring Dynamic Kernel Module Support (DKMS)
With the first remove command, the module would be uninstalled. If this module/module-version were not installed on any other kernel, all traces of it would be removed from the DKMS tree. If, say, qla2x00/v6.04.00 also was installed on the 2.4.20-8bigmem kernel, the first remove command would leave it alone—it would remain intact in the DKMS tree. That would not be the case in the second example. It would uninstall all versions of the qla2x00/v6.04.00 module from all kernels and then completely expunge all references of qla2x00/v6.04.00 from the DKMS tree. Thus, remove is what cleans your DKMS tree.
DKMS also comes with a fully functional status command that returns information about what is currently located in your tree. If no parameters are set, it returns all information found. Logically, the specificity of information returned depends on which parameters are passed to your status command. Each status entry returned is of the state added, built or installed. If an original module has been saved, this information also is displayed. Some example status commands include:
dkms status dkms status -m qla2x00 dkms status -m qla2x00 -v v6.04.00 dkms status -k 2.4.20-8smp dkms status -m qla2x00 -v v6.04.00 -k 2.4.20-8smp
Another major feature of DKMS is the match command. The match command takes the configuration of DKMS-installed modules for one kernel and applies it to some other kernel. When the match completes, the same module/module-versions installed for one kernel are then installed on the other kernel. This is helpful when you are upgrading from one kernel to the next but want to keep the same DKMS modules in place for the new kernel. In the example:
dkms match --templatekernel 2.4.20-8smp ↪-k 2.4.20-9smp
--templatekernel is the match-er kernel from which the configuration is based. The -k kernel is the match-ee upon which the configuration is instated.
For systems management purposes, the commands mktarball and ldtarball also have been added to DKMS. These commands allow the user to make and load tarball archives, respectively, into the DKMS tree to facilitate using DKMS in deployments where many similar systems exist. This allows the system administrator to build modules on only one system. Rather than build the same module on every other system, the built binary can be applied directly to the other systems' DKMS tree. Specifically, mktarball creates a tarball of the source for a given module/module-version. It then archives the DKMS tree of every kernel version that has a module built for that module/module-version. Consider the example:
dkms mktarball -m qla2x00 -v v6.04.00 ↪-k 2.4.20-8smp,2.4.20-8
Depending on the -k kernel parameter, mktarball archives only certain binaries compiled for those kernels specified. If no kernel parameter is given, it archives all built module binaries for that module/module-version.
With ldtarball, DKMS simply parses the archive created with mktarball and applies whatever is found to that system's DKMS tree. This leaves all modules in the built state; the dkms install command then can be used to place the module binaries into the /lib/modules tree. Under normal operation, ldtarball does not overwrite any files that already exist in the system's DKMS tree. However, the archive can be forced over what is in the tree with the --force option. An example ldtarball:
dkms ldtarball --config ↪qla2x00-v6.04.00-kernel2.4.20-8smp.tar.gz
The last miscellaneous DKMS command is mkdriverdisk. As can be inferred from its name, mkdriverdisk takes the proper sources in your DKMS tree and creates a driver disk image that can provide updated drivers to Linux distribution installations. A sample mkdriverdisk might look like:
dkms mkdriverdisk -d redhat -m qla2x00 ↪-v v6.04.00 -k 2.4.20-8BOOT
Currently, the only supported distribution driver disk format is Red Hat, but this easily could expand with some help from the community in understanding driver disk requirements and formats on a per-distribution basis. For more information on the extra necessary files and their formats for DKMS to create Red Hat driver disks, see people.redhat.com/dledford. These files should be placed in your module source directory.
For maintainers of DKMS packages, the dkms.conf configuration file is the only auxiliary piece necessary to make your source tarball DKMS-ready. The format of the conf file is a successive list of shell variables sourced by DKMS when working with your package. For example, an excerpt from the qla2x00/v6.04.00 dkms.conf file:
MAKE="make all ↪INCLUDEDIR=/lib/modules/$kernelver/build/include" MAKE_smp="make SMP=1 all ↪INCLUDEDIR=/lib/modules/$kernelver/build/include" LOCATION="/kernel/drivers/addon/qla2200" REMAKE_INITRD="yes" MODULE_NAME="qla2200.o:qla2200_6x.o ↪qla2300.o:qla2300_6x.o" CLEAN="make clean" MODULES_CONF_ALIAS_TYPE="scsi_hostadapter" MODULES_CONF0="options scsi_mod ↪scsi_allow_ghost_devices=1"
|Jarvis, Please Lock the Front Door||Aug 31, 2016|
|Contrast Security's Contrast Enterprise||Aug 30, 2016|
|illusive networks' Deceptions Everywhere||Aug 29, 2016|
|Happy Birthday Linux||Aug 25, 2016|
|ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs||Aug 24, 2016|
|Updates from LinuxCon and ContainerCon, Toronto, August 2016||Aug 23, 2016|
- Jarvis, Please Lock the Front Door
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Contrast Security's Contrast Enterprise
- illusive networks' Deceptions Everywhere
- Happy Birthday Linux
- All about printf
- What I Wish I’d Known When I Was an Embedded Linux Newbie
- New Version of GParted
- Tech Tip: Really Simple HTTP Server with Python
- Blender for Visual Effects
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide