Hi,
I'm wondering how the version of DKMS in rawhide deals with old modules, when the kernel for which they were built is removed.
On F-7, with FreshRPMS' madwifi RPM (which uses DKMS), the old modules are left behind, which means /lib/modules accumulates junk files over time.
Not sure what the best solution is. Trigger a cleanup process in the DKMS initscript, which would operate if the kernel booted is not the same as at the previous boot?
(will Bugzilla this if people think it's a good idea)
Regards,
On So September 9 2007, Michel Salim wrote:
Not sure what the best solution is. Trigger a cleanup process in the DKMS initscript, which would operate if the kernel booted is not the same as at the previous boot?
Proposed is a trigger when an old kernel is removed.
(will Bugzilla this if people think it's a good idea)
It's alread there: https://bugzilla.redhat.com/show_bug.cgi?id=250377
Regards, Till
On 09/09/2007, Till Maas opensource@till.name wrote:
On So September 9 2007, Michel Salim wrote:
Not sure what the best solution is. Trigger a cleanup process in the DKMS initscript, which would operate if the kernel booted is not the same as at the previous boot?
Proposed is a trigger when an old kernel is removed.
(will Bugzilla this if people think it's a good idea)
It's alread there: https://bugzilla.redhat.com/show_bug.cgi?id=250377
I thought that dkms had the ability to build an rpm and then install that. That would be the ideal solution.
On 09/09/2007, Jonathan Underwood jonathan.underwood@gmail.com wrote:
On 09/09/2007, Till Maas opensource@till.name wrote:
On So September 9 2007, Michel Salim wrote:
Not sure what the best solution is. Trigger a cleanup process in the DKMS initscript, which would operate if the kernel booted is not the same as at the previous boot?
Proposed is a trigger when an old kernel is removed.
(will Bugzilla this if people think it's a good idea)
It's alread there: https://bugzilla.redhat.com/show_bug.cgi?id=250377
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.
No kernel developer has weighed in on that discussion, it seems. Ping?
On 09/09/2007, Michel Salim michel.sylvan@gmail.com wrote:
On 09/09/2007, Jonathan Underwood jonathan.underwood@gmail.com wrote:
On 09/09/2007, Till Maas opensource@till.name wrote:
On So September 9 2007, Michel Salim wrote:
Not sure what the best solution is. Trigger a cleanup process in the DKMS initscript, which would operate if the kernel booted is not the same as at the previous boot?
Proposed is a trigger when an old kernel is removed.
(will Bugzilla this if people think it's a good idea)
It's alread there: https://bugzilla.redhat.com/show_bug.cgi?id=250377
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.
Announcement of that capability goes back to 2004:
http://lists.atrpms.net/pipermail/atrpms-devel/2004-June/000259.html
On Sun, Sep 09, 2007 at 05:51:28PM -0400, Michel Salim wrote:
On 09/09/2007, Jonathan Underwood jonathan.underwood@gmail.com 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
On 10/09/2007, Matt Domsch Matt_Domsch@dell.com wrote:
On Sun, Sep 09, 2007 at 05:51:28PM -0400, Michel Salim wrote:
On 09/09/2007, Jonathan Underwood jonathan.underwood@gmail.com 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).
Ah, ok, I slightly misunderstood the use of mkrpm - I was under the impression that DKMS could build an rpm of the kernel module on the users machine (not in a repository buildsystem) and then install that. I.e. dkms, when it sees a new kernel on the users machine compiles the kernel module and packages at as an rpm and then installs it. Would that be implementable?
On Mon, Sep 10, 2007 at 03:16:23PM +0100, Jonathan Underwood wrote:
Ah, ok, I slightly misunderstood the use of mkrpm - I was under the impression that DKMS could build an rpm of the kernel module on the users machine (not in a repository buildsystem) and then install that. I.e. dkms, when it sees a new kernel on the users machine compiles the kernel module and packages at as an rpm and then installs it. Would that be implementable?
sure, it's just a matter of code. There's also the secondary problem of rpm being non-recursive. e.g. you'd have to do this from outside of a running rpm transaction, such as in the dkms_autoinstaller. DKMS couldn't do it from the proposed kernel package postinst hook that's called by the kernel RPM's %post, which is where you'd really want it to be called from.
I see dkms is now in fedora. Does this mean fedora now blesses it's use? I'd like to submit a package to use it.
Neal Becker wrote:
I see dkms is now in fedora. Does this mean fedora now blesses it's use? I'd like to submit a package to use it.
DKMS has been available in Fedora for a long time. The curent kernel modules guidelines doesn't use it and there is a proposal to get rid of separate kernel modules entirely and patch the kernel package directly if needed.
What is the module you are thinking of packaging?
Rahul
Rahul Sundaram wrote:
Neal Becker wrote:
I see dkms is now in fedora. Does this mean fedora now blesses it's use? I'd like to submit a package to use it.
DKMS has been available in Fedora for a long time. The curent kernel modules guidelines doesn't use it and there is a proposal to get rid of separate kernel modules entirely and patch the kernel package directly if needed.
What is the module you are thinking of packaging?
Rahul
I have sent a review request for blcr, Berkeley Linux Checkpoint Restart, which uses a kernel module.