第八章 I/O系統(第二節1)
一個裝置驅動程式為了與I/O管理器和其他的I/O系統元件整合在一起,必須符合“與它所管理的裝置型別相一致的實現規範”,也要與“它在管理該裝置時所扮演的角色”相符。在本節中,我們來看一看Windows所支援的裝置驅動程式的型別,以及一個裝置驅動程式的內部結構。
裝置驅動程式型別
Windows支援一組範圍廣泛的裝置驅動程式型別和各種程式設計環境。即使在同一種型別的裝置驅動程式的內部,程式設計環境也可能不盡相同,這取決於一個驅動程式所針對的目標裝置的具體型別。對於一個驅動程式,最為寬泛的分類是,它是一個使用者模式驅動程式還是一個核心模式驅動程式。
Windows支援以下幾種型別的使用者模式驅動程式:
■ Windows子系統印表機驅動程式(printer driver)將與裝置無關的圖形請求轉譯成與印表機相關的命令,然後這些命令通常被轉送到一個核心模式的埠驅動程式,比如通用序列匯流排(USB,universal serial bus)印表機埠驅動程式(Usbprint.sys)。
■ 使用者模式驅動程式框架(UMDF,User-Mode Driver Framework)驅動程式是執行在使用者模式的硬體裝置驅動程式,它們通過高階本地過程呼叫(ALPC)與核心模式UMDF支援庫進行通訊。更多資訊見本章後節“使用者模式驅動程式框架(UMDF)”。
在本章,我們將焦點放在核心模式裝置驅動程式上。核心模式的驅動程式有很多種型別,它們可以被劃分為以下基本類別:
■ 檔案系統驅動程式(file system driver)接受針對檔案的I/O請求,然後通過向大容量儲存裝置(mass storage)或網路裝置驅動程式傳送它們自己的、更為顯式的請求,以此來滿足所接收到的I/O請求;
■ 即插即用驅動程式(Plug and Play driver)與硬體一起工作,並與Windows電源管理器和PnP管理器結合起來,它們包含了大容量儲存裝置、視訊介面卡、輸入裝置和網路介面卡的驅動程式;
■ 非即插即用驅動程式(Non-Plug and Play driver)亦包括核心擴充套件在內,是擴充套件了系統功能的驅動程式或模組。由於它們通常不管理實際的硬體,因此並不與PnP管理器或電源管理器結合在一起。這種驅動程式的例子有網路API和協議驅動程式,卷1第4章中講述的程式監視器驅動程式就是這樣一個例子。
在核心模式驅動程式的類別中,還可以進一步根據驅動程式所遵從的驅動程式模型及其在處理裝置請求過程中所處的角色來進行分類。
WDM驅動程式
WDM驅動程式是指遵從Windows驅動程式模型(WDM,Windows Driver Model)的裝置驅動程式。WDM包含了對Windows電源管理、即插即用和WMI的支援,而且,絕大多數即插即用驅動程式都遵從WDM規範。WDM驅動程式有以下三種型別。
■ 匯流排型驅動程式(bus driver)管理一個邏輯的或物理的匯流排。匯流排的例子有PCMCIA、PCI、USB和IEEE 1394.一個匯流排型驅動程式負責檢測所控制的匯流排上附載的裝置,檢測到以後通知PnP管理器,它也管理該匯流排的電源設定;
■ 功能型驅動程式(function driver)管理某一特定型別的裝置。匯流排型驅動程式通過PnP管理器將裝置展示給功能型驅動程式。所謂功能型驅動程式,是指該驅動程式將一個裝置的操作介面匯出給作業系統。一般而言,它是掌握了最多關於該裝置操作知識的驅動程式;
■ 過濾型驅動程式(filter driver)在邏輯上位於功能型驅動程式之上層或下層(稱其為功能型過濾器),或位於匯流排型驅動程式上層(稱其為匯流排型過濾器),增加或者改變一個裝置或另一個驅動程式的行為。例如,一個鍵盤捕獲工具可能是通過一個鍵盤過濾型驅動程式來實現的,該驅動程式位於鍵盤功能型驅動程式之上層。
在WDM中,沒有一個驅動程式負責控制一個特定裝置的所有方面。匯流排型驅動程式負責檢測匯流排上成員的變化(裝置加入或移除),幫助PnP管理器列舉該匯流排上的裝置,訪問與該匯流排有關的配置暫存器,以及在某些情況下,還要控制該匯流排上裝置的電源。功能型驅動程式通常只是一個訪問該裝置硬體的驅動程式而已。
分層的驅動程式
系統對硬體單獨部分的支援通常被分散在幾個驅動程式中,每個驅動程式提供了一部分功能,這些功能只有聯合起來才能使該裝置正確工作。除了WDM匯流排型驅動程式、功能型驅動程式和過濾型驅動程式以外,對硬體的支援也可能在以下的元件之間劃分。
■ 類驅動程式(class driver)實現了某一特定型別裝置的I/O處理,如磁碟、鍵盤或CD-ROM,這些裝置的硬體介面已經標準化了,因此驅動程式可以為來自各生產商的裝置提供服務;
■ 小類驅動程式(miniclass driver)針對某一特定型別裝置,實現生產商定義的I/O處理。例如,雖然Microsoft編寫標準的電池類驅動程式,但是,不間斷電源和筆記本電池都有高度特定的介面,不同的廠商會有很大的差別,因此供應商就需要提供小類驅動程式。小類驅動程式實質上是核心模式動態連結庫(Dll),並不直接進行IRP處理——類驅動程式呼叫它們,它們從類驅動程式中匯入函式;
■ 埠驅動程式(port driver)實現了與某一型別I/O埠相關的I/O請求的處理,比如SATA,它們作為核心模式的函式庫實現,而非真正的裝置驅動程式。埠驅動程式通常由Microsoft編寫,這是因為介面已經標準化了,不同供應商仍可以共享相同的埠驅動程式。然而某些情況下,第三方廠商可能需要為特定的硬體編寫驅動程式。有時候,概念“I/O埠”也擴充套件覆蓋了邏輯埠,比如,NDIS是網路“埠”驅動程式,DxgPort/Videoprt是DirectX/video“埠”驅動程式;
■ 小埠驅動程式(Miniport driver)將“針對一種型別埠的通用I/O請求”對映為一種介面卡型別,比如某種特定的網路介面卡。小埠驅動程式是真正的裝置驅動程式,它們需要匯入(import)一個埠驅動程式所提供的函式。第三方廠商編寫小埠驅動程式,並提供埠驅動程式所需的介面。與小類驅動程式類似,它們是核心模式動態連結庫,並不直接進行IRP處理。
介紹一個簡化示例將有助於說明這些裝置驅動程式是如何工作的。檔案系統驅動程式接受一個“在某個特殊檔案中的特定位置上寫入資料”的請求,它將該請求轉譯成一個“在磁碟的特定‘邏輯’位置上寫入特定數量的位元組”的請求,然後,將此請求(通過I/O管理器)傳遞給一個簡單的磁碟驅動程式,磁碟驅動程式又依次將此請求轉譯成針對該磁碟某一物理位置的請求,並與磁碟通訊進行寫資料。這一層次如圖8-3所示。
圖8-3 一個檔案系統驅動程式和一個磁碟驅動程式的分層
該圖示出了兩個分層的驅動程式之間的分工。I/O管理器接收一個寫請求,此請求相對於一個特定檔案的起始處,I/O管理器將此請求傳遞給檔案系統驅動程式,驅動程式將這個寫操作從一個相對於檔案的操作,轉譯成一個開始位置(磁碟上的一個扇區邊界)和要寫入的位元組數量。檔案系統驅動程式呼叫I/O管理器將此請求傳遞給磁碟驅動程式,然後,磁碟驅動程式將此請求轉譯成一個物理磁碟位置並傳送資料。
因為所有的驅動程式——無論是裝置驅動程式還是檔案系統驅動程式——展示給作業系統的框架都是相同的,所以,另一個驅動程式可以很容易地插入到這一層次結構中,而無需改變已有的驅動程式或者I/O系統。例如,只要加入一個驅動程式就可以讓幾個磁碟變得像一個大的單磁碟那樣工作。這一邏輯的卷管理器驅動程式位於檔案系統驅動程式和磁碟驅動程式之間,圖8-4概念性地示出了簡化架構圖(關於實際儲存驅動程式棧圖,見第9章“儲存管理”的圖9-3),第9章更加詳細地描述了卷管理器驅動程式。
圖8-4 加入一個分層驅動程式
實驗:檢視已載入的驅動程式列表
在“開始”(Start)選單的“執行”(Run)對話方塊中執行Msinfo.exe工具,就可以檢視已註冊驅動程式的列表。在“軟體環境”下選中“系統驅動程式”項,就可以看到當前系統上配置的驅動程式的列表,已被載入的驅動程式在“已啟動”一欄中標明瞭“是”。
你也可以利用Windows Sysinternals(http://www,microsoft.com/technet/sysinternals)的程式管理器(Process Explorer)來檢視已載入的核心模式驅動程式的列表。執行程式管理器,選中“System”程式,從“View”選單的“Lower Pane View”選單項中選擇“Dlls”。程式管理器列出已載入的驅動程式、它們的名稱、包括公司和說明在內的版本資訊,以及載入的地址(假設你已經配置了程式管理器,讓它顯示相應的欄目),如下圖所示:
最後,如果你正在使用核心偵錯程式來檢查一個崩潰轉儲(或實時系統),那麼,通過核心偵錯程式的lm kv命令,你可以得到類似的輸出:
lkd> lm kv
start end module name
82007000 823c0000 nt (pdb symols)
c:\programming\symbols\ntkrpamp.pdb\37D328E3BAE5460F8E662756ED80951D2\ntkrpamp.pdb
Loaded symbol image file:ntkrpamp.exe
Image path:ntkrpamp.exe
Image name:ntkrpamp.exe
Timestamp: Fri Jan 18 21:30:58 2008(47918B12)
CheckSum: 00372038
ImageSize: 003B90000
File version: 6.0.6001.18000
Product version:6.0.6001.18000
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 1.0 App
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® Windows® Operation System
InternalName: ntrpamp.exe
OriginalFilename:ntrpamp.exe
ProductVersion: 6.0.6001.18000
FileVersion: 6.0.6001.18000(longhorn_rtm,080118-1840)
FileDescription: Nt Kernel & System
LegalCopyright: © Microsoft Corporation. All rights reserved.
823c0000 823f3000 hal (deferred)
Image path:halmacpi.dll
Image name:halmacpi.dll
Timestamp: Fri Jan 18 21:41:20 2008(7918D80)
CheckSum: 0006E742
ImageSize: 00071000
Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0
相關文章
- JAVA I/O系統Java
- 系統級 I/O
- 作業系統—I/O 模型作業系統模型
- 系統程式設計 - I/O模型程式設計模型
- Linux命令----分析系統I/O的瓶頸Linux
- 作業系統程式、儲存和I/O作業系統
- Java I/O系統學習系列一:File和RandomAccessFileJavarandomMac
- 計算機I/O與I/O模型計算機模型
- I2C系統框架(1)框架
- Java I/OJava
- I/O流
- 第二十章:非同步和檔案I/O.(一)非同步
- 第二十章:非同步和檔案I/O.(九)非同步
- 第二十章:非同步和檔案I/O.(八)非同步
- 第二十章:非同步和檔案I/O.(十四)非同步
- 第二十章:非同步和檔案I/O.(二)非同步
- 1分鐘掌握Arduino出入輸出口(I/O)UI
- Java I/O系統學習系列二:輸入和輸出Java
- 作業系統I/O模型及輪詢技術演變作業系統模型
- Python教程:精簡概述I/O模型與I/O操作Python模型
- c++ I/OC++
- Java(8)I/OJava
- 關於I/O
- 【java】I/O流Java
- 第二十章:非同步和檔案I/O.(二十三)非同步
- 第二十章:非同步和檔案I/O.(二十一)非同步
- 電商系統O2O商城系統開發
- 佳弗O2O系統
- 效能分析(7)- 未利用系統快取導致 I/O 緩慢案例快取
- 02. I/O 操作
- Hadoop的I/O操作Hadoop
- NodeJs 非同步 I/ONodeJS非同步
- Java 非同步 I/OJava非同步
- 理解I/O Completion Port
- python 非同步 I/OPython非同步
- Google I/O Extend 2018Go
- 網路I/O模型模型
- Linux下的5種I/O模型與3組I/O複用Linux模型
- 如何在Linux系統伺服器中測試儲存/磁碟I/O效能?Linux伺服器