1. 课程导论：为什么需要按需加载？VFS初始化阶段模块膨胀的痛点

在嵌入式 Linux 系统中，VFS（虚拟文件系统）初始化阶段是所有文件系统驱动注册的“第一现场”。传统做法是在内核启动时，将所有可能用到的文件系统驱动一次性编译进内核或通过 initramfs 全部加载。这种“全量加载”模式在桌面或服务器场景尚可容忍，但在资源受限的嵌入式环境中，却成为启动速度、内存占用和系统复杂性的核心瓶颈。

1.1 模块膨胀的三大表现

VFS 初始化阶段的模块膨胀并非单一维度的增长，而是从代码量、内存占用、初始化耗时三个层面同时爆发。下表对比了“全量加载”与“按需加载”在典型嵌入式环境中的差异：

1.2 VFS 初始化阶段的“膨胀链”

要理解膨胀的根源，需要深入 VFS 初始化流程。下图展示了传统全量加载模式下，VFS 初始化阶段的模块注册路径：

从图中可以清晰看到：vfs_caches_init() 会遍历一个静态注册表 filesystem_registration_table[]，该表在编译时由所有启用的文件系统驱动填充。即使系统最终只使用 ext4 和 procfs，内核仍然会为 ext2、ext3、btrfs、xfs、ntfs、fat 等数十个驱动执行注册函数，分配 inode_operations、file_operations 等数据结构。

1.3 嵌入式场景的“放大效应”

模块膨胀在嵌入式系统中会被进一步放大，原因包括：

• 内存资源稀缺： 嵌入式设备通常只有 64MB–512MB RAM，每个额外驱动即使不挂载，也会占用 slab 缓存和 dentry 缓存。
• 启动时间敏感： 工业控制、汽车电子等领域要求冷启动时间 < 1s，VFS 初始化阶段的数百次函数调用成为关键路径。
• 模块依赖复杂： 某些文件系统驱动（如 overlayfs）依赖下层文件系统，全量加载时可能触发循环依赖或初始化顺序错误。
• 安全攻击面增加： 每个注册的驱动都暴露了系统调用接口，未使用的驱动成为潜在攻击向量。

1.4 按需加载的核心思路

本课程提出的“文件系统驱动按需加载”方案，核心思想是：将驱动注册从“编译时静态绑定”改为“运行时按需触发”。具体来说：

1. 延迟注册： 在 VFS 初始化阶段，只注册 VFS 核心功能（如 dentry cache、inode cache），不注册任何文件系统驱动。
2. 按需触发： 当用户空间执行 mount() 系统调用时，根据文件系统类型名称动态查找并注册对应的驱动。
3. 模块化注册表： 使用哈希表或红黑树替代静态数组，支持动态插入/删除驱动条目。
4. 依赖自动解析： 当驱动 A 依赖驱动 B 时，在注册 A 之前自动触发 B 的注册。

下表对比了传统方案与按需加载方案在关键设计维度的差异：

1.5 课程路线图

本课程将围绕“按需加载”这一核心目标，从原理到实践逐步展开：

• 第 2–5 章： 深入分析 VFS 初始化源码，定位模块膨胀的精确位置。
• 第 6–10 章： 设计按需加载框架，包括注册表重构、延迟绑定机制、依赖解析算法。
• 第 11–15 章： 在嵌入式 Linux 上实现原型，并对比性能数据。
• 第 16–20 章： 处理边界情况：模块卸载、热插拔、错误恢复。
• 第 21–25 章： 与现有内核机制（如 request_module、udev）的集成方案。
• 第 26–30 章： 实战案例：在 Yocto/Buildroot 项目中应用按需加载。