DKMS is a framework where device driver source can reside outside the kernel
source tree so that it is very easy to rebuild modules as you upgrade
kernels. This allows Linux vendors to provide driver drops without having to
wait for new kernel releases (as a stopgap before the code can make it back
into the kernel), while also taking out the guesswork for customers
attempting to recompile modules for new kernels.
For veteran Linux users it also provides some advantages since a separate
framework for driver drops will remove kernel releases as a blocking
mechanism for distributing code. Instead, driver development should speed up
as this separate module source tree will allow quicker testing cycles
meaning better tested code can later be pushed back into the kernel at a
more rapid pace. Its also nice for developers and maintainers as DKMS only
requires a source tarball in conjunction with a small configuration file in
order to function correctly.
The latest DKMS version is available at http://www.lerhaupt.com/dkms/. It
is licensed under the GPL. You can also find a sample DKMS enabled QLogic
RPM to show you how it all works (or, a mocked-up tarball if you don't like
RPMs). If you use the sample RPM, you'll have to install it with --nodeps as
it requires the DKMS RPM to be installed (which I haven't provided).
===Using DKMS===
DKMS is one bash executable that supports 7 sub-actions: add, build,
install, uninstall, remove, status and match.
add: Adds an entry into the DKMS tree for later builds. It requires that
source be located in /usr/src/<module>-<module-version>/ as well as the
location of a properly formatted dkms.conf file (each dkms.conf is module
specific and is the configuration file that tells DKMS how to build and
where to install your module).
build: Builds your module but stops short of installing it. The resultant
.o files are stored in the DMKS tree.
install: Installs the module in the LOCATION specified in dkms.conf.
uninstall: Uninstalls the module and replaces it with whatever original
module was found during install (returns your module to the "built" state).
remove: Uninstalls and expunges all references of your module from the DKMS
tree.
status: Displays the current state (added, built, installed) of modules
within the DMKS tree as well as whether any original modules have been saved
for uninstallation purposes.
match: Allows you to take the configuration of DKMS installed modules for
one kernel and apply this config to some other kernel. This is helpful when
upgrading kernels where you would like to continue using your DKMS modules
instead of certain kernel modules.
Check out the man page for more details.
Gary Lerhaupt
Linux Development
Dell Computer Corporation
I wanted to post a follow-up as I have seen only a few downloads of DKMS
since my original posting and also given that the Linux Development Group
here at Dell is very interested in feedback from the community. The problem
of chasing kernel drops is a very real issue for Linux solution providers.
With our constant work with new hardware and large deployments involving
many customers, at times we simply cannot afford to wait for functional
drivers in the kernel. This is especially true for the discovery and
resolution of high severity issues. At the same time, we cannot just hand
updated source tarballs to our customers and expect that to be an
appropriate customer experience. Further, it is just not feasible for us to
continue to produce kernel specific module RPMs for every kernel that we
support for every module that we support.
What is needed instead is a framework that can hold module source and can
recompile that source directly on user's systems for whichever kernel they
are running. As well, this entire process must be non-painful. We believe
that DKMS is this solution and we'd like to know if you agree and how it can
be improved.
Lastly, as I realize some might take a *don't care* approach to such a
problem given their personal Linux comfort level, I'd like to reiterate from
my previous post how such a framework could possibly yield benefits to the
entire process of Linux development. We at Dell are very committed to
merging code into the kernel, and if a separate framework to deploy (and
test) module source existed apart from the kernel, we envision both an
improvement in the speed and quality of driver development that can later be
pushed back into the kernel.
So, at your convenience we invite you to give DKMS a whirl (and to try out
the sample QLogic driver included for the full experience). Thanks.
Gary Lerhaupt
> -----Original Message-----
> From: Lerhaupt, Gary
> Sent: Friday, February 28, 2003 12:02 PM
> To: '[email protected]'
> Subject: [ANNOUNCE] DKMS: Dynamic Kernel Module Support
>
>
> DKMS is a framework where device driver source can reside
> outside the kernel source tree so that it is very easy to
> rebuild modules as you upgrade kernels. This allows Linux
> vendors to provide driver drops without having to wait for
> new kernel releases (as a stopgap before the code can make it
> back into the kernel), while also taking out the guesswork
> for customers attempting to recompile modules for new kernels.
>
> For veteran Linux users it also provides some advantages
> since a separate framework for driver drops will remove
> kernel releases as a blocking mechanism for distributing
> code. Instead, driver development should speed up as this
> separate module source tree will allow quicker testing cycles
> meaning better tested code can later be pushed back into the
> kernel at a more rapid pace. Its also nice for developers and
> maintainers as DKMS only requires a source tarball in
> conjunction with a small configuration file in order to
> function correctly.
>
> The latest DKMS version is available at
> http://www.lerhaupt.com/dkms/. It is licensed under the GPL.
> You can also find a sample DKMS enabled QLogic RPM to show
> you how it all works (or, a mocked-up tarball if you don't
> like RPMs). If you use the sample RPM, you'll have to install
> it with --nodeps as it requires the DKMS RPM to be installed
> (which I haven't provided).
>
> ===Using DKMS===
>
> DKMS is one bash executable that supports 7 sub-actions: add,
> build, install, uninstall, remove, status and match.
>
> add: Adds an entry into the DKMS tree for later builds. It
> requires that source be located in
> /usr/src/<module>-<module-version>/ as well as the location
> of a properly formatted dkms.conf file (each dkms.conf is
> module specific and is the configuration file that tells DKMS
> how to build and where to install your module).
>
> build: Builds your module but stops short of installing it.
> The resultant .o files are stored in the DMKS tree.
>
> install: Installs the module in the LOCATION specified in dkms.conf.
>
> uninstall: Uninstalls the module and replaces it with
> whatever original module was found during install (returns
> your module to the "built" state).
>
> remove: Uninstalls and expunges all references of your module
> from the DKMS tree.
>
> status: Displays the current state (added, built, installed)
> of modules within the DMKS tree as well as whether any
> original modules have been saved for uninstallation purposes.
>
> match: Allows you to take the configuration of DKMS installed
> modules for one kernel and apply this config to some other
> kernel. This is helpful when upgrading kernels where you
> would like to continue using your DKMS modules instead of
> certain kernel modules.
>
> Check out the man page for more details.
>
> Gary Lerhaupt
> Linux Development
> Dell Computer Corporation
>
On Mon, Mar 03, 2003 at 11:07:03AM -0600, Lerhaupt, Gary wrote:
> I wanted to post a follow-up as I have seen only a few downloads of DKMS
> since my original posting and also given that the Linux Development Group
> here at Dell is very interested in feedback from the community.
Hi Gary.
I have made a brief look at the shell script.
It assume .o for modules, which is not true for 2.5.
When building a module it simply executes $MAKE - which is plain wrong.
As have been discussed in several threads you cannot reliably track
changes in CFLAGS etc. without utilising the kbuild infrastructure.
DKMS is also highly connected to the usage of /lib/modules/...
and naming of config files. It looks to me as it is very distribution
specic.
Sam
> It assume .o for modules, which is not true for 2.5.
>
> When building a module it simply executes $MAKE - which is
> plain wrong.
> As have been discussed in several threads you cannot reliably track
> changes in CFLAGS etc. without utilising the kbuild infrastructure.
>
I will take up your suggestion and remove the assumptions that modules end
with .o. I should note that we don't see 2.6 making it into production
environments within the next year so my focus has been solely on 2.4 at this
point. Though, the kbuild infrastructure will actually mesh nicely with
DKMS as it will simplify the mess of makefiles that it has to deal with. As
for $MAKE, I believe there is some confusion here. $MAKE comes from
sourcing in the dkms.conf file which is required for each module in DKMS.
One of the directives in dkms.conf must be a MAKE which is the specific make
command needed to build your module. So $MAKE should represent the right
thing to do for the module in question.
> DKMS is also highly connected to the usage of /lib/modules/...
> and naming of config files. It looks to me as it is very distribution
> specic.
DKMS is very intertwined with /lib/modules as this is where it installs
modules. I was not aware that this was distro specific. As for the kernel
config files, you are correct. By default it does assume Red Hat's distro
specific scheme, but when building your module, you can pass a --config
option and specify the alternate path for your .config if it does not follow
this scheme. I hope this clears this up.
Gary
I've updated DKMS and posted it: http://www.lerhaupt.com/dkms/
ChangeBlog can be found at: http://www.lerhaupt.com/foo/archives/000027.html
Here's a copy of the changeblog:
* I added patching support in dkms.conf. You can now specify
PATCH0=<patch_filename>, PATCH1=..., etc. in your dkms.conf and the patches
will be applied in numerical order to your source each time before it
builds. All patches are expected to be in -p1 format and should be installed
into the /usr/src/<module>-<module-version>/patches/ directory.
* With patching support also comes kernel specific patches. These should be
entered in the form of PATCH_<kernel-regexp> in dkms.conf. If the
<kernel-regexp> matches to the kernel you are currently trying to build a
module for, then this patch will be applied. All kernel specific patches are
applied after generic patches.
* All module builds now occur in the directory
/var/dkms/<module>/<module-version>/build/. Before each build, the source is
copied into this directory for /usr/src/<module>-<module-version>/. If a
build succeeds, then this directory is emptied after the build. However, if
a build fails or if patches fail to apply, then this directory is left with
the source in it so that further troubleshooting can be done.
* There is no longer a limit to how many MODULES_CONF entries can be placed
in dkms.conf (used to be a 5 entry limit). As well, the format was changed
from MODULES_CONF_<#>=... to just MODULES_CONF<#>=...
* DKMS no longer sources in /etc/init.d/functions as this is Red Hat
specific and was not utilized anyway.
* Modules are no longer assumed to end with .o. This means the explicit
built name of your module must be specified in dkms.conf.
> -----Original Message-----
> From: Lerhaupt, Gary
> Sent: Monday, March 03, 2003 11:07 AM
> To: '[email protected]'
> Subject: RE: [ANNOUNCE] DKMS: Dynamic Kernel Module Support
>
>
> I wanted to post a follow-up as I have seen only a few
> downloads of DKMS since my original posting and also given
> that the Linux Development Group here at Dell is very
> interested in feedback from the community. The problem of
> chasing kernel drops is a very real issue for Linux solution
> providers. With our constant work with new hardware and
> large deployments involving many customers, at times we
> simply cannot afford to wait for functional drivers in the
> kernel. This is especially true for the discovery and
> resolution of high severity issues. At the same time, we
> cannot just hand updated source tarballs to our customers and
> expect that to be an appropriate customer experience.
> Further, it is just not feasible for us to continue to
> produce kernel specific module RPMs for every kernel that we
> support for every module that we support.
>
> What is needed instead is a framework that can hold module
> source and can recompile that source directly on user's
> systems for whichever kernel they are running. As well, this
> entire process must be non-painful. We believe that DKMS is
> this solution and we'd like to know if you agree and how it
> can be improved.
>
> Lastly, as I realize some might take a *don't care* approach
> to such a problem given their personal Linux comfort level,
> I'd like to reiterate from my previous post how such a
> framework could possibly yield benefits to the entire process
> of Linux development. We at Dell are very committed to
> merging code into the kernel, and if a separate framework to
> deploy (and test) module source existed apart from the
> kernel, we envision both an improvement in the speed and
> quality of driver development that can later be pushed back
> into the kernel.
>
> So, at your convenience we invite you to give DKMS a whirl
> (and to try out the sample QLogic driver included for the
> full experience). Thanks.
>
> Gary Lerhaupt
>
> > -----Original Message-----
> > From: Lerhaupt, Gary
> > Sent: Friday, February 28, 2003 12:02 PM
> > To: '[email protected]'
> > Subject: [ANNOUNCE] DKMS: Dynamic Kernel Module Support
> >
> >
> > DKMS is a framework where device driver source can reside
> > outside the kernel source tree so that it is very easy to
> > rebuild modules as you upgrade kernels. This allows Linux
> > vendors to provide driver drops without having to wait for
> > new kernel releases (as a stopgap before the code can make it
> > back into the kernel), while also taking out the guesswork
> > for customers attempting to recompile modules for new kernels.
> >
> > For veteran Linux users it also provides some advantages
> > since a separate framework for driver drops will remove
> > kernel releases as a blocking mechanism for distributing
> > code. Instead, driver development should speed up as this
> > separate module source tree will allow quicker testing cycles
> > meaning better tested code can later be pushed back into the
> > kernel at a more rapid pace. Its also nice for developers and
> > maintainers as DKMS only requires a source tarball in
> > conjunction with a small configuration file in order to
> > function correctly.
> >
> > The latest DKMS version is available at
> > http://www.lerhaupt.com/dkms/. It is licensed under the GPL.
> > You can also find a sample DKMS enabled QLogic RPM to show
> > you how it all works (or, a mocked-up tarball if you don't
> > like RPMs). If you use the sample RPM, you'll have to install
> > it with --nodeps as it requires the DKMS RPM to be installed
> > (which I haven't provided).
> >
> > ===Using DKMS===
> >
> > DKMS is one bash executable that supports 7 sub-actions: add,
> > build, install, uninstall, remove, status and match.
> >
> > add: Adds an entry into the DKMS tree for later builds. It
> > requires that source be located in
> > /usr/src/<module>-<module-version>/ as well as the location
> > of a properly formatted dkms.conf file (each dkms.conf is
> > module specific and is the configuration file that tells DKMS
> > how to build and where to install your module).
> >
> > build: Builds your module but stops short of installing it.
> > The resultant .o files are stored in the DMKS tree.
> >
> > install: Installs the module in the LOCATION specified in dkms.conf.
> >
> > uninstall: Uninstalls the module and replaces it with
> > whatever original module was found during install (returns
> > your module to the "built" state).
> >
> > remove: Uninstalls and expunges all references of your module
> > from the DKMS tree.
> >
> > status: Displays the current state (added, built, installed)
> > of modules within the DMKS tree as well as whether any
> > original modules have been saved for uninstallation purposes.
> >
> > match: Allows you to take the configuration of DKMS installed
> > modules for one kernel and apply this config to some other
> > kernel. This is helpful when upgrading kernels where you
> > would like to continue using your DKMS modules instead of
> > certain kernel modules.
> >
> > Check out the man page for more details.
> >
> > Gary Lerhaupt
> > Linux Development
> > Dell Computer Corporation
> >
>