DKMS and old kernel modules

[Matt Domsch]

On Sun, Sep 09, 2007 at 05:51:28PM -0400, Michel Salim wrote:
> On 09/09/2007, Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
> > I thought that dkms had the ability to build an rpm and then install
> > that. That would be the ideal solution.
> >
> Matt Domsch, who is (AFAIK) in charge of DKMS development, did not
> mention that at all.

There are several problems DKMS is designed to solve, and while
clearly biased,  I think it does so quite well.  Dell honestly would
not have been able to ship a product like RHEL, SLES, or Ubuntu
without having a tool like DKMS available - which is why we wrote and
continue to maintain it.  We rarely change our factory images from the
"gold" kernels of those products - the complete retesting required to
do so makes it time-consuming and therefore expensive.  We use DKMS to
change individual kernel modules, with clear targeted changes that are
easy to verify by code inspection and through runtime testing.  We do
this in cooperation with the developers at the distros, so the changes
that are backported into a DKMS packaged module are then included in future
distro updated kernels, which then eliminate the need for the DKMS
packaged module.

Gary added 'mkrpm', at the request of people within Red Hat, several
years ago.  One can argue that the RPM spec file template that has
evolved over time could be done differently or better, and you'd have
no argument from me.  The kmod work from SLES and RHEL, while each are
different spec templates, both try to solve the same problem - make
DKMS produce a source RPM containing source code, which is built in a
build system to produce binary RPMs.

There are other spec file proposals, like Jef and others propose.
Great!  I haven't looked at all of them in detail, but with the
'mkrpm' and 'mkkmp' commands in DKMS, any of those spec file
proposals should be usable by DKMS.

I would want any proposal made to include shipping the source code in
the RPM, such that DKMS can rebuild modules on the fly (provided gcc
etc. are available).  I find this one of the "killer features" of DKMS
- it lets modules which are not presently "in the tree" get rebuilt
whenever "the tree" gets updated.  It isn't perfect, but it's a whole
lot better than having no such solution.  With the module versioning
code I helped get into the kernel, DKMS recognizes when a module is
now "in the tree", and of same or equal version to what is provided by
a DKMSified package.  DKMS then defers to the in-kernel module rather
than updating from its own - exactly the behavior we want to
encourage (get your code into upstream and therefore into the distros;
use DKMS as a backport mechansim for specific fixes older kernels, or
in rarer cases, for currently out-of-tree modules which are working to
get into the tree).

> No kernel developer has weighed in on that discussion, it seems. Ping?

The Fedora kernel developers, from the comments I've gathered, all
seem to prefer a) modules be upstream first, and b) in rare necessary
instances (say, squashfs) they can patch modules into the Fedora
kernel tree themselves.  This works well for open source modules where
you can attract a Fedora kernel developer's attention (e.g. bugzilla
with a really good technical case and use case, but the bar is pretty
high given that the code isn't upstream yet).

Especially with Linus's comments of this past week [1] about the need
to work harder to get currently out-of-tree modules cleaned up and
into the upstream tree, if that comes to pass there will be less need
for out-of-tree modules.  And Fedora doesn't have an audience that
freezes on a kernel version like RHEL or SLES do, so there's less need
for DKMSified modules in the Fedora branded repositories.

I say "less need", because there's still the case of open source,
out-of-tree modules that one can't convince the kernel maintainers to
accept, maybe because it needs wider audience testing.  I used DKMS to
produce a ppp_mppe module package exactly to address this (not
included in Fedora, but posted on the pptpclient.sf.net web site)a.
It was a short-lived package, a few months, while testers actively ran
and found bugs, and provided me feedback, such that when the driver
was proposed for mainline inclusion, I had many people to point to
saying "it works for them", and none reporting bugs.  It made mainline
inclusion much easier.  And then the package went away, its need
eliminated - my goal all along.

I'm OK with keeping kmods out of the official Fedora repositories.
But I really like seeing people use DKMS in this last way, as a
testing environment for code being prepared for upstream inclusion.


[1] http://lwn.net/Articles/248195/

Thanks,
Matt

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux