Linux 與 Windows 的設備驅動模型對比：架構、API 和開發環境比較

名詞縮寫：

• API 應用程序介面 （ Application Program Interface ）
• ABI 應用系統二進位介面 （ Application Binary Interface ）

設備驅動是操作系統的一部分，它能夠通過一些特定的編程介面便於硬體設備的使用，這樣軟體就可以控制並且運行那些設備了。因為每個驅動都對應不同的操作系統，所以你就需要不同的 Linux、Windows 或 Unix 設備驅動，以便能夠在不同的計算機上使用你的設備。這就是為什麼當你僱傭一個驅動開發者或者選擇一個研發服務商提供者的時候，查看他們為各種操作系統平台開發驅動的經驗是非常重要的。

驅動開發的第一步是理解每個操作系統處理它的驅動的不同方式、底層驅動模型、它使用的架構、以及可用的開發工具。例如，Linux 驅動程序模型就與 Windows 非常不同。雖然 Windows 提倡驅動程序開發和操作系統開發分別進行，並通過一組 ABI 調用來結合驅動程序和操作系統，但是 Linux 設備驅動程序開發不依賴任何穩定的 ABI 或 API，所以它的驅動代碼並沒有被納入內核中。每一種模型都有自己的優點和缺點，但是如果你想為你的設備提供全面支持，那麼重要的是要全面的了解它們。

在本文中，我們將比較 Windows 和 Linux 設備驅動程序，探索不同的架構，API，構建開發和分發，希望讓您比較深入的理解如何開始為每一個操作系統編寫設備驅動程序。

1. 設備驅動架構

Windows 設備驅動程序的體系結構和 Linux 中使用的不同，它們各有優缺點。差異主要受以下原因的影響：Windows 是閉源操作系統，而 Linux 是開源操作系統。比較 Linux 和 Windows 設備驅動程序架構將幫助我們理解 Windows 和 Linux 驅動程序背後的核心差異。

1.1. Windows 驅動架構

雖然 Linux 內核分發時帶著 Linux 驅動，而 Windows 內核則不包括設備驅動程序。與之不同的是，現代 Windows 設備驅動程序編寫使用 Windows 驅動模型（WDM），這是一種完全支持即插即用和電源管理的模型，所以可以根據需要載入和卸載驅動程序。

處理來自應用的請求，是由 Windows 內核的中被稱為 I/O 管理器的部分來完成的。I/O 管理器的作用是是轉換這些請求到 I/O 請求數據包 （ IO Request Packets ） （IRP），IRP 可以被用來在驅動層識別請求並且傳輸數據。

Windows 驅動模型 WDM 提供三種驅動， 它們形成了三個層：

• 過濾 （ Filter ） 驅動提供關於 IRP 的可選附加處理。
• 功能 （ Function ） 驅動是實現介面和每個設備通信的主要驅動。
• 匯流排 （ Bus ） 驅動服務不同的配適器和不同的匯流排控制器，來實現主機模式控制設備。

一個 IRP 通過這些層就像它們經過 I/O 管理器到達底層硬體那樣。每個層能夠獨立的處理一個 IRP 並且把它們送回 I/O 管理器。在硬體底層中有硬體抽象層（HAL），它提供一個通用的介面到物理設備。

1.2. Linux 驅動架構

相比於 Windows 設備驅動，Linux 設備驅動架構根本性的不同就是 Linux 沒有一個標準的驅動模型也沒有一個乾淨分隔的層。每一個設備驅動都被當做一個能夠自動的從內核中載入和卸載的模塊來實現。Linux 為即插即用設備和電源管理設備提供一些方式，以便那些驅動可以使用它們來正確地管理這些設備，但這並不是必須的。

模式輸出那些它們提供的函數，並通過調用這些函數和傳入隨意定義的數據結構來溝通。請求來自文件系統或網路層的用戶應用，並被轉化為需要的數據結構。模塊能夠按層堆疊，在一個模塊進行處理之後，另外一個再處理，有些模塊提供了對一類設備的公共調用 介面，例如 USB 設備。

