I'm trying to understand how the Linux kernel loads modules at runtime. Specifically, what mechanisms are used to locate the .ko files, resolve their dependencies, and insert them into the running kernel? How does the kernel keep track of which symbols are exported, and what happens if a required symbol is missing? Any clear overview or resources would help. What do you think?
How does the Linux kernel handle module loading and dependencies?
👁️ 91 görüntüleme💬 1 cevap❤️ 0 beğeni
1 Cevap
When the kernel needs a module it first asks **modprobe** (or insmod for a raw insert). Modprobe walks the module directory tree (usually /lib/modules/$(uname ‑r)/) and uses the **modules.dep** file that was generated by `depmod`. That file is essentially a pre‑computed dependency graph: each .ko lists the other .ko files it needs, based on the symbols it references. So the locator is just a filesystem lookup plus the dependency cache; you can also override it with `modprobe -d /my/alt/path` or by editing **modules.alias** for alias handling.
Once the right .ko is found, the kernel’s `init_module` syscall hands the binary over to the module loader. The loader parses the ELF sections, extracts the **__ksymtab** and **__ksymtab_gpl** tables, and registers all exported symbols in the kernel’s global symbol hash. When a new module is being linked, the loader walks its undefined symbols, looks them up in that hash, and patches the relocation entries. If any required symbol isn’t present, the load fails with `-ENOENT` and you’ll see an error like “Unknown symbol <sym> (err -2)”. In practice you’ll get a clear message from `dmesg` and `modprobe` will abort.
From a debugging perspective, I always keep **/proc/kallsyms** handy – it’s a live dump of everything the kernel currently exports (including GPL‑only symbols). If you suspect a missing dependency, `modinfo -F depends <module>.ko` shows what the module expects, and `grep <sym> /proc/kallsyms` tells you if it’s actually available. When I ran into a version mismatch (the module was built against a different kernel config), the missing symbols were usually hidden behind CONFIG_* options. Rebuilding the module against the exact running kernel headers (or enabling the needed config flags) solved it.
A quick workflow that works for me:
1. Run `depmod -a` after installing any new .ko to refresh **modules.dep**.
2. Use `modprobe -v <mod>` to see the exact load order and any auto‑loaded dependencies.
3. If you hit “unknown symbol”, check `/proc/kallsyms` and the module’s `modinfo` output, then either load the missing module first or rebuild with the correct headers.
That’s the whole chain from file locate → dependency resolve → symbol linking, and the kernel’s built‑in hash table is what guarantees the symbols are either found or the load aborts cleanly.