模块化设计：静态编译 vs 动态加载，如何选择？

驱动模块怎么装？这是个老话题了。我入行那会儿，大家习惯一股脑全编进内核。后来设备越来越多，内核越来越胖，大家又开始琢磨动态加载。说白了，静态编译和动态加载，就是「空间换时间」和「灵活换稳定」的博弈。

今天咱们就聊聊，这两种方式到底怎么选。我个人的经验是：没有银弹，只有权衡。

静态编译，就是把驱动代码直接塞进内核镜像。系统启动时，驱动跟着内核一起加载。动态加载呢？驱动编译成独立的 .ko 文件，系统跑起来后，用 insmod 或 modprobe 手动插进去。

你想想看，这两种方式对系统的影响完全不同。我整理了一张对比表，方便你快速把握核心差异：

核心结论：静态编译适合「确定性高、资源敏感」的场景；动态加载适合「需要灵活迭代、硬件热插拔」的场景。

我记得有一次做工业控制器的项目。那设备一上电就得在 3 秒内完成所有外设初始化。用动态加载？不行。文件系统还没挂载，模块根本找不到。最后全部静态编译，启动时序精确到毫秒级。

静态编译的典型场景：

配置方法很简单，内核菜单里选 y 就行：

Device Drivers  --->
  [*]   SPI support  --->
    <*>   SPI driver for MyDevice

小技巧：如果某个驱动必须静态编译，但你又想保留调试能力，可以在驱动代码里加 module_param()，通过内核启动参数控制行为。这样既保证了启动时序，又保留了灵活性。

动态加载最大的好处是什么？我跟你讲，开发阶段简直不要太爽。改一行代码，make 一下，insmod 就能测。不用一遍遍重启机器。我曾经在调试一个 USB 摄像头驱动时，一天之内迭代了 30 多个版本，全靠动态加载撑着。

但动态加载也有坑。我踩过最大的坑是：模块依赖地狱。一个驱动依赖另一个驱动，加载顺序错了，直接 panic。后来我学乖了，用 modprobe 代替 insmod，它会自动处理依赖。

动态加载的典型场景：

编译成模块的方法：

Device Drivers  --->
  [*]   SPI support  --->
    <M>   SPI driver for MyDevice

加载命令：

# 手动加载
insmod mydriver.ko

# 自动处理依赖
modprobe mydriver

# 查看已加载模块
lsmod

# 卸载模块
rmmod mydriver

注意：动态加载的模块必须与当前内核版本、配置完全匹配。否则会出现 Invalid module format 错误。我建议在 Makefile 里加上 CONFIG_MODULE_SIG 签名，生产环境强制校验。

实际项目中，我很少只用一种方式。更常见的做法是：核心驱动静态编译，非核心驱动动态加载。

举个例子，一个智能网关设备：

这样做的好处很明显：系统启动时只加载必要驱动，保证快速上线。后续按需加载其他驱动，内存利用率也高。

下面这张图，是我总结的决策流程：

我每次做驱动裁剪时，都会过一遍这个清单。你可以直接拿来用：

我的经验法则：如果一个驱动在系统生命周期内「几乎不会变」，那就静态编译。如果一个驱动「可能换硬件、可能升级、可能不用」，那就动态加载。别为了「万一以后要用」而静态编译所有驱动——那会让内核变得臃肿，启动变慢，内存浪费。

最后分享几个我踩过的坑，希望你别重蹈覆辙：

坑1：模块签名不匹配——有一次我编译了模块，放到另一台同内核版本机器上，结果加载失败。查了半天，发现是 CONFIG_MODULE_SIG_HASH 算法不同。从那以后，我统一用 CONFIG_MODULE_SIG_SHA512，并在构建脚本里固定签名密钥。
坑2：依赖模块未加载——一个 I2C 触摸屏驱动依赖 I2C 核心模块。我直接 insmod touch.ko，结果报错 Unknown symbol。后来改用 modprobe，或者把依赖模块也静态编译。
坑3：动态加载导致内存碎片——频繁加载卸载模块，内核模块内存分配器会产生碎片。长期运行的设备，我建议把常用驱动静态编译，减少动态操作。

嗯，关于静态编译和动态加载的选择，今天就聊到这儿。记住一句话：没有最好的方式，只有最合适的方式。根据你的项目场景，灵活搭配才是王道。