哈嘍，大家好，我是LittleG。

Linux內核模塊加載順序(一)

嚴格來說*模塊加載順序*這一概念主要適用于動態(tài)加載的內核模塊，而非靜態(tài)編譯到內核中的模塊。

因為靜態(tài)編譯到內核中的模塊已經作為內核代碼的一部分直接編譯進了內核映像?？梢岳斫鉃樵谙到y(tǒng)啟動過程中，這些模塊實際上已經處于“已加載”狀態(tài)，無需再經歷獨立的加載過程，跟隨Linux內核啟動流程，走正常初始化即可。

由于靜態(tài)編譯的模塊在系統(tǒng)啟動時已經作為內核的一部分存在，不存在“加載”這一動作，所以也就不存在動態(tài)加載時的依賴關系檢查和加載順序問題。但是，對于內核編譯過程中涉及多個靜態(tài)模塊的情況，確實存在一定的編譯順序，主要受到內核構建系統(tǒng)的組織結構和編譯規(guī)則的影響。

下面結合Linux源碼舉例說明下，如何控制內核模塊的編譯(“靜態(tài)加載”)順序。

1、源碼組織結構

Linux內核源碼通常采用層次化的目錄結構，其中各個模塊（不論是內核子系統(tǒng)還是單獨的驅動模塊）都有各自的源碼目錄。例如：

?

在這個例子中，`driverA`、`driverB`、`driverC`和`driverD`是四個靜態(tài)編譯的內核模塊。它們的編譯順序取決于構建系統(tǒng)如何遍歷這些目錄并安排編譯任務。

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及其依賴規(guī)則

內核的頂層Makefile以及各子系統(tǒng)、模塊的Makefile共同構成了復雜的依賴關系網絡。當執(zhí)行`make`命令時，頂層Makefile會遞歸地遍歷所有子目錄，根據Kconfig配置生成相應的`*.config`文件，并進一步調用各子系統(tǒng)的Makefile來編譯模塊。

每個模塊的Makefile通常包含類似以下的規(guī)則：

這里的`obj-y`列表指定了要編譯的對象文件，而`driverA-objs`和`driverB-objs`則定義了構成單個模塊的多個源文件。Makefile會按照列表的順序處理這些對象文件，確保先編譯依賴項。

4、總結

在上述源碼組織結構、Kconfig配置和Makefile規(guī)則的共同作用下，內核模塊的編譯順序(靜態(tài)加載順序)主要受以下因素影響：

源碼目錄結構：內核編譯系統(tǒng)通常會按目錄層級從上至下、從左至右遞歸地遍歷源碼樹。因此，位于目錄結構較前位置的模塊通常會被先編譯。

- Kconfig依賴：依賴關系明確的模塊會在其依賴項編譯完成后才開始編譯。Kconfig中的`select`、`depends on`等語句確保了這一點。

- Makefile中的對象列表：在單個Makefile中，`obj-y`列表的順序決定了模塊編譯的順序。如果模塊間存在隱式依賴（即源碼中直接或間接引用了其他模塊的符號），正確的Makefile編寫應確保依賴模塊先于被依賴模塊出現(xiàn)在列表中。

綜上所述，內核模塊靜態(tài)加載的順序控制主要依賴于內核源碼的組織結構、Kconfig配置文件中的依賴聲明，以及Makefile中的編譯規(guī)則。這些因素共同確保了編譯過程中模塊按正確順序被處理，從而保證編譯的正確性和最終內核映像的完整性。在實際開發(fā)過程中，維護好這些依賴關系是至關重要的，特別是在處理復雜模塊間依賴或進行內核定制時。