[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: DKMS - Dynamic Kernel Module Support

please keep also the upstream author CCed :)

On Thu, 11 Sep 2008 15:00:14 +0000, Tzafrir Cohen wrote:

> 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.

That's why I'm trying to introduce DKMS!

> 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?

The short answer: probably not, but DKMS is not "following this way".

The long answer: here's the "problem" -- currently m-a just generates .deb
packages, which are handled by apt-get, dpkg and the such.
DKMS would instead handle all that by itself -- and to remove a module, you'd
need to do something like:

# dkms remove -m <module> [-v <version] [...<lots of other options>...]

This is, obviously, to guarantee cross-vendor compatibility. It can't generate
a vendor-specific package (be it .deb, .rpm or any other else), it just has to
do that by itself.

(even if there's the "mkdeb" command to dkms [i.e. "dkms mkdeb"] which...
well... generates a .deb.)

> > 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.

Sure, but I believe Mario intended "trasparently adding modules" -- i.e.
modules you forgot to update&install would automatically be handled by DKMS on
boot. Mario, am I wrong?

> > *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')

I believe this is a bug in the zaptel init scripts... shouldn't they check
whether they can be unloaded? Is there a --force option? But this is another
story :)

> > 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.

Googling for "dkms zaptel" gives some results, but most for Mandriva. I believe
some effort should be made to make a "central repository" (like for
autopackage, and for other similar "cross-vendor" projects) where to store
"vanilla" tarballs. Mario, do you know of any "central source" currently

> 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.

I'm sorry I haven't all that experience with DKMS to clearly confirm this.
Mario, can you confirm?

> > 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.

Me neither -- oh well, I'm not into the "enterprise" world at all!


 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

Attachment: signature.asc
Description: PGP signature

Reply to: