On 9/6/07, Jeff Spaleta <jspaleta@xxxxxxxxx> 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. Jon -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
