kernel modules/kmods/dkms (Re: Plan for tomorrows (20070906) FESCO meeting)
jon.nettleton at gmail.com
Thu Sep 6 20:17:57 UTC 2007
On 9/6/07, Jeff Spaleta <jspaleta at gmail.com> 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
> 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