Re: RFC: DKMS - Dynamic Kernel Module Support
Hi,
I have experince mostly with the out-of-tree module Zaptel.
I'm personally happy with m-a. It works resonably well for me. Though I
appreciate the goal of cross-vendor compatibility.
Some comments:
On Thu, Sep 11, 2008 at 10:00:38AM +0200, David Paleino wrote:
> 1) It includes a kernel postinstall hook. This means that, the moment kernel
> headers get installed, your modules are automatically rebuilt.
Seems just as easy (or diffiuclt) to implement with module-assistant,
right?
Is it possible to generate a package at a package post-install hook?
>
> 2) It includes a boot time service to add modules for a running kernel provided
> headers are available.
Boot time service or install time reload? At install time it is not
always possible to reload modules silently.
Reboot is the easy way to get modules reloaded.
>
>
> *Usability & Maintainability*
>
> 3) You don't need to know much about what you are doing in order to install a
> package that uses DKMS. If you look at the kqemu-source package in Ubuntu, the
> moment you install it, it builds modules for your running kernel. As soon as
> you install a new kernel, it will build modules for that kernel too. Any old
> kernels that you have, modules will be built as soon as you boot into the
> kernel.
> Compare this to module-assistant. You have to install kqemu-source, and then
> manually run module assistant for every single kernel you need modules for.
I wonder how this can be done with zaptel. If you try to be
user-friendly and run '/etc/init.d/zaptel/unload' when installing
zaptel-modules-<current-kernel>' it'll eventually fail normally, because
Asterisk holds /dev/zap/pseudo open, and hence zaptel cannot be
unloaded.
(And this assumes that the application using it is 'asterisk')
> 5) Interoperability with different distributions. DKMS tarballs can be used on
> RHEL, SuSE, Ubuntu, or Debian. If there are different kernels, patches can be
> included in the DKMS tarball to enable support on different kernel releases.
OK. As a test case, please provide a DKMS for zaptel. I know one was
made for Mandriva. I looked into it a while ago because I thought DKMS
is such a grand idea. And I recall I bumped into many practical issues I
had to overcome myself. I think that this was mainly to do with the fact
that Zaptel is both userspace and kernek.
>
> 6) Acceptance in enterprise solutions. Both Redhat & Novell support DKMS as a
> solution for OEMs to provide kernel modules that won't be maintained in the
> upstream tree for the foreseeable future.
IIRC Fedora has a policy for Kernel packages which is *not* DKMS. But I
don't follow Fedora/RH closely.
--
Tzafrir Cohen | tzafrir@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
tzafrir@cohens.org.il | | best
ICQ# 16849754 | | friend
Reply to: