撬开 Linux 内核的大门:手把手带你写一个内核模块

$ lsmod | head -10Module                  Size  Used byxt_conntrack           16384  1nf_conntrack          139264  1 xt_conntracknf_defrag_ipv6         24576  1 nf_conntrackiptable_filter         16384  1bpfilter               32768  0

#include <linux/module.h>#include <linux/kernel.h>static int __init hello_init(void){    printk(KERN_INFO "Hello, kernel world!\n");    return 0;}static void __exit hello_exit(void){    printk(KERN_INFO "Goodbye, kernel world!\n");}module_init(hello_init);module_exit(hello_exit);MODULE_LICENSE("GPL");MODULE_AUTHOR("A Curious Developer");MODULE_DESCRIPTION("My first kernel module");

就这些，30 行不到。但麻雀虽小，五脏俱全，我们来拆开看看每一行在干什么。

3.1 头文件

#include <linux/module.h>#include <linux/kernel.h>

注意：这是 内核头文件，不是 glibc 的头文件。你在内核态写代码，没有 printf，没有 malloc，没有 <stdio.h>。你用的每一个函数都是内核提供的。

module.h 给了你 module_init / module_exit 这些宏，kernel.h 给了你 printk。

3.2 入口函数

static int __init hello_init(void){    printk(KERN_INFO "Hello, kernel world!\n");    return 0;}

__init 是一个标记宏，告诉编译器：这个函数只在初始化阶段用一次，之后它的内存可以被回收。同样，后面会看到 __exit 用于卸载路径。

返回值 0 表示初始化成功。如果返回负数，模块加载会失败。

printk 是内核版的 printf，KERN_INFO 是日志级别。你可以用 dmesg 看到输出：

$ dmesg | tail -2[ 1234.567890] Hello, kernel world!

3.3 出口函数

static void __exit hello_exit(void){    printk(KERN_INFO "Goodbye, kernel world!\n");}

这会在你 rmmod 的时候被调用。如果你不定义出口函数，你的模块将无法被卸载——这是一个很容易踩的坑。

3.4 注册宏

module_init(hello_init);module_exit(hello_exit);

这两个宏在背后做了很多脏活：它们把函数指针塞进内核的一个特殊段（.init.text 和 .exit.text），内核在合适的时机会去那里找到并调用它们。你不用关心具体细节，但要知道：没有这两个宏，你的函数只是普通函数，内核根本不知道它们是入口和出口。

3.5 模块元信息

MODULE_LICENSE("GPL");MODULE_AUTHOR("...");MODULE_DESCRIPTION("...");

MODULE_LICENSE 不是装饰品。如果你不声明 GPL 兼容的许可证，你将无法使用内核导出的 GPL-only 符号——基本上就是自断双臂。另外编译时内核还会给你甩一个 warning，提醒你污染了内核。

四、怎么编译和运行

光有 .c 文件没用，你得有 Makefile。内核模块的编译用的是内核构建系统（kbuild），不能直接用 gcc。

# Makefileobj-m += hello.oall:	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modulesclean:	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

这里 obj-m 表示编译成模块（m = module）。-C 指向你当前运行内核的构建目录。M=$(PWD) 告诉 kbuild 你的模块源码在哪里。

然后：

$ make                          # 编译$ sudo insmod hello.ko          # 加载模块$ dmesg | tail -1               # 看看输出$ lsmod | grep hello            # 确认已加载$ sudo rmmod hello              # 卸载模块$ dmesg | tail -1               # 看离开时的输出

如果你看到 "Hello, kernel world!" 和 "Goodbye, kernel world!"——恭喜，你已经是一个内核模块开发者了。

小提示：用 modprobe 而不是 insmod 可以自动处理依赖。但 modprobe 只会从标准模块目录（/lib/modules/...）查找，你自己写的模块得先用 insmod。

五、模块的生命周期——不止是加载和卸载

一个内核模块从生到死，经历了这几个阶段：

编译(.ko) → 加载(insmod) → 初始化(init) → 运行中 → 卸载(exit) → 清理                │                            ↑                └── 符号解析 & 依赖检查 ──────┘

加载时，内核做的事比你想象的多：

1. ELF 解析
   ：.ko 文件本质上是一个可重定位的 ELF 目标文件（你可以用 file hello.ko 验证）
2. 符号解析
   ：把模块里调用的内核函数（如 printk）和实际的函数地址对上
3. 依赖检查
   ：如果模块依赖其他模块，先加载依赖
4. 许可证检查
   ：看你的 MODULE_LICENSE 是否允许访问你调用的那些符号
5. 调用 init 函数
6. 回收 __init 标记的内存

卸载时反过来：检查引用计数（没人用才让走），调用 exit 函数，释放内存。

有一个常见的坑：如果你的 init 函数里启动了内核线程或注册了回调，但 exit 函数里没有清理干净，卸载模块会导致 use-after-free 或 kernel panic。 记住：你申请的资源，每一份都要在 exit 里还回去。内核不会帮你做垃圾回收。

六、printk 的日志级别——你的调试利器

printk 有 8 个日志级别，从高到低：

默认情况下，只有级别小于 console_loglevel 的消息才会打印到控制台。你可以通过 /proc/sys/kernel/printk 查看和修改：

$ cat /proc/sys/kernel/printk7       4       1       7# 四个值：console_loglevel, default_level, minimum_console_level, default_console_loglevel

生产环境写模块，调试信息请用 KERN_DEBUG，别和系统日志混在一起。

七、带参数的内核模块——让模块更灵活

写死的模块不够实用，你可以在加载时传参数给它：

#include <linux/moduleparam.h>static int repeat = 1;module_param(repeat, int, 0644);MODULE_PARM_DESC(repeat, "How many times to say hello");static char *who = "world";module_param(who, charp, 0644);MODULE_PARM_DESC(who, "Who to greet");static int __init hello_init(void){    int i;    for (i = 0; i < repeat; i++)        printk(KERN_INFO "Hello, %s!\n", who);    return 0;}

加载时：

$ sudo insmod hello.ko repeat=5 who="kernel"

dmesg 会看到 5 行 "Hello, kernel!"。

module_param 的第三个参数是 sysfs 权限。设为 0644 意味着你可以通过 /sys/module/hello/parameters/repeat 在运行时读写这个参数。如果不需要运行时暴露，用 0000。

八、module_init 的底牌：内核 initcall 级别

前面我们一直在用 module_init() 和 module_exit()，但你可能不知道——module_init() 其实是一个幌子。

来看内核源码里 include/linux/module.h 的定义：

#define module_init(x)  __initcall(x);

而 __initcall 再展开：

#define __initcall(fn) device_initcall(fn)

真相是：module_init(my_init) 最终等价于 device_initcall(my_init)。

那 device_initcall 又是什么？这就引出了内核最核心的初始化机制——initcall 级别。

8.1 为什么需要分级别

内核启动时，要初始化的东西太多了：内存管理、调度器、中断控制器、定时器、文件系统、设备驱动……这些东西之间有严格的依赖关系。调度器没初始化完就去注册一个需要唤醒进程的驱动？直接翻车。

所以内核把初始化函数分了 8 个级别，从早到晚依次调用：

这就解释了为什么你在一个驱动模块里可以放心调用 kmalloc——因为内存管理在 core_initcall 级别就已经初始化完了，而你的驱动在 device_initcall 级别才起来。顺序保证了安全。

8.2 实现原理

内核不是用 switch-case 一个一个调函数——那样写死人。它用了一个很巧妙的方法：链接器脚本 + 函数指针数组。

每个级别的宏，本质上是把函数指针放到一个特定的 ELF section 里。比如：

#define core_initcall(fn)     __define_initcall(fn, 1)#define device_initcall(fn)  __define_initcall(fn, 6)

数字就是级别编号。编译完以后，不同级别的函数指针散落在 .init.data 的不同段里，启动时 do_initcalls() 按级别顺序遍历调用：

static void __init do_initcalls(void){    int level;    for (level = 0; level < ARRAY_SIZE(initcall_levels); level++)        do_initcall_level(level);}