Linux 設備驅動程序支持三種設備：

• 實現一個位元組流介面的 字元 （ Character ） 設備。
• 用於存放文件系統和處理多位元組數據塊 IO 的 塊 （ Block ） 設備。
• 用於通過網路傳輸數據包的 網路 （ Network ） 介面。

Linux 也有一個硬體抽象層（HAL），它實際扮演了物理硬體的設備驅動介面。

2. 設備驅動 API

Linux 和 Windows 驅動 API 都屬於事件驅動類型：只有當某些事件發生的時候，驅動代碼才執行——當用戶的應用程序希望從設備獲取一些東西，或者當設備有某些請求需要告知操作系統。

2.1. 初始化

在 Windows 上，驅動被表示為 DriverObject 結構，它在 DriverEntry 函數的執行過程中被初始化。這些入口點也註冊一些回調函數，用來響應設備的添加和移除、驅動卸載和處理新進入的 IRP。當一個設備連接的時候，Windows 創建一個設備對象，這個設備對象在設備驅動後面處理所有應用請求。

相比於 Windows，Linux 設備驅動生命周期由內核模塊的 module_init 和 module_exit 函數負責管理，它們分別用於模塊的載入和卸載。它們負責註冊模塊來通過使用內核介面來處理設備的請求。這個模塊需要創建一個設備文件（或者一個網路介面），為其所希望管理的設備指定一個數字識別號，並註冊一些當用戶與設備文件交互的時候所使用的回調函數。

2.2. 命名和聲明設備

在 Windows 上註冊設備

Windows 設備驅動在新連接設備時是由回調函數 AddDevice 通知的。它接下來就去創建一個 設備對象 （ device object ） ，用於識別該設備的特定的驅動實例。取決於驅動的類型，設備對象可以是 物理設備對象 （ Physical Device Object ） （PDO）， 功能設備對象 （ Function Device Object ） （FDO），或者 過濾設備對象 （ Filter Device Object ） （FIDO）。設備對象能夠堆疊，PDO 在底層。

設備對象在這個設備連接在計算機期間一直存在。DeviceExtension 結構能夠被用於關聯到一個設備對象的全局數據。

設備對象可以有如下形式的名字 DeviceDeviceName，這被系統用來識別和定位它們。應用可以使用 CreateFile API 函數來打開一個有上述名字的文件，獲得一個可以用於和設備交互的句柄。

然而，通常只有 PDO 有自己的名字。未命名的設備能夠通過設備級介面來訪問。設備驅動註冊一個或多個介面，以 128 位全局唯一標識符（GUID）來標示它們。用戶應用能夠使用已知的 GUID 來獲取一個設備的句柄。

在 Linux 上註冊設備

在 Linux 平台上，用戶應用通過文件系統入口訪問設備，它通常位於 /dev 目錄。在模塊初始化的時候，它通過調用內核函數 register_chrdev 創建了所有需要的入口。應用可以發起 open 系統調用來獲取一個文件描述符來與設備進行交互。這個調用後來被發送到回調函數，這個調用（以及將來對該返回的文件描述符的進一步調用，例如 read、write 或close）會被分配到由該模塊安裝到 file_operations 或者 block_device_operations這樣的數據結構中的回調函數。

設備驅動模塊負責分配和保持任何需要用於操作的數據結構。傳送進文件系統回調函數的 file 結構有一個 private_data 欄位，它可以被用來存放指向具體驅動數據的指針。塊設備和網路介面 API 也提供類似的欄位。

雖然應用使用文件系統的節點來定位設備，但是 Linux 在內部使用一個 主設備號 （ major numbers ） 和 次設備號 （ minor numbers ） 的概念來識別設備及其驅動。主設備號被用來識別設備驅動，而次設備號由驅動使用來識別它所管理的設備。驅動為了去管理一個或多個固定的主設備號，必須首先註冊自己或者讓系統來分配未使用的設備號給它。

目前，Linux 為 主次設備對 （ major-minor pairs ） 使用一個 32 位的值，其中 12 位分配主設備號，並允許多達 4096 個不同的設備。主次設備對對於字元設備和塊設備是不同的，所以一個字元設備和一個塊設備能使用相同的設備對而不導致衝突。網路介面是通過像 eth0 的符號名來識別，這些又是區別於主次設備的字元設備和塊設備的。

2.3. 交換數據

Linux 和 Windows 都支持在用戶級應用程序和內核級驅動程序之間傳輸數據的三種方式：

• 緩衝型輸入輸出 （ Buffered Input-Output ） 它使用由內核管理的緩衝區。對於寫操作，內核從用戶空間緩衝區中拷貝數據到內核分配的緩衝區，並且把它傳送到設備驅動中。讀操作也一樣，由內核將數據從內核緩衝區中拷貝到應用提供的緩衝區中。
• 直接型輸入輸出 （ Direct Input-Output ） 它不使用拷貝功能。代替它的是，內核在物理內存中釘死一塊用戶分配的緩衝區以便它可以一直留在那裡，以便在數據傳輸過程中不被交換出去。
• 內存映射 （ Memory mapping ） 它也能夠由內核管理，這樣內核和用戶空間應用就能夠通過不同的地址訪問同樣的內存頁。

Windows 上的驅動程序 I/O 模式

支持緩衝型 I/O 是 WDM 的內置功能。緩衝區能夠被設備驅動通過在 IRP 結構中的 AssociatedIrp.SystemBuffer 欄位訪問。當需要和用戶空間通訊的時候，驅動只需從這個緩衝區中進行讀寫操作。

Windows 上的直接 I/O 由 內存描述符列表 （ memory descriptor lists ） （MDL）介導。這種半透明的結構是通過在 IRP 中的 MdlAddress 欄位來訪問的。它們被用來定位由用戶應用程序分配的緩衝區的物理地址，並在 I/O 請求期間釘死不動。

在 Windows 上進行數據傳輸的第三個選項稱為 METHOD_NEITHER。 在這種情況下，內核需要傳送用戶空間的輸入輸出緩衝區的虛擬地址給驅動，而不需要確定它們有效或者保證它們映射到一個可以由設備驅動訪問的物理內存地址。設備驅動負責處理這些數據傳輸的細節。

Linux 上的驅動程序 I/O 模式

Linux 提供許多函數例如，clear_user、copy_to_user、strncpy_from_user 和一些其它的用來在內核和用戶內存之間進行緩衝區數據傳輸的函數。這些函數保證了指向數據緩存區指針的有效，並且通過在內存區域之間安全地拷貝數據緩衝區來處理數據傳輸的所有細節。

然而，塊設備的驅動對已知大小的整個數據塊進行操作，它可以在內核和用戶地址區域之間被快速移動而不需要拷貝它們。這種情況是由 Linux 內核來自動處理所有的塊設備驅動。塊請求隊列處理傳送數據塊而不用多餘的拷貝，而 Linux 系統調用介面來轉換文件系統請求到塊請求中。

最終，設備驅動能夠從內核地址區域分配一些存儲頁面（不可交換的）並且使用 remap_pfn_range 函數來直接映射這些頁面到用戶進程的地址空間。然後應用能獲取這些緩衝區的虛擬地址並且使用它來和設備驅動交流。

3. 設備驅動開發環境

3.1. 設備驅動框架

Windows 驅動程序工具包

Windows 是一個閉源操作系統。Microsoft 提供 Windows 驅動程序工具包以方便非 Microsoft 供應商開發 Windows 設備驅動。工具包中包含開發、調試、檢驗和打包 Windows 設備驅動等所需的所有內容。

Windows 驅動模型 （ Windows Driver Model ） （WDM）為設備驅動定義了一個乾淨的介面框架。Windows 保持這些介面的源代碼和二進位的兼容性。編譯好的 WDM 驅動通常是前向兼容性：也就是說，一個較舊的驅動能夠在沒有重新編譯的情況下在較新的系統上運行，但是它當然不能夠訪問系統提供的新功能。但是，驅動不保證後向兼容性。

Linux 源代碼

