David Paleino wrote: > 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? > Correct, the service will simply compile the modules for you. rmmod/modprobe/udev control of the modules is outside the scope of what it handles. > > 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 :) > > For the case that was mentioned for asterisk holding zaptel devices open, that's not what DKMS is here to solve. DKMS is one step up the chain producing the modules that are needed 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? > The original plan for DKMS built modules was not to provide a central repository for these modules. They *should* all end up in the kernel in the long term. In cases that a vendor is providing a driver to be used on a variety of distributions, they should be hosting it on their own webspace generally. Another usecase is putting it directly into distributions that are most interesting to the vendor, but this is significantly more work. This is how a few drivers in Ubuntu are handled at this point. > > > I'm sorry I haven't all that experience with DKMS to clearly confirm this. > Mario, can you confirm? > > So if there were issues between the interaction of the Zaptel userspace init script and DKMS producing the modules to be used, an upstart style script will be needed so that Zaptel's userspace script doesn't get launched unless DKMS is finished.
-- Mario Limonciello *Dell | Linux Engineering* [EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
