2

I have a kernel module and I would like to distribute it (ie. package it).

I'd like to distribute it so that the user doesn't need to do anything other than yum/dnf install kmod-mymodule.

  • SRPM: The user must have to build the RPM on its machine then install the RPM. I can't put it in a yum repository
  • RPM: I have to build the RPM for all the majors and minors versions of RHEL.
  • DKMS: Might be the solution but it expects the user to know how to use dkms, not that transparent.

What the way to distribute a kernel module easily so that the user just needs to do yum install kmod-mymodule and it compiles the module for the specific machine?

If there is a distribution-agnostic solution, I'm all ears!

Improve this question
4
  • 1
    Is there a reason why you want to target only RPM-based distributions? Commented Nov 30, 2022 at 9:08
  • My clients are exclusively using RHEL distributions. I go to the most urgent. But if there is an distrib-agnostic solution, I'm all ears! (no discrimination here) Commented Nov 30, 2022 at 9:10
  • In the long term contributing the module to the kernel might be the easiest for both you and your client. Commented Nov 30, 2022 at 17:25
  • Not really, not for few customers for a very specific device. Commented Nov 30, 2022 at 19:26

1 Answer 1

Reset to default
5

Arguing for the most user-friendly way

RPM: I have to build the RPM for all the majors and minors versions of RHEL.

But that's probably the right way to go from the point of view of your client. Single packet, clean, instant, no dependencies, installation.

There's maybe 6 to 12 versions you need to cover – all with the same SRPM. You can upload that SRPM to your own project on Copr and let IBM pay for the electricity needed to build your modules, or you can just have a loop in a shell script that runs for config in /etc/mock/rhel+epel-{7,8,9}-{x86_64,aarch64}.cfg ; do mock --rebuild ${your SRPM here} -r ${config} ; done (you might need to adjust templates a bit in /etc/mock to give you your different RHEL minors).

Or instead of using mock to set up your isolated build environments you do it in your own containers, VMs, or whatever you have available on site.

Automating on-target RPM building.

You'll want to use akmods, so that your binary kernel module RPM automatically gets rebuilt every time the kernel is updated (and the first time it's installed).

That way, your users don't have to do anything but install an akmod package, which will depend on the kernel headers package, which gets updated alongside with the kernel automatically. It will also depend on the necessary build tools (a C compiler etc).

rpmfusion's Packaging Kernel Modules as akmods goes in (only a little) more detail. In the end, akmod is just a way to automate building your kmod RPM.

It's probably best to look at an example of that in action. The v4l2loopback-kmod package contains a third-party kernel module which adds video loopback capability to the Linux kernel's v4l2 camera infrastructure. You can find the spec, along with the rest of the packaging files, here.

Improve this answer
13
  • I need to dig a bit further but akmod seems to be the way to go. Thanks for the explanation! Commented Nov 30, 2022 at 10:10
  • 1
    @Alexis You don't actually need akmod if you specifically only care about RHEL(-likes), not something like Fedora. RHEL kernels have a stable kABI, so a module built for a particular major release stays compatible with any later kernel updates (the weak-modules mechanism takes care of that by symlinking the .ko into /lib/modules/*/weak-updates for all compatible kernels). Commented Nov 30, 2022 at 20:57
  • @TooTea ah thanks! In that case, really, you need to test your module anyway, go with the one-RPM-per-Distro-release method (my first heading) Commented Nov 30, 2022 at 21:01
  • 1
    @Alexis The authoritative source explaining this is behind a subscription wall. Those without access can infer what's in there from this release note, which says that starting with EL9 the kABI can actually change between minor releases (I didn't know that, haven't seen EL9 yet). But if your module happens to use internal symbols (ones not on the kABI stablelists), you're on your own (= need akmod). Commented Dec 1, 2022 at 9:11
  • 1
    @Alexis really, no matter which route you'll take, having an SRPM is the first step :) But it's also not very hard – in essence, writing a .spec file; see the v4l2loopback example I linked to as how such an SRPM can look like, and just remove all the "magicy" things that make it an akmod. Once you have an SRPM, all you need to do is use either a build service like copr to build it for your N distro versions of choice, or do that yourself using mock. Commented Dec 1, 2022 at 9:18

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.