593
哈喽，大家好，我是LittleG。
严格来说*模块加载顺序*这一概念主要适用于动态加载的内核模块，而非静态编译到内核中的模块。
因为静态编译到内核中的模块已经作为内核代码的一部分直接编译进了内核映像。可以理解为在系统启动过程中，这些模块实际上已经处于“已加载”状态，无需再经历独立的加载过程，跟随Linux内核启动流程，走正常初始化即可。
由于静态编译的模块在系统启动时已经作为内核的一部分存在，不存在“加载”这一动作，所以也就不存在动态加载时的依赖关系检查和加载顺序问题。但是，对于内核编译过程中涉及多个静态模块的情况，确实存在一定的编译顺序，主要受到内核构建系统的组织结构和编译规则的影响。
下面结合Linux源码举例说明下，如何控制内核模块的编译(“静态加载”)顺序。
1、源码组织结构
Linux内核源码通常采用层次化的目录结构，其中各个模块（不论是内核子系统还是单独的驱动模块）都有各自的源码目录。例如：
在这个例子中，`driverA`、`driverB`、`driverC`和`driverD`是四个静态编译的内核模块。它们的编译顺序取决于构建系统如何遍历这些目录并安排编译任务。
2、Kconfig配置
每个内核模块通常有一个对应的Kconfig文件，用于定义模块是否可选、依赖关系等配置项。Kconfig文件中的`config`语句用于声明模块的存在，而`select`、`depends on`等关键字则用来表达模块间的依赖关系。这些依赖关系会影响编译时模块的处理顺序。
例如，在`drivers/block/Kconfig`中可能会有这样的配置：
这里，`BLOCK_DRIVER_A`选择时会自动选择`DEPENDENCY_X`，而`BLOCK_DRIVER_B`不仅依赖于`BLOCK_DRIVER_A`，还依赖于`DEPENDENCY_Y`。这样的依赖关系会在配置阶段被解析，确保编译时先编译依赖项。
3、Makefile及其依赖规则
内核的顶层Makefile以及各子系统、模块的Makefile共同构成了复杂的依赖关系网络。当执行`make`命令时，顶层Makefile会递归地遍历所有子目录，根据Kconfig配置生成相应的`*.config`文件，并进一步调用各子系统的Makefile来编译模块。
每个模块的Makefile通常包含类似以下的规则：
这里的`obj-y`列表指定了要编译的对象文件，而`driverA-objs`和`driverB-objs`则定义了构成单个模块的多个源文件。Makefile会按照列表的顺序处理这些对象文件，确保先编译依赖项。
4、总结
在上述源码组织结构、Kconfig配置和Makefile规则的共同作用下，内核模块的编译顺序(静态加载顺序)主要受以下因素影响：
源码目录结构：内核编译系统通常会按目录层级从上至下、从左至右递归地遍历源码树。因此，位于目录结构较前位置的模块通常会被先编译。
- Kconfig依赖：依赖关系明确的模块会在其依赖项编译完成后才开始编译。Kconfig中的`select`、`depends on`等语句确保了这一点。
- Makefile中的对象列表：在单个Makefile中，`obj-y`列表的顺序决定了模块编译的顺序。如果模块间存在隐式依赖（即源码中直接或间接引用了其他模块的符号），正确的Makefile编写应确保依赖模块先于被依赖模块出现在列表中。
综上所述，内核模块静态加载的顺序控制主要依赖于内核源码的组织结构、Kconfig配置文件中的依赖声明，以及Makefile中的编译规则。这些因素共同确保了编译过程中模块按正确顺序被处理，从而保证编译的正确性和最终内核映像的完整性。在实际开发过程中，维护好这些依赖关系是至关重要的，特别是在处理复杂模块间依赖或进行内核定制时。
下载ECAD模型
