kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting)

Jon Nettleton jon.nettleton at
Thu Sep 6 20:17:57 UTC 2007

On 9/6/07, Jeff Spaleta <jspaleta at> wrote:
> > > The complexity of separately-packaged kernel modules is unnecessary, and the users' problems with upgrading when the modules are not built synchronously with the kernel will no longer be possible.
> >
> > Same for dkms, as modules might break if the api changed.
> slightly less complex for dkms, because with dkms you don't have to
> deal with synchronously building the modules on the central build
> system. You package dkms source payloads and you let dkms attempt to
> build the modules locally as soon as a new kernel is installed. (dkms
> can even build rpms locally too to populate the rpmdb for tracking
> purposes)
> I think dkms works as a piece of technology as far as it can. The
> question really is, would providing dkms source payloads in Fedora
> help drive mainlining of kernel modules or does it discourage the
> necessary upstream discussions.  If providing dkms source payloads can
> help move things into upstream via feedback, then I'm all for it. But
> if its just going to be a way for people to get around the hard work
> of getting a module upstreamed, then I'm not for it. Which is why I'd
> be interested in setting an explicit expiration date for any dkms
> payload. I don't want to see this stuff linger as an external module
> indefinitely. I want to see progress towards adoption, and if there's
> no progress than we drop the dkms payload package.

The other piece that is needed for dkms is a yum plugin that can
detect when  kernel is updated and then run the dkms installer against
it.  This will allow three things to happen.   The first is that if a
module fails to compile then grubby can select the old kernel for
booting.  Secondly we can give some feedback to the user that the dkms
update failed.  Reboots after a kernel update won't take really long.


More information about the fedora-devel-list mailing list