01 The Problem with insmod

In the previous article we loaded our stacked modules using insmod. It worked, but we had to do everything manually — load mod1 first, verify the symbol in /proc/kallsyms, then load mod2. If we forgot the order, the kernel threw an Unknown symbol error.

Now imagine you are working on a production driver with five or six stacked layers. Remembering the exact load sequence every time you reboot — or asking a tester to do it — is a recipe for mistakes. There has to be a better way, and there is: modprobe. modprobe for Kernel Modules

02 What is modprobe?

modprobe is the smart module loader. Unlike insmod which blindly tries to load a single .ko file, modprobe first consults a pre-built dependency map called modules.dep. It reads which other modules your target module depends on, loads those first in the correct order, and only then loads the module you actually asked for.

Think of it like a package manager — when you install a package, it automatically pulls in all required dependencies. modprobe does the same for kernel modules.

User types:  sudo modprobe mod2

           ┌────────────────────────────────────────┐
           │           modprobe                     │
           │  1. Open /lib/modules/$(uname -r)/     │
           │         modules.dep                    │
           │  2. Find entry for mod2.ko             │
           │  3. See: mod2.ko depends on mod1.ko    │
           │  4. Load mod1.ko first  (insmod)       │
           │  5. Load mod2.ko second (insmod)       │
           └────────────────────────────────────────┘

Result: both modules loaded, correct order, zero manual effort

03 How modprobe Knows Dependencies — modules.dep

The brain of modprobe is a file called modules.dep. It lives here on your system: so let us study how modprobe for Kernel Modules works

/lib/modules/$(uname -r)/modules.dep

# For example on kernel 6.8.0-90-generic:
/lib/modules/6.8.0-90-generic/modules.dep

The format of this file is straightforward. Each line looks like this:

# target_module: dependency1 dependency2 ...

kernel/drivers/misc/mod2.ko: kernel/drivers/misc/mod1.ko
kernel/drivers/misc/mod1.ko:

Read it like this: “To load mod2.ko, you must first load mod1.ko.” mod1.ko has no dependencies, so its line has nothing after the colon.

This file is not something you edit by hand. It is automatically generated by a tool called depmod, which we will look at in a moment. But first, we need to tell the kernel where our custom modules live — and that is where softlinks come in.

04 Creating Softlinks — Registering Your Module

Here is something important to understand: modprobe only looks for modules inside /lib/modules/$(uname -r)/. Your compiled .ko files are sitting in your home directory — modprobe has no idea they exist.

We have two options: copy the .ko files into the kernel module tree, or create a symbolic link (softlink) pointing from the module tree to our actual files. The softlink approach is much better during development because if you recompile the module, the link automatically points to the updated file — no copying needed.

What is a Softlink?

A softlink is like a shortcut. It is a special file that just points to another file located elsewhere. When the kernel reads the softlink, it transparently accesses the actual file at the target path.

/lib/modules/6.8.0-90-generic/kernel/drivers/misc/
  mod1.ko  ──────────────────────────────────────────►  /home/raviteja/.../mod1.ko
  mod2.ko  ──────────────────────────────────────────►  /home/raviteja/.../mod2.ko

The .ko files stay in your project folder.
modprobe reads through the link transparently.

Creating the Softlinks

The command to create a softlink is ln -s <source> <destination>. We place the link inside the misc driver directory of the running kernel’s module tree:

05 Running depmod -a — Rebuilding the Dependency Map

Now that the softlinks are in place, modprobe still does not know about our modules. Remember — modprobe reads from modules.dep, and that file has not been updated yet. We need to run depmod -a to regenerate it.

What does depmod -a actually do? It walks the entire /lib/modules/$(uname -r)/ directory, reads every .ko file, looks at their unresolved symbols and exported symbols, and figures out who depends on whom. The result is written back into modules.dep.

Let us verify that our modules appeared in the file:

viteja@raviteja-Inspiron-15-3511:/lib/modules/6.8.0-90-generic/kernel/drivers/misc$ grep mod /lib/modules/6.8.0-90-generic/modules.dep
kernel/drivers/misc/mod1.ko:
kernel/drivers/misc/mod2.ko: kernel/drivers/misc/mod1.ko

There it is. modules.dep now knows that mod2 depends on mod1. modprobe will use this information every time someone asks it to load mod2.

What is modules.dep.bin?

You might notice a modules.dep.bin file alongside modules.dep. This is just a binary-encoded version of the same information — modprobe reads the .bin version at runtime because it loads faster than parsing text. depmod -a generates both files automatically, so you never need to worry about .bin directly.

06 Loading with modprobe — Full Walkthrough

Everything is set up. Softlinks are created, depmod -a has run, and modules.dep has the dependency entry. Now watch how simple the load becomes:

1 Just load mod2 — do not load mod1 manually. Let modprobe figure it out.

2 Check lsmod — you will see both mod1 and mod2 are loaded, even though you only asked for mod2.

3 Check dmesg — both init functions ran, in the correct order: mod1 first, mod2 second.

What Just Happened Under the Hood?

When you ran sudo modprobe mod2, here is the exact sequence of events:

sudo modprobe mod2
       │
       ▼
┌─ modprobe reads modules.dep ──────────────────────┐
│  Found: mod2.ko depends on mod1.ko               │
└───────────────────────┬───────────────────────────┘
                        │
       ┌────────────────┴─────────────────┐
       ▼                                ▼
┌── Step 1 ──────────┐          ┌── Step 2 ──────────┐
│  insmod mod1.ko    │    then  │  insmod mod2.ko    │
│  (dependency)      │   ──────►│  (requested)       │
└────────────────────┘          └────────────────────┘

Both modules loaded. Correct order. Zero effort from you.

07 Removing Modules with modprobe -r

Just like loading, unloading with modprobe is also automatic. You only need to ask it to remove mod2, and it will unload both modules in the correct reverse order — mod2 first, then mod1.

08 insmod vs modprobe — When to Use Which

Both tools load kernel modules. Understanding when to reach for each one saves a lot of debugging time.

During your early development sessions — editing code, recompiling, testing a single module — insmod is perfectly fine and faster. Once your driver has dependencies and you want to test it more realistically or share it with someone else, switch to modprobe.

09 Common Mistakes and Fixes

10 Summary

Final summary: