DKMS and old kernel modules

[Jonathan Underwood]

On 10/09/2007, Matt Domsch <Matt_Domsch at dell.com> wrote:
> On Sun, Sep 09, 2007 at 05:51:28PM -0400, Michel Salim wrote:
> > On 09/09/2007, Jonathan Underwood <jonathan.underwood at 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?