Red Hat began supporting multi-arched driver disks in RHEL3. To force creation of a driver disk with arch information, specify -d redhat2 or if you specify multiple archictectures on the command-line and use -d redhat , DKMS will create a version 2 driver disk. By specifying -d redhat1 , you can force a version 1 driver disk image.
Note that redhat1 driver disks actually supported multiple architectures when the second arch was i386 and the kernel module was for the BOOT kernel. DKMS allows for this, and as such you can create a redhat1 style driver disk if the only other arch is i386 and the kernel name ends in BOOT.
See http://people.redhat.com/dledford for more information on the Red Hat driver disk standards and which files are necessary to make a driver disk.
For suse/UnitedLinux driver disks, there are no necessary additional files needed to construct the disk. However, for these distros, you must specify a -r release (eg. for suse 9.1, it would be -d suse -r 9.1).
By default the disk image it creates is 1440 (k) in size. This can be overridden by specifying a different --size #### which should should be given as a number in kilobytes divisible by 20.
For example, if you were to specify: -k kernel1 -k kernel2 -a i386 -k kernel3 -a i686 -a x86_64, DKMS would process this as: kernel1-i386, kernel2-i686, kernel3-x86_64.
If more than one is found, then the first one located (by preference indicated above) will be considered the "original_module". As well, all copies of the same-named module will be removed from your kernel tree and placed into /var/dkms/<module>/original_module/$kernelver/collisions so that they can be *manually* accessible later. DKMS will never actually do anything with the modules found underneath the /collisions directory, and they will be stored there until you manually delete them.
It is important to understand that many of the DKMS directives are arrays whose index values are tied together. These array associations can be considered families, and there are currently four such families of directive arrays. MAKE[#] and MAKE_MATCH[#] make up one family. PATCH[#] and PATCH_MATCH[#] make up the second family. The third and largest family consists of BUILT_MODULE_NAME[#], BUILT_MODULE_LOCATION[#], DEST_MODULE_NAME[#], DEST_MODULE_LOCATION[#], MODULES_CONF_ALIAS_TYPE[#], MODULES_CONF_OBSOLETES[#], MODULES_CONF_OBSOLETE_ONLY[#] and STRIP[#]. The fourth family is made up of only MODULES_CONF[#]. When indexing these arrays when creating your dkms.conf, each family should start at index value 0.
When the first module is installed upon the first kernel within the user's system, these entries in MODULES_CONF[#] are automatically added to /etc/modules.conf and if REMAKE_INITRD is specified, then the user's initrd is then remade. Subsequently, as your modules are then later removed from the user's system, until the final module/version combination is removed from the final kernel version, those references in modules.conf will remain. Once the last module/version combination is removed, those references are then removed.
As modules/versions are removed and initrds are remade, one of three things will happen if you have specified a MODULES_CONF_ALIAS_TYPE. If no original_module exists for that kernel, and no MODULES_CONF_OBSOLETES modules are found in that kernel too, the modules.conf alias references will temporarily be removed so that the initrd will successfully remake. Once the initrd is remade, however; those references are then automatically put back into modules.conf (unless you are removing the last instance of the module on the last kernel). However, if no original_module exists, but there is an OBSOLETE module found within that kernel, the alias reference is temporarily shifted to point to the OBSOLETE module so that the initrd can be remade. After it is remade, it then automatically puts back the alias reference (unless you are removing the last instance of the module on the last kernel). Lastly, if an original_module does exist for the kernel version, then modules.conf is not touched and all references persist (even if you are removing the last instance of the module on the last kernel).
Certain module installations might not only require adding references to modules.conf but also require removing conflicting references that might exist in the user's system. If this is the case, the MODULES_CONF_OBSOLETES[#] directive should be utilized to remove these references. More information about this directive can be found in the DKMS.CONF section of this man page.
Note that the end state of your modules.conf file very much depends on what kernel modules exist in the final kernel you remove your DKMS module from. This is an imperfect system caused by the fact that there is only one modules.conf file for every kernel on your system even though various kernels use different modules. In a perfect world, there would be one modules.conf file for every kernel (just like System.map).
Under the removal parts of the .spec file, all that needs to be called is a: dkms remove -m <module> -v <module-version> --all --rpm_safe_upgrade.
Use of the --rpm_safe_upgrade flag is imperative for making sure DKMS and RPM play nicely together in all scenarios of using the -Uvh flag with RPM to upgrade dkms enabled packages. It will only function if used during both the add and remove actions within the same RPM spec file. Its use makes sure that when upgrading between different releases of an RPM for the same <module-version>, DKMS does not do anything dumb (eg. it ensures a smooth upgrade from megaraid-2.09-5.noarch.rpm to megaraid-2.09-6.noarch.rpm).
It should be noted that a binary RPM which contains source is not a traditional practice. However, given the benefits of dkms it hopefully will become so. As the RPM created which utilizes dkms is not architecture specific, BuildArch: noarch should be specified in the .spec file to indicate that the package can work regardless of the system architecture. Also note that DKMS RPM upgrades (-U option) will automatically work because of the structure of the dkms tree.
Lastly, as a matter of convention, you should name your RPM: <package>-<version>-<rpm-version>dkms.noarch.rpm. The word dkms as part of the rpm-version signifies that the RPM works within the DKMS framework.
http://www.dell.com/downloads/global/power/1q04-ler.pdf
http://www.linuxjournal.com/article.php?sid=6896
Fedora Kernel Module Packages http://fedoraproject.org/wiki/Extras/KernelModuleProposal