歡迎關(guān)注“嵌入式分享”，每周更新！? 正文

從接觸 Linux 系統(tǒng)開始，我們就知道內(nèi)核內(nèi)置（built-in）驅(qū)動會在系統(tǒng)上電啟動時(shí)自動加載，而編譯為.ko文件的驅(qū)動則需要手動通過insmod加載。

這看似順理成章的差異，背后實(shí)則是內(nèi)核對驅(qū)動初始化機(jī)制的精巧設(shè)計(jì) —— 核心在于module_init和module_exit這兩個(gè)宏在不同編譯模式下的實(shí)現(xiàn)邏輯差異。

要理解這一點(diǎn)，首先需要明確一個(gè)前提：無論是內(nèi)置驅(qū)動還是可加載模塊，其初始化和卸載的核心邏輯都是通過module_init（入口）和module_exit（出口）定義的。兩者的差異并非 “是否執(zhí)行這些函數(shù)”，而是 “何時(shí)、如何觸發(fā)這些函數(shù)的執(zhí)行”。

有了以上思路，問題就好辦了。

先從module_init/module_exit 入手，閱讀源碼（源碼路徑：include/linux/module.h）知道，這兩個(gè)宏根據(jù)驅(qū)動是否編譯為模塊，會展開為不同的代碼，從而決定初始化函數(shù)的調(diào)用時(shí)機(jī)。

當(dāng)驅(qū)動為內(nèi)置模塊（#ifndefMODULE）

此時(shí)MODULE宏未定義，module_init被定義為__initcall(x)：

__initcall(x)：將函數(shù)x注冊到內(nèi)核的初始化調(diào)用隊(duì)列中。內(nèi)核啟動時(shí)，會按優(yōu)先級依次執(zhí)行所有__initcall標(biāo)記的函數(shù)（從early_initcall到late_initcall）。

編譯時(shí)，這些初始化函數(shù)會被歸類到內(nèi)核的初始化段（如.init.text），內(nèi)核啟動時(shí)會按順序執(zhí)行這些函數(shù)。

因此，內(nèi)置驅(qū)動的初始化函數(shù)會在系統(tǒng)啟動階段自動執(zhí)行，無需手動干預(yù)。

當(dāng)驅(qū)動為可加載模塊

此時(shí)MODULE宏被定義（編譯時(shí)通過-DMODULE指定），module_init和module_exit的定義完全不同。

module_init(initfn)：將用戶定義的initfn函數(shù)別名為init_module（內(nèi)核模塊加載器約定的初始化入口）。 module_exit(exitfn)：將用戶定義的exitfn函數(shù)別名為cleanup_module（模塊卸載時(shí)的入口）。

當(dāng)通過insmod加載.ko文件時(shí)，內(nèi)核會調(diào)用init_module函數(shù)；通過rmmod卸載時(shí)，會調(diào)用cleanup_module函數(shù)。這兩個(gè)函數(shù)與用戶定義的initfn/exitfn是同一個(gè)函數(shù)（通過alias屬性關(guān)聯(lián)）。

總結(jié)

內(nèi)置驅(qū)動與可加載模塊的加載差異，本質(zhì)是module_init宏在不同編譯模式下的實(shí)現(xiàn)分流：

可加載模塊通過 “函數(shù)別名” 將初始化邏輯綁定到insmod觸發(fā)的標(biāo)準(zhǔn)入口，屬于 “用戶態(tài)手動觸發(fā)”；

內(nèi)置驅(qū)動通過 “初始化調(diào)用鏈” 將初始化邏輯注冊到內(nèi)核啟動流程，屬于 “內(nèi)核態(tài)自動執(zhí)行”。

這種設(shè)計(jì)既保證了系統(tǒng)關(guān)鍵驅(qū)動的自動初始化（確保啟動流程順暢），又提供了非關(guān)鍵驅(qū)動的動態(tài)加載能力（提升靈活性、節(jié)省內(nèi)存），是 Linux 內(nèi)核設(shè)備模型 “模塊化” 與 “啟動可靠性” 的精妙平衡。

（完）

本人專注 Linux 驅(qū)動 & Linux/Android BSP 開發(fā)調(diào)試，可接外包項(xiàng)目/技術(shù)支持/問題定位。有需求可加微信：【Chen_WeChat2026】。

更多原創(chuàng)技術(shù)文章：《README 2026》

審核編輯 黃宇