Windows Debugging之八

I/O系統組件

==================

Windows I/O系統的設計目標就是為以下一些特性的應用程式提供裝置的抽象, 裝置包括硬體裝置和軟體裝置(虛擬設備和邏輯裝置).

• 對跨裝置的共用資源進行統一的安全和命名
• 對於可度量的應用程式, 提供基於IO包的,高效能的非同步支援.
• 允許用進階語言寫驅動程式, 和更容易的在不同機器架構之間遷移.
• 擁有分層能力和擴充能力. 允許另外的驅動透明的修改其他驅動或裝置的行為, 不需要任何對其他驅動或者裝置的修改的分層能力和擴充能力.
• 動態載入和卸載, 這樣驅動程式可以在需要的時候載入, 不需要的時候卸載掉, 不佔系統資源.
• 支援隨插即用, 即系統為新找到的硬體裝置定位並安裝驅動程式, 然後給他們分配硬體所需要的作業系統資源
• 支援電源管理, 所以某些系統中的裝置可以進入省電模式.
• 支援多重可安裝的檔案系統, 包括FAT, CD-ROM檔案系統(CDFS), 統一磁碟格式(universal disk format)UDF, 還有Windows檔案系統(NTFS).
• Windows管理工具的支援,還有可診斷能力, 所以驅動可以通過Windows Management Instrumentation的應用程式來管理.

Windows的IO系統包括許多執行元件(executive components)組成, 見.

• IO管理器是整個IO系統的核心, 它串連應用程式和系統組件到虛擬,邏輯的和物理的裝置上, 它還定義了支援裝置驅動的基礎架構.
• 裝置驅動一般為某種裝置提供IO介面. 裝置驅動接受IO manager傳遞給他們的命令, 然後他們通知IO manager這些命令什麼時候結束. 裝置驅動經常使用IO manager來forward IO命令給其他的裝置驅動, 這些裝置驅動是在裝置介面或控制中共用的.
• PnP管理器與IO管理器還有一種叫做bus driver的裝置驅動結合的十分緊密, bus driver是用來知道硬體資源分派, 還有檢測並響應硬體裝置的加入和移除的. 當一個裝置加入到系統中, 他還沒有恰當的裝置驅動的時候, 執行隨插即用的組件調用使用者態的PnP管理器的裝置安裝服務.
• 電源管理器也和IO管理器結合的很緊, 他們兩個一起指導系統和單個的裝置驅動程式如何執行電源狀態的轉換.
• Windows Management Instrumentation (WMI) 支援叫做Windows Driver Model (WDM)的WMI provider函數, 允許裝置驅動間接的像provider一樣的工作, 在使用者台下, 允許裝置驅動可以像媒介一般的使用WDM WMI provider來與WMI服務通訊.
• 註冊表像一個資料庫一樣的存貯附著在系統上的基本硬體裝置的描述資訊, 還有驅動初始化設定以及配置設定.
• INF檔案, 也就是以.inf為尾碼的檔案, 是驅動安裝檔案. INF檔案將特定的硬體裝置和假設為裝置首要控制的驅動相聯絡. 它們組成了類似指令碼的指令來描述1, 相關的裝置; 2. 驅動檔案的源位置和目標位置; 3. 必須的關於驅動安裝的註冊表修改; 4. 裝置依賴關係資訊. Windows 使用數位簽章來驗證驅動程式是否通過了微軟硬體品質實驗室的測試. 數位簽章存在.cat檔案中.
• 硬體抽象層, 使驅動程式同特定的處理器和中斷控制器隔離開來, 從而屏蔽了他們的細節, 這樣可以隱藏不同平台之間的區別. 本質上來說, HAL是所有電腦母板上的, 不被其他裝置控制的, 裝置們的bus driver

 

I/O系統的結構和模式

================

在Windows中, 線程對虛擬檔案執行IO操作. 作業系統將所有的IO請求都抽象為在一個虛擬檔案上的操作., 隱藏了IO操作的對象可能並不是一個檔案結構的裝置的事實. 這抽象產生了應用程式對裝置的介面. 一個virtual file指的是: 對任何的源或者目的IO裝置來說, 線程就當他們是一個檔案(檔案啦, 目錄啦, 管道啦, 郵件槽啦). 所有的讀或者寫的資料都被看作是簡單的面向這些虛擬檔案的位元組流. 使用者態應用程式調用文檔記錄的函數, 他們依次調用內部的IO系統函數來從檔案中讀取資料, 向檔案中寫入資料, 或者執行其他的操作. IO管理器動態檢測這些虛擬檔案的請求, 並執行到恰當的裝置驅動上.

下面是典型IO請求過程的基本架構.

 

 

IO管理器

-------------

IO管理器定義了有秩序的架構, 在這個架構中IO請求會被傳遞給裝置驅動. IO系統是packet driven(封包驅動)的. 多數的IO請求都由IO request packet(IRP)表示, IRP可以在多個IO系統組件中間流動. Fast IO是一個例外, 他不使用IRP. 設計允許一個應用程式線程並發的處理多個IO請求. 一個IRP是一個資料結構, 包含描述IO請求的完整資訊.

 

IO管理器建立代表IO請求的IRP, 傳遞IRP的指標給正確的驅動, 然後在io操作結束之後析構掉這個IRP包. 對比的, 驅動程式接受IRP包, 執行IRP指定的操作, 將IRP包傳回給io管理器, 要麼是操作成功了而傳回, 要不是準備傳遞給另外一個驅動程式去作進一步的處理.

 

關於建立和析構IRP, IO管理器提供代碼, 這些代碼對於不同的驅動程式來說是常見的, 所有的驅動都調用這些函數來執行他們的IO處理. 通過加強了的IO管理器的普通任務, 個別的驅動變得更簡單, 更精簡. 比如說, io管理器提供一個函數, 允許一個驅動程式去調用另一個驅動程式. 它也管理IO請求的緩衝, 對驅動和記錄提供逾時支援, 這裡的記錄指的是被可安裝的檔案系統被載入到作業系統中的時候的記錄. 有進百個不同的IO管理器的函數可以被驅動程式調用.

 

IO管理器還提供靈活的IO服務, 這些服務允許環境子系統比如Win32和POSIX來實現各自的IO函數. 這些服務包括成熟的對非同步IO的服務, 非同步IO服務允許開發人員建立可度量的高效能的伺服器應用程式.

 

驅動程式展現出的統一的, 模組化的介面, 允許IO管理器調用任何的驅動程式而不需要知道關於這個驅動的具體資訊和內部實現的細節. 如同我們之前提到的, 作業系統對待所有的IO請求都看做是一個操作一個檔案. 驅動將給虛擬檔案的請求轉換為對物理裝置的請求. 驅動程式也可以調用彼此來實現分層的, 獨立的IO請求處理.

 

除了正常的開啟, 關閉, 讀, 寫功能之外, Windows IO系統還提供許多進階的特性, 比如非同步處理啦, 緩衝啦, scatter/gather IO.