On Sun, Sep 09, 2007 at 05:51:28PM -0400, Michel Salim wrote: > On 09/09/2007, Jonathan Underwood <jonathan.underwood@xxxxxxxxx> wrote: > > I thought that dkms had the ability to build an rpm and then install > > that. That would be the ideal solution. > > > Matt Domsch, who is (AFAIK) in charge of DKMS development, did not > mention that at all. There are several problems DKMS is designed to solve, and while clearly biased, I think it does so quite well. Dell honestly would not have been able to ship a product like RHEL, SLES, or Ubuntu without having a tool like DKMS available - which is why we wrote and continue to maintain it. We rarely change our factory images from the "gold" kernels of those products - the complete retesting required to do so makes it time-consuming and therefore expensive. We use DKMS to change individual kernel modules, with clear targeted changes that are easy to verify by code inspection and through runtime testing. We do this in cooperation with the developers at the distros, so the changes that are backported into a DKMS packaged module are then included in future distro updated kernels, which then eliminate the need for the DKMS packaged module. Gary added 'mkrpm', at the request of people within Red Hat, several years ago. One can argue that the RPM spec file template that has evolved over time could be done differently or better, and you'd have no argument from me. The kmod work from SLES and RHEL, while each are different spec templates, both try to solve the same problem - make DKMS produce a source RPM containing source code, which is built in a build system to produce binary RPMs. There are other spec file proposals, like Jef and others propose. Great! I haven't looked at all of them in detail, but with the 'mkrpm' and 'mkkmp' commands in DKMS, any of those spec file proposals should be usable by DKMS. I would want any proposal made to include shipping the source code in the RPM, such that DKMS can rebuild modules on the fly (provided gcc etc. are available). I find this one of the "killer features" of DKMS - it lets modules which are not presently "in the tree" get rebuilt whenever "the tree" gets updated. It isn't perfect, but it's a whole lot better than having no such solution. With the module versioning code I helped get into the kernel, DKMS recognizes when a module is now "in the tree", and of same or equal version to what is provided by a DKMSified package. DKMS then defers to the in-kernel module rather than updating from its own - exactly the behavior we want to encourage (get your code into upstream and therefore into the distros; use DKMS as a backport mechansim for specific fixes older kernels, or in rarer cases, for currently out-of-tree modules which are working to get into the tree). > No kernel developer has weighed in on that discussion, it seems. Ping? The Fedora kernel developers, from the comments I've gathered, all seem to prefer a) modules be upstream first, and b) in rare necessary instances (say, squashfs) they can patch modules into the Fedora kernel tree themselves. This works well for open source modules where you can attract a Fedora kernel developer's attention (e.g. bugzilla with a really good technical case and use case, but the bar is pretty high given that the code isn't upstream yet). Especially with Linus's comments of this past week [1] about the need to work harder to get currently out-of-tree modules cleaned up and into the upstream tree, if that comes to pass there will be less need for out-of-tree modules. And Fedora doesn't have an audience that freezes on a kernel version like RHEL or SLES do, so there's less need for DKMSified modules in the Fedora branded repositories. I say "less need", because there's still the case of open source, out-of-tree modules that one can't convince the kernel maintainers to accept, maybe because it needs wider audience testing. I used DKMS to produce a ppp_mppe module package exactly to address this (not included in Fedora, but posted on the pptpclient.sf.net web site)a. It was a short-lived package, a few months, while testers actively ran and found bugs, and provided me feedback, such that when the driver was proposed for mainline inclusion, I had many people to point to saying "it works for them", and none reporting bugs. It made mainline inclusion much easier. And then the package went away, its need eliminated - my goal all along. I'm OK with keeping kmods out of the official Fedora repositories. But I really like seeing people use DKMS in this last way, as a testing environment for code being prepared for upstream inclusion. [1] http://lwn.net/Articles/248195/ Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