和 Windows 相對比，Linux 是一個開源操作系統，因此 Linux 的整個源代碼是用於驅動開發的 SDK。沒有驅動設備的正式框架，但是 Linux 內核包含許多提供了如驅動註冊這樣的通用服務的子系統。這些子系統的介面在內核頭文件中描述。

儘管 Linux 有定義介面，但這些介面在設計上並不穩定。Linux 不提供有關前向和後向兼容的任何保證。設備驅動對於不同的內核版本需要重新編譯。沒有穩定性的保證可以讓 Linux 內核進行快速開發，因為開發人員不必去支持舊的介面，並且能夠使用最好的方法解決手頭的這些問題。

當為 Linux 寫 樹內 （ in-tree ） （指當前 Linux 內核開發主幹）驅動程序時，這種不斷變化的環境不會造成任何問題，因為它們作為內核源代碼的一部分，與內核本身同步更新。然而，閉源驅動必須單獨開發，並且在 樹外 （ out-of-tree ） ，必須維護它們以支持不同的內核版本。因此，Linux 鼓勵設備驅動程序開發人員在樹內維護他們的驅動。

3.2. 為設備驅動構建系統

Windows 驅動程序工具包為 Microsoft Visual Studio 添加了驅動開發支持，並包括用來構建驅動程序代碼的編譯器。開發 Windows 設備驅動程序與在 IDE 中開發用戶空間應用程序沒有太大的區別。Microsoft 提供了一個企業 Windows 驅動程序工具包，提供了類似於 Linux 命令行的構建環境。

Linux 使用 Makefile 作為樹內和樹外系統設備驅動程序的構建系統。Linux 構建系統非常發達，通常是一個設備驅動程序只需要少數行就產生一個可工作的二進位代碼。開發人員可以使用任何 IDE，只要它可以處理 Linux 源代碼庫和運行 make ，他們也可以很容易地從終端手動編譯驅動程序。

3.3. 文檔支持

Windows 對於驅動程序的開發有良好的文檔支持。Windows 驅動程序工具包包括文檔和示例驅動程序代碼，通過 MSDN 可獲得關於內核介面的大量信息，並存在大量的有關驅動程序開發和 Windows 底層的參考和指南。

Linux 文檔不是描述性的，但整個 Linux 源代碼可供驅動開發人員使用緩解了這一問題。源代碼樹中的 Documentation 目錄描述了一些 Linux 的子系統，但是有幾本書介紹了關於 Linux 設備驅動程序開發和 Linux 內核概覽，它們更詳細。

Linux 沒有提供設備驅動程序的指定樣本，但現有生產級驅動程序的源代碼可用，可以用作開發新設備驅動程序的參考。

3.4. 調試支持

Linux 和 Windows 都有可用於追蹤調試驅動程序代碼的日誌機制。在 Windows 上將使用 DbgPrint 函數，而在 Linux 上使用的函數稱為 printk。然而，並不是每個問題都可以通過只使用日誌記錄和源代碼來解決。有時斷點更有用，因為它們允許檢查驅動代碼的動態行為。互動式調試對於研究崩潰的原因也是必不可少的。

Windows 通過其內核級調試器 WinDbg 支持互動式調試。這需要通過一個串列埠連接兩台機器：一台計算機運行被調試的內核，另一台運行調試器和控制被調試的操作系統。Windows 驅動程序工具包包括 Windows 內核的調試符號，因此 Windows 的數據結構將在調試器中部分可見。

Linux 還支持通過 KDB 和 KGDB 進行的互動式調試。調試支持可以內置到內核，並可在啟動時啟用。之後，可以直接通過物理鍵盤調試系統，或通過串列埠從另一台計算機連接到它。KDB 提供了一個簡單的命令行界面，這是唯一的在同一台機器上來調試內核的方法。然而，KDB 缺乏源代碼級調試支持。KGDB 通過串列埠提供了一個更複雜的介面。它允許使用像 GDB 這樣標準的應用程序調試器來調試 Linux 內核，就像任何其它用戶空間應用程序一樣。

