Linux 核心驅動程式初始化順序深度解析與調整實戰

核心啟動流程中的驅動初始化機制

Linux 核心啟動時，所有驅動程式的初始化工作主要集中在 init/main.c 的 do_basic_setup() 函數中。這個函數依序呼叫 init_workqueues()、usermodehelper_init()、driver_init() 等核心初始化函數，最後透過 do_initcalls() 執行所有註冊的初始化呼叫。

do_initcalls() 核心邏輯

do_initcalls() 會遍歷 __initcall_start 到 __initcall_end 之間的所有函數指標並依序執行。這裡有幾個關鍵檢查機制：

• 搶佔計數檢查：確保初始化過程中沒有發生搶佔不平衡
• 中斷狀態檢查：防止初始化函數在關閉中斷狀態下返回
• 排程工作刷新：確保初始化序列完成後沒有殘留工作

七層初始化優先級架構

在 arch/xxx/kernel/vmlinux.lds.S 連結腳本中定義了 .initcall.init 區段，包含七個子區段：

.initcall.init {
    *(.initcall1.init)
    *(.initcall2.init)
    *(.initcall3.init)
    *(.initcall4.init)
    *(.initcall5.init)
    *(.initcall6.init)
    *(.initcall7.init)
}

這七個優先級對應 include/linux/init.h 中定義的巨集：

關鍵發現：我們常用的 module_init() 實際上等同於 device_initcall()，屬於優先級 6（.initcall6.init）。

實戰案例：I2C 觸控螢幕驅動依賴問題

開發觸控螢幕驅動時常遇到一個經典問題：驅動需要使用 I2C 總線提供的 API，但在核心初始化階段 I2C 子系統尚未就緒。這是因為 I2C 核心初始化屬於 subsys_initcall（優先級 4），而普通設備驅動預設是 device_initcall（優先級 6），導致執行順序錯誤。

解決方案

1. 調整初始化優先級：將驅動初始化改為 subsys_initcall 或 late_initcall
2. 模組化依賴管理：在驅動內部封裝 i2c_driver 和 input_dev 結構，控制載入順序
3. module_init 中註冊 i2c_driver
4. 在 attach_adapter 回呼中再註冊 input_dev

2.4 vs 2.6 核心的差異

在 2.4 核心中，初始化函數指標順序與連結順序相關，是不確定的。2.6 核心引入七層子區段機制，區段間順序固定，但同一子區段內仍受連結順序影響。這意味著同優先級驅動之間的相對順序仍不可預測，必須透過優先級調整來解決強依賴關係。

最佳實踐建議

• 優先使用 late_initcall 處理非關鍵路徑初始化
• 跨子系統依賴時，明確指定優先級而非依賴預設值
• 善用 initcall_debug 核心參數除錯初始化順序
• 考慮使用 module_init 配合 MODULE_ALIAS 實現按需載入