由於在下能力相當有限，有不當之處，還望批評指正^_^

一、概述

在核心中，匯流排/裝置/驅動模型實現了對匯流排/裝置/驅動的管理。

涉及的概念有struct bus_type（匯流排型別）。

核心並不關心每種匯流排的實現細節，也未預先定義一共有哪些具體的匯流排型別。

因此，開發者甚至可以自己定義一種匯流排型別，註冊到核心中。

如下是PCI匯流排型別的定義。相當於是將PCI匯流排共性的部分進行了包裝。

struct bus_type pci_bus_type = {
.name= "pci",
.match= pci_bus_match,
.uevent= pci_uevent,
.probe= pci_device_probe,
.remove= pci_device_remove,
.shutdown= pci_device_shutdown,
.dev_attrs= pci_dev_attrs,
.bus_attrs= pci_bus_attrs,
.drv_attrs= pci_drv_attrs,
.pm= PCI_PM_OPS_PTR,

};

struct pci_bus則代表了一條具體的PCI匯流排，他包含了匯流排號，還用連結串列將其下面掛著的裝置全部串了起來。

然後，struct pci_driver和struct pci_dev分別表示pci驅動與pci裝置。

除了pci匯流排，核心中還有i2c、spi、usb、platform等匯流排，涉及到的概念大體類似。

需要特別注意的是，對於匯流排裝置驅動模型，核心關鍵詞是管理。

每一個匯流排型別，體現了外設接入系統的一種方式。

有些裝置，並沒有通過某種匯流排接入系統，而是直接掛在了系統總線上。為了架構的統一，對於這種裝置，核心抽象出了一種特殊的匯流排—platform匯流排，然後將這些裝置都歸到platform匯流排中。

這樣，核心就將匯流排型別、匯流排、裝置驅動、裝置很有條理的管理了起來，同時還對裝置與驅動進行匹配。

需要注意的是，核心的這種管理結構，只關心管理層面的資訊，並不關心所管理物件的別的方面的資訊。

例如，某匯流排具體是如何與外設連線的，原理是什麼，各種操作是怎麼實現的，某裝置是幹什麼的，某驅動要如何設定暫存器，如何處理中斷，如何將所驅動裝置的功能提供給使用者使用。

這些內容，管理層面都是不關心的。

而對於各種各樣的驅動而言，所要做的操作主要包含如下三種。

與裝置互動（對於pci裝置可直接讀寫暫存器，對於i2c裝置可通過匯流排控制器與之互動）

處理中斷

向核心註冊一個物件(如cdev/net_device/input_dev等等)，使得系統可以將這個裝置用起來

另外，驅動可能還會針對接管的每個裝置，在/sys下面建立一些屬性檔案，以便使用者可以通過這些屬生與裝置進行互動。

一般來說，驅動會針對接管的每一個裝置，建立一個結構變數，用於維護上述各種操作可能涉及的各種上下文資訊。

好了，下面還是看看匯流排裝置驅動模型相關內容吧。

sys檔案系統與匯流排裝置驅動模型

/sys/bus/目錄下列出了各種匯流排型別，像pci、i2c、usb、platform等。

我們以pci匯流排為例，看看相關概念。

/sys/bus/pci/devices/目錄下則則列出了所有系統中存在的所有pci裝置(不管有沒有安裝對應的驅動程式)的名稱，pci裝置的名稱即pci地址(即 "域:pci匯流排號:槽位號:功能號")。下面的示例輸出，限於篇幅，只列出了幾個裝置作為樣例。

[[email protected] char]# ls /sys/bus/pci/devices/
0000:00:00.0  0000:03:00.0  0000:06:12.7  0000:06:16.3

/sys/bus/pci/drivers目錄下則列出了所有已載入的所有pci裝置的驅動。

下面的示例輸出，列出了pci裝置驅動ixgbe(一款網絡卡驅動程式)，以及當前接管了哪些裝置(0000:06:00.0和0000:06:00.1)。