4. 設備驅動分發

4.1. 安裝設備驅動

在 Windows 上安裝的驅動程序，是由被稱為為 INF 的文本文件描述的，通常存儲在 C:WindowsINF 目錄中。這些文件由驅動供應商提供，並且定義哪些設備由該驅動程序服務，哪裡可以找到驅動程序的二進位文件，和驅動程序的版本等。

當一個新設備插入計算機時，Windows 通過查看已經安裝的驅動程序並且選擇適當的一個載入。當設備被移除的時候，驅動會自動卸載它。

在 Linux 上，一些驅動被構建到內核中並且保持永久的載入。非必要的驅動被構建為內核模塊，它們通常是存儲在 /lib/modules/kernel-version 目錄中。這個目錄還包含各種配置文件，如 modules.dep，用於描述內核模塊之間的依賴關係。

雖然 Linux 內核可以在自身啟動時載入一些模塊，但通常模塊載入由用戶空間應用程序監督。例如，init 進程可能在系統初始化期間載入一些模塊，udev 守護程序負責跟蹤新插入的設備並為它們載入適當的模塊。

4.2. 更新設備驅動

Windows 為設備驅動程序提供了穩定的二進位介面，因此在某些情況下，無需與系統一起更新驅動程序二進位文件。任何必要的更新由 Windows Update 服務處理，它負責定位、下載和安裝適用於系統的最新版本的驅動程序。

然而，Linux 不提供穩定的二進位介面，因此有必要在每次內核更新時重新編譯和更新所有必需的設備驅動程序。顯然，內置在內核中的設備驅動程序會自動更新，但是樹外模塊會產生輕微的問題。 維護最新的模塊二進位文件的任務通常用 DKMS 來解決：這是一個當安裝新的內核版本時自動重建所有註冊的內核模塊的服務。

4.3. 安全方面的考慮

所有 Windows 設備驅動程序在 Windows 載入它們之前必須被數字簽名。在開發期間可以使用自簽名證書，但是分發給終端用戶的驅動程序包必須使用 Microsoft 信任的有效證書進行簽名。供應商可以從 Microsoft 授權的任何受信任的證書頒發機構獲取 軟體出版商證書 （ Software Publisher Certificate ） 。然後，此證書由 Microsoft 交叉簽名，並且生成的交叉證書用於在發行之前簽署驅動程序包。

Linux 內核也能配置為在內核模塊被載入前校驗簽名，並禁止不可信的內核模塊。被內核所信任的公鑰集在構建時是固定的，並且是完全可配置的。由內核執行的檢查，這個檢查嚴格性在構建時也是可配置的，範圍從簡單地為不可信模塊發出警告，到拒絕載入有效性可疑的任何東西。

5. 結論

如上所示，Windows 和 Linux 設備驅動程序基礎設施有一些共同點，例如調用 API 的方法，但更多的細節是相當不同的。最突出的差異源於 Windows 是由商業公司開發的封閉源操作系統這個事實。這使得 Windows 上有好的、文檔化的、穩定的驅動 ABI 和正式框架，而在 Linux 上，更多的是源代碼做了一個有益的補充。文檔支持也在 Windows 環境中更加發達，因為 Microsoft 具有維護它所需的資源。

另一方面，Linux 不會使用框架來限制設備驅動程序開發人員，並且內核和產品級設備驅動程序的源代碼可以在需要的時候有所幫助。缺乏介面穩定性也有其作用，因為它意味著最新的設備驅動程序總是使用最新的介面，內核本身承載較小的後向兼容性負擔，這帶來了更乾淨的代碼。

了解這些差異以及每個系統的具體情況是為您的設備提供有效的驅動程序開發和支持的關鍵的第一步。我們希望這篇文章對 Windows 和 Linux 設備驅動程序開發做的對比，有助於您理解它們，並在設備驅動程序開發過程的研究中，將此作為一個偉大的起點。

via: http://xmodulo.com/linux-vs-windows-device-driver-model.html

作者：Dennis Turpitka 譯者：FrankXinqi &YangYang 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive