Plans for tomorrow's (20090529) FESCo meeting

Adam Williamson awilliam at redhat.com
Fri May 29 17:32:25 UTC 2009


On Fri, 2009-05-29 at 10:00 -0700, Toshio Kuratomi wrote:
> On 05/29/2009 09:47 AM, Adam Williamson wrote:
> 
> > There is a solution to this particular point, which it seems many who
> > use kmods don't seem to know about: akmods. Install the akmod for your
> > kmod, and if the pre-built kmod hasn't yet been updated when a new
> > kernel is released, the akmod handles the problem (it gets automatically
> > built at boot time).
> > 
> I've used dkms (the infrastructural package is in Fedora although
> there's no modules in fedora to use it).  It seems similar to what you
> describe.

Yes, vanilla DKMS works like this: it doesn't use pre-built binaries at
all, it's just about wrapping the module source up into a convenient
lump and having a bit of infrastructure to automatically compile it
during startup if appropriate.

> > That doesn't address all the other problems, of course, which are valid.
> > And it doesn't help if the new kernel happens to have changed the
> > interface somehow so the module source doesn't build any more. But there
> 
> This ended up being the blocker for my personal use.  For FESCo, I
> remember the requirement that gcc and other build tools were needed on
> an end user system was a big issue.

Yeah, that's the drawback to a pure source approach.

Mandriva took DKMS and hacked it up so that it creates both pre-built
binaries and 'source' packages (much like kmods and akmods in the kmod
system), so that if you have a system without the build chain things
will work as long as you're running a supported kernel and the updates
are in sync, but if you have the whole build chain, the 'source' DKMS
package covers you if you're running a different kernel or whatever. RPM
Fusion does much the same by providing both kmods and akmods.

It works for MDV but only with rather a lot of effort to ensure the
binary packages are kept in sync with kernel updates, and there were a
couple of releases where NVIDIA and ATI users suffered because this
wasn't the case, and they didn't have the kernel headers installed so
the DKMS 'source' packages didn't cover them.

NVIDIA and ATI are the major use case for MDV (and, frankly, for RPM
Fusion), so I came around to the view that it isn't really a good idea
to have kmods or DKMS in Fedora; the major use case for them doesn't
apply to Fedora and never will, and the other objections are pretty
valid for all the other cases for which DKMS / kmods can be used (either
this stuff should go straight into the kernel or we should not ship it).
And the pain involved in keeping the pre-built binaries in sync with the
kernel is significant.

On kmods vs. DKMS, I've now both built packages that use both and used
both on my own system. My perception is that DKMS is a much cleaner
system and saner to package, but kmod works slightly faster on boot. So
personally I prefer DKMS, but I may be biased (you usually prefer the
first implementation of anything you come across, as students of music
are aware :>)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net




More information about the fedora-devel-list mailing list