[[email protected] char]# ls /sys/bus/pci/drivers/ixgbe  
0000:06:00.0  0000:06:00.1  bind  module  new_id  remove_id  uevent  unbind

示例輸出中還有一些別的檔案，像bind用來指定某個pci裝置由此驅動接管，unbind則起相反的作用。通常，一個驅動都有自己支援的裝置型號的列表。new_id用於動態增加此驅動可以接管的裝置型號，remove_id則起相反作用。

【注】

pci裝置的名稱，是通過如下方式設定的

dev_set_name(&dev->dev, "%04x:%02x:%02x.%d", pci_domain_nr(dev->bus),
     dev->bus->number, PCI_SLOT(dev->devfn),
     PCI_FUNC(dev->devfn));

而其他型別的裝置，命名方式也名異。下面列出了其他幾種裝置的命名方式

(i) isa

dev_set_name(&isa_dev->dev, "%s.%u",
    isa_driver->driver.name, id);

(ii)platform

(iii)I2C

dev_set_name(&client->dev, "%d-%04x", i2c_adapter_id(adap),
    client->addr);

【注】

有時候，可能會存在多個驅動，都可以驅動某一個裝置的情況。

這時候，使用者可以執行將裝置與驅動進行繫結或解除繫結的操作。

將裝置與驅動繫結的方法為：

echo  dev_name  > /sys/bus/bus_type/drivers/driver_name/bind

將裝置與驅動解除繫結的方法為：

echo  dev_name  > /sys/bus/bus_type/drivers/driver_name/unbind

echo 0000:06:00.1 > /sys/bus/pci/drivers/ixgbe/bind

echo命令執行後，由driver_bind/driver_unbind函式執行具體的繫結與解綁。

這兩個函式對應於sys檔案系統的store操作。

當然，除了pci匯流排，還有別的匯流排型別。

不同型別的匯流排，有著不同的原理與概念。

下面列出了若干不同型別匯流排的裝置，可以看到其命名風格的不同。

[[email protected] char]# ls /sys/bus/i2c/devices/
2-007c  i2c-0  i2c-1  i2c-2  i2c-3

[[email protected] char]# ls /sys/bus/usb/devices/
1-0:1.0  1-1  1-1:1.0  1-1.3  1-1.3:1.0  1-1.3:1.1  2-0:1.0  2-1  2-1:1.0  usb1  usb2

[[email protected] char]# ls /sys/bus/platform/devices/
alarmtimer  coretemp.1        GHES.0  gpio_ich         iTCO_wdt   pcspkr
coretemp.0  Fixed MDIO bus.0  GHES.1  ipmi_bmc.3060.8  microcode  serial8250

相關核心原始碼

裝置驅動方面的核心程式碼，位於drivers/base目錄下。core.c是裝置管理的核心檔案，driver.c是驅動管理的核心檔案，bus.c是匯流排處理的核心檔案。我們可以以他們為線索，看出不同模組之間的呼叫關係，同時也能看出核心在管理裝置與驅動方面的精妙設計理念。

在看程式碼之前，先來聊聊裝置、驅動、匯流排之間的關係，同時引出一些核心中的重要資料結構。首先說說裝置。不管是什麼奇奇怪怪的裝置，它畢竟都是一個裝置。所以，在這個層次上，可以將一切裝置都歸納到裝置這個集合中去管理。就像動物一樣，不管是人，還是豬馬牛羊，站在動物這個層次上，都可以歸屬到動物這個類別中去。

在核心中，用於表示一個裝置的資料結構是 struct device。

再來說說驅動。同理，一切驅動都是驅動，自然也是統一管理。

核心中，表示一個驅動的資料結構是 struct device_driver。

好了，現在已經有了裝置與驅動的表示方法。但是，這是站在最高層次上做出的概念抽象。

不同型別匯流排的裝置，其標識方法也各有不同。

實際上，核心原始碼中也為此定義了不同型別的結構來標識之。

例如，struct platform_device_id用於標識platform裝置，struct pci_device_id用於標識pci裝置。

未完...