Hi, 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 available? > 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! Kindly, David -- . ''`. 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