🔍

B站相應的視屏教程：
📌 內核：博文+視頻 - 從靜態綁定驅動模型到現代設備模型

---

在 Linux 內核的發展歷程中，設備驅動結構經歷了從"硬編碼 + 手動注冊"的早期實現方式，到"設備模型統一管理"的現代化架構。這一演進不僅改變了驅動開發者的習慣，也極大提升了內核的可維護性、擴展性與模塊化能力。

本篇博文將聚焦早期的 靜態綁定驅動模型（Static Binding Driver Model），深入講解其原理、結構、優缺點，并與后續的設備模型機制進行對比，幫助讀者建立完整的認知脈絡。

---

📘 第一部分：什么是靜態綁定驅動模型？

所謂“靜態綁定”，是指驅動代碼中通過硬編碼的方式指定所使用的設備資源（如物理地址、中斷號、引腳編號等），并在模塊初始化過程中手動完成所有注冊與初始化步驟。

這種方式廣泛存在于 Linux v2.4 及更早版本 中，當時還沒有統一的 struct device、platform_driver、of_match_table 等機制。

---

? 核心特征

特征類別	表現
資源管理	資源地址、IRQ 手動硬編碼
匹配機制	沒有匹配機制，全靠人工指定
驅動結構	所有邏輯集中在 init 函數中
生命周期管理	沒有 probe/remove 接口
模塊加載	無法自動匹配，僅靠 insmod
用戶態接口	無 sysfs 映射，udev 不可見

---

📌 示例：靜態綁定驅動代碼片段

#define LCDIF3_BASE  0x32fc6000
#define LCDIF3_IRQ   42static void __iomem *lcd_base;static int __init lcd_driver_init(void)
{request_mem_region(LCDIF3_BASE, 0x1000, "lcdif");lcd_base = ioremap(LCDIF3_BASE, 0x1000);request_irq(LCDIF3_IRQ, lcd_irq_handler, 0, "lcdif", NULL);// 初始化寄存器writel(0x01, lcd_base + 0x00);printk("lcd driver loaded\n");return 0;
}static void __exit lcd_driver_exit(void)
{free_irq(LCDIF3_IRQ, NULL);iounmap(lcd_base);release_mem_region(LCDIF3_BASE, 0x1000);
}module_init(lcd_driver_init);
module_exit(lcd_driver_exit);
MODULE_LICENSE("GPL");

---

📘 第二部分：靜態綁定模型的優缺點

? 優點

• 實現簡單，易于快速驗證硬件邏輯
• 沒有抽象層，調試路徑清晰
• 適用于早期定制板、實驗性代碼

? 缺點

問題類型	描述
可移植性差	所有硬件信息寫死在代碼中，不易適配新平臺
不支持熱插拔	無法根據硬件動態加載驅動模塊，udev 無法使用
維護困難	所有初始化、清理邏輯集中在一個文件中，不易分離模塊
無法復用	沒有設備模型的抽象結構，代碼難以共享給其他項目或平臺
無法使用設備樹	與現代 SoC 的 DTS 描述方式不兼容，不能通過 compatible 匹配驅動

---

📘 第三部分：設備模型的引入與演進

Linux 內核從 v2.5.x 開始引入設備模型（Device Model），在 v2.6.0（2003 年） 正式啟用。

它提供了統一的結構用于描述設備（struct device）、驅動（struct device_driver）、總線（struct bus_type）與設備類（struct class），實現驅動與設備的解耦、匹配與動態管理。

---

📎 核心機制

結構體	作用說明
struct device	表示一個設備本體，包含資源、狀態等
struct driver	表示驅動代碼與功能結構
struct bus_type	表示設備與驅動的匹配方式（如 platform）
struct class	用于創建 /sys/class/ 接口

? 匹配機制演進

// 匹配表（由驅動提供）
static const struct of_device_id xxx_of_match[] = {{ .compatible = "fsl,imx8mp-lcdif1" },{}
};// 驅動注冊結構
static struct platform_driver xxx_driver = {.probe = xxx_probe,.remove = xxx_remove,.driver = {.name = "lcdif",.of_match_table = xxx_of_match,},
};

📘 自動加載與用戶空間聯動

• sysfs 自動創建 /sys/devices/platform/...
• /sys/bus/platform/drivers/... 中掛接驅動
• udev 可根據 alias 自動調用 modprobe 加載模塊
  

---

📘 第四部分：對比分析：靜態綁定 vs 設備模型

對比維度	靜態綁定驅動	設備模型驅動
資源定義	硬編碼	通過 DTS 或 platform_device 動態提供
匹配機制	無自動匹配	支持 of_match_table 自動綁定
生命周期管理	通過 module_init/exit 手動完成	通過 probe/remove 自動分離處理
可移植性	不具備平臺適配能力	支持同一驅動在多個硬件平臺間共享
sysfs 支持	不支持	自動創建設備節點，支持 udev、熱插拔等
資源釋放	手動 free_irq/iounmap	支持 devm_* 系列自動回收
推薦使用場景	早期內核、快速驗證、簡單定制板	主線驅動開發、模塊化平臺支持

---

📘 第五部分：案例對比分析

📌 靜態綁定代碼核心點

• 所有地址/中斷號寫死
• 所有初始化邏輯集中在 lcd_driver_init()
• 無匹配邏輯、無設備結構體、無 struct platform_device

📌 設備模型版本（platform）核心點

• of_match_table 用于與設備樹 compatible 匹配
• 注冊為 platform_driver，掛接 bus_type
• probe() 自動被調用，完成注冊與初始化
• 所有資源通過 devm_* 自動管理

---

? 總結：為什么設備模型是驅動發展的必然？

靜態綁定驅動模型雖然在早期發揮了重要作用，但隨著 SoC 架構的復雜化與模塊化需求的增強，其硬編碼、不可復用的特性逐漸成為負擔。

設備模型通過總線、設備、驅動三者的分離與抽象，成功實現了驅動框架的現代化，使得：

• 一個驅動可以匹配多個設備
• 一個設備可以熱插拔與自動加載驅動
• 系統可以動態管理設備生命周期
• 用戶空間可以通過 sysfs 觀察設備狀態

這正是現代嵌入式系統與通用 Linux 平臺所需的基礎能力。

---

📚 延伸閱讀

• Linux Device Model 設計初衷 - Patrick Mochel
• 內核文檔：Documentation/driver-model/
• 內核源碼：drivers/base/*、include/linux/device.h
• 推薦書籍：《Linux Device Drivers 第三版》《Linux內核設計與實現》

---

下一篇，我們將結合實際平臺（如 i.MX8M、Raspberry Pi）對比分析設備樹中的設備節點是如何與驅動匹配的，深入剖析設備模型運行時的數據流結構。