[導讀] Linux設備林林總總,嵌入式開發一個繞不開的話題就是設備驅動開發,在做具體設備驅動開發之前,有必要對Linux設驅動模型有一個相對清晰的認識,將會幫助驅動開發,明白具體驅動介面運算子相應都做些什么,
個人對于驅動模型的理解概括起來就是一句話:利用面向物件編程思想,實作設備分層管理軟體體系結構,
注:代碼分析基于linux-5.4.31
為啥要驅動模型
隨著系統結構演化越來越復雜,Linux內核對設備描述衍生出一般性的抽象描述,形成一個分層體系結構,從而引入了設備驅動模型,這樣描述還是不夠讓人理解,來看一下這些需求就好理解些:
- Linux內核可以在各種體系結構和硬體平臺上運行,因此需要最大限度地提高代碼在平臺之間的可重用性,
- 分層實作也實作了軟體工程的高內聚-低耦合的設計思想,低耦合體現在對外提供統一的抽象訪問介面,高內聚將相關度緊密的集中抽象實作,
- Linux內核驅動程式模型是先前在內核中使用的所有不同驅動程式模型的統一, 它旨在通過將一組資料和操作整合到全域可訪問的資料結構中,來擴展基于基礎總線來橋接設備驅動程式,
傳統的驅動模型為它們所控制的設備實作了某種類似于樹的結構(有時只是一個串列),不同型別的總線之間沒有任何一致性,
驅動模型抽象了啥
當前驅動程式模型為描述總線和總線下可能出現的設備提供了一個通用的、統一的模型,統一總線模型包括一組所有總線都具有的公共屬性和一組公共回呼,如總線探測期間的設備發現、總線關閉、總線電源管理等,
通用的設備和橋接介面反映了現代計算機的目標:即執行無縫設備“即插即用”,電源管理和熱插拔的能力, 特別是,英特爾和微軟規定的模型(即ACPI)可確保與x86兼容的系統上幾乎任何總線上的幾乎所有設備都可以在此范式下作業, 當然,雖然大多數總線都支持其中大多數操作,但并不是每條總線都能夠支持所有此類操作,
那么哪些通用需求被抽象出來了呢?
-
電源系統和系統關機,對于電源管理與系統關機對于設備相關的操作進行抽象實作,關機為什么要被抽象出來管理,比如設備操作正在進行此時系統收到關機指令,那么在設備模型層就會遍歷系統設備硬體,確保系統正確關機,
-
用戶空間訪問:sysfs虛擬檔案系統實作與設備模型對外的訪問抽象,這也是為什么說Linux 設備也是檔案的由來,實際從軟體架構層面看,這其實是一個軟體橋接模塊,抽象出統一用戶訪問介面,橋接了設備驅動,
-
熱插拔管理:熱插拔管理機制定義統一的抽象介面運算子kset_hotplug_ops,不同設備利用運算子實作差異化,
-
設備型別:設備分類機制,從高層級抽象描述設備型別,具體可以在sysfs下面體現,
用戶空間訪問
由于具有系統中所有設備的完整分層視圖,因此將完整的分層視圖匯出到用戶空間變得相對容易, 這是通過實作名為sysfs虛擬檔案系統來完成的,
sysfs的自動掛載通常是通過/etc/fstab檔案中的以下條目來完成的:
none /sys sysfs defaults 0 0
對于Debian系統而言,可能在/lib/init/fstab采用下面的形式掛載:
none /sys sysfs nodev,noexec,nosuid 0 0
當然也可以采用手動方式掛載:
# mount -t sysfs sysfs /sys
當將設備插入樹中時,都會為其創建一個目錄,該目錄可以填充在發現的每個層(全域層,總線層或設備層)中,
全域層當前創建兩個檔案-'name'和'power', 前者報告設備名稱, 后者報告設備的當前電源狀態, 它還將用于設定當前電源狀態,
總線層為探測總線時發現的設備創建檔案, 例如,PCI層當前為每個PCI設備創建“ irq”和“resource”檔案,
特定于設備的驅動程式也可以在其目錄中匯出檔案,以暴露特定于設備的資料或可用介面,
驅動模型實作
先來梳理一下內部幾個主要與驅動模型相關的資料結構:
./include/linux/Device.h 定義設備驅動主要資料結構
- bus_type:抽象描述總線型別,如USB/PCI/I2C/MMC等
- device_driver:實作具體連接在總線上的設備驅動,
- device:描述連接在總線上的設備
./include/linux/Kobject.h中定義了隱藏在后臺的類似于基類的資料結構:
- kset:可以認為是kobject的頂層容器類,每個kset內部都包含了自己的kobject.
- kobject:在 sysfs 中出現的每個物件都對應一個 kobject, 它和內核互動來創建它的可見表述,每一個 kobject 對應 檔案系統 /sys 里的一個 目錄,目錄的名字就是結構體中的 name