所有 initcall 函数跑完之后，内核会释放掉整个 .init section 的内存（大概几百 KB），这些初始化代码只在启动时存在一次，之后就彻底消失了。

8.3 内置代码 vs 可加载模块

这里有一个容易搞混的地方。module_init() 的行为取决于你的代码是编译进内核还是编译成 .ko 模块：

• 编译进内核
  （obj-y）：module_init() → device_initcall()，函数在系统启动时自动调用
• 编译成模块
  （obj-m）：module_init() 变成一个别名，指向你的 init 函数，等 insmod 的时候才调用，调用时机完全由你决定

8.4 调试 initcall

如果你想知道每个 initcall 花了多少时间，加一个内核启动参数就行：

# 在 GRUB 的 cmdline 里加上initcall_debug

重启后 dmesg 会看到类似这样的输出：

[    0.020123] calling  init_timer_cpu_notifier+0x0/0x28 @ 1[    0.020456] initcall init_timer_cpu_notifier+0x0/0x28 returned 0 after 0 usecs[    0.020789] calling  spawn_ksoftirqd+0x0/0x30 @ 1[    0.021123] initcall spawn_ksoftirqd+0x0/0x30 returned 0 after 0 usecs

看到了吗——每行都标了 @ 1，这个数字就是 initcall 级别。对于排查启动性能问题，这个参数是神器。

8.5 和你写模块的关系

大多数情况下你不需要关心这些级别——写个简单模块，用 module_init() 就够了，它自动落在 device_initcall 级别。

但当你写的模块需要在其他设备驱动之前初始化（比如你写的是一个总线框架或一个中断控制器驱动），你就得考虑用更早的级别：

// 我这个驱动必须在 PCI 总线扫描之前初始化subsys_initcall(my_early_driver_init);

反过来，如果模块依赖某个子系统已经就绪，但你又不确定对方在什么级别初始化，那就用 late_initcall 兜底——"等你们所有人跑完了我再上"。

总的来说，initcall 机制回答了内核设计里一个根本问题：在正确的时机做正确的初始化。module_init 只是这个宏大体系里一个小小的、给普通驱动用的入口。

九、写内核模块容易踩的坑

分享几个我亲身踩过的坑，省得你再踩一遍：

9.1 忘记清理资源

这是排名第一的坑。kmalloc 了要 kfree，注册了 notifier 要注销，申请了 sysfs 入口要删除……内核里没有 RAII，没有智能指针，一切靠你自己记得。

9.2 在内核态做了会睡眠的事

中断上下文里不能睡眠。持有自旋锁时不能睡眠。但你调用 kmalloc(GFP_KERNEL) 可能就会睡眠。规则是：

• 进程上下文 → 可以用 GFP_KERNEL
• 中断/软中断上下文 → 只能用 GFP_ATOMIC

搞混了，内核会给你一个大大的 "scheduling while atomic" BUG。

9.3 内核版本兼容性

内核内部 API 不保证稳定。你在 5.15 上写的模块，放到 6.1 上可能就编译不过了。API 经常改名、改参数、甚至被整个移除。Linus 的名言是："We don't break userspace, but we break internal kernel APIs all the time."

9.4 滥用 printk

在热路径里打 printk 是性能杀手。调试完记得删掉或者改用 tracepoint。

9.5 Makefile 写错

内核模块的 Makefile 必须用内核构建系统，不能直接用 gcc --shared 之类的。最可靠的写法就是照搬上面那个模板。

参考资料

• [The Linux Kernel Module Programming Guide](https://sysprog21.github.io/lkmpg/) — 最好的入门教程，一直在更新
• Linux 内核源码里的 Documentation/kbuild/modules.rst — kbuild 权威文档
• 内核源码中的 include/linux/init.h — initcall 宏定义和级别编号，一目了然
• 内核源码中的 samples/ 目录 — 官方提供的示例代码，比任何教程都权威

*这篇文章不会让你成为内核专家，但希望它能让你有勇气打开终端，敲下第一个 insmod。那个感觉，值一万行文档。*