bus_type
bus_type用以驅動總線,具體的驅動USB/I2C/PCI/MMC等:
- 注冊總線,利用bus_register注冊總線,bus_unregister洗掉總線,如下例子,每種總線須定義一個bus_type物件,并利用bus_register注冊總線,或bus_unregister洗掉總線,
/*i2c-core-base.c*/
struct bus_type i2c_bus_type = {
.name = "i2c",
.match = i2c_device_match,
.probe = i2c_device_probe,
.remove = i2c_device_remove,
.shutdown = i2c_device_shutdown,
};
EXPORT_SYMBOL_GPL(i2c_bus_type);
static int __init i2c_init(void)
{
int retval;
retval = of_alias_get_highest_id("i2c");
down_write(&__i2c_board_lock);
if (retval >= __i2c_first_dynamic_bus_num)
__i2c_first_dynamic_bus_num = retval + 1;
up_write(&__i2c_board_lock);
/*注冊I2C總線*/
retval = bus_register(&i2c_bus_type);
if (retval)
return retval;
is_registered = true;
#ifdef CONFIG_I2C_COMPAT
i2c_adapter_compat_class = class_compat_register("i2c-adapter");
if (!i2c_adapter_compat_class) {
retval = -ENOMEM;
goto bus_err;
}
#endif
retval = i2c_add_driver(&dummy_driver);
if (retval)
goto class_err;
if (IS_ENABLED(CONFIG_OF_DYNAMIC))
WARN_ON(of_reconfig_notifier_register(&i2c_of_notifier));
if (IS_ENABLED(CONFIG_ACPI))
WARN_ON(acpi_reconfig_notifier_register(&i2c_acpi_notifier));
return 0;
class_err:
#ifdef CONFIG_I2C_COMPAT
class_compat_unregister(i2c_adapter_compat_class);
bus_err:
#endif
is_registered = false;
/*錯誤時洗掉總線*/
bus_unregister(&i2c_bus_type);
return retval;
}
- 注冊配接器驅動程式(USB控制器,I2C配接器等),以檢測連接的設備,并提供與設備的通信機制
- 圖中的match函式介面用于將驅動程式與設備進行匹配,match回呼的目的是使總線有機會通過比較驅動程式支持的設備ID與特定設備的設備ID來確定特定驅動程式是否支持特定設備,而不會犧牲特定于總線的功能或型別安全性 ,當向總線注冊驅動程式時,將遍歷總線的設備串列,并為每個沒有與之關聯的驅動程式的設備呼叫match回呼,
- 提供API函式以實作配接器驅動以及設備驅動,
- 同時dev_pm_ops *pm實作對于總線的功耗管理介面抽象,對于特定總線實作這個運算子對應的函式,
struct dev_pm_ops {
int (*prepare)(struct device *dev);
void (*complete)(struct device *dev);
int (*suspend)(struct device *dev);
int (*resume)(struct device *dev);
int (*freeze)(struct device *dev);
int (*thaw)(struct device *dev);
int (*poweroff)(struct device *dev);
int (*restore)(struct device *dev);
int (*suspend_late)(struct device *dev);
int (*resume_early)(struct device *dev);
int (*freeze_late)(struct device *dev);
int (*thaw_early)(struct device *dev);
int (*poweroff_late)(struct device *dev);
int (*restore_early)(struct device *dev);
int (*suspend_noirq)(struct device *dev);
int (*resume_noirq)(struct device *dev);
int (*freeze_noirq)(struct device *dev);
int (*thaw_noirq)(struct device *dev);
int (*poweroff_noirq)(struct device *dev);
int (*restore_noirq)(struct device *dev);
int (*runtime_suspend)(struct device *dev);
int (*runtime_resume)(struct device *dev);
int (*runtime_idle)(struct device *dev);
};
- iommu_ops 運算子提供總線相關的IOMMU抽象,
- 設備驅動注冊到總線上時,將在sysfs管理總線/設備/設備驅動的層次關系,以PCI為例:
/*在總線上注冊的驅動程式會在總線的驅動程式目錄中獲得一個目錄*/
/sys/bus/pci/
|-- devices
`-- drivers
|-- Intel ICH
|-- Intel ICH Joystick
|-- agpgart
`-- e100
/*在該型別的總線上發現的每個設備都會在總線的設備目錄中獲得到物理層次結構中該設備目錄的符號鏈接*/
/sys/bus/pci/
|-- devices
| |-- 00:00.0 -> ../../../root/pci0/00:00.0
| |-- 00:01.0 -> ../../../root/pci0/00:01.0
| `-- 00:02.0 -> ../../../root/pci0/00:02.0
`-- drivers
- 總線屬性:bus_groups/設備屬性dev_groups/驅動屬性drv_groups,

device
-
作用:抽象描述具體的設備
-
設備注冊:發現設備的總線驅動程式使用下面的函式來向內核注冊設備
int device_register(struct device * dev);
- 利用device_unregister()從總線上洗掉設備
device_driver
- 作用:抽象描述連接在總線上的具體設備的驅動
- 驅動注冊,通過下面的函式將設備驅動程式注冊
int driver_register(struct device_driver *drv);
- 使用它使用以下命令從驅動程式目錄中添加和洗掉屬性
int driver_create_file(struct device_driver *, const struct driver_attribute *);
void driver_remove_file(struct device_driver *, const struct driver_attribute *);
class
- 作用:抽象設備的高層視圖,描述的是設備的集合,抽象了同型別的設備的底層實作細節,比如所有的網路介面都位于/sys/class/net下
- struct subsys_private *p描述類鏈表
kobject/kset
- kobject類似于面向物件中的內核基類,內核利用它將各個物件連接起來組成分層的機構體系,其parent指標將形成一個樹狀分層結構,
- kset內部包含了kobject,重心在描述物件的聚集于集合,這也是set一詞的含義,每一個kset添加到系統中,都將在sysfs中創建一個目錄
- kobject/kset一起實作了sysfs虛擬檔案系統中設備/總線/設備驅動樹狀分層結構的最關鍵的底層實作由來,
總體上而言:
通過上面一些關鍵資料結構關系分析,總線設備驅動模型最終目的是實作如下這樣一個分層驅動模型,

文章出自微信公眾號:嵌入式客堆疊,更多內容,請關注本人公眾號,嚴禁商業使用,違法必究

轉載請註明出處,本文鏈接:https://www.uj5u.com/caozuo/63208.html
標籤:Linux
上一篇:容器云技術
下一篇:簡單安裝配置samba服務器
