windows的裝置驅動框架中的上層與下層模組
在windows的裝置驅動框架中，下層模組向上層模組提供乙個資料結構指標。但是，上層模組並不直接從這個資料結構獲取具體的函式指標，更不直接使用這些函式指標呼叫下層模組中的函式；而是通過一些由核心提供的函式下達「i/o請求包」即irp，間接地呼叫下層模組提供的函式，要求其執行某種操作。這就好像是向核心下乙個定單，定單中告訴核心要由哪乙個下層模組執行何種操作。另一方面，對於建立了形式「堆疊」的裝置驅動，上層模組在執行中通常也沒有如何「找到」下層模組的問題，甚至根本就不必知道其下一層是什麼模組或什麼裝置，模組之間已在建立形式堆疊的時候固定連線好了。此時上層模組所獲得的是哪乙個下層模組的指標，取決於同乙個堆疊中各個模組的裝載次序，實際上取決於系統的配置，而相關的配置資訊則最終來自相關的.inf檔案，這些資訊儲存在集中的資料庫「登錄檔（registry）」中。這樣就為通過系統配置改變具體裝置驅動堆疊的結構提供了更大的靈活性，主要體現在：
更容易在堆疊的下層實現「重定向」，即把上層模組嫁接到不同的下層模組上；
更容易在堆疊內部插入以「過濾驅動物件（fido）」為代表的「過濾模組」。
最後，裝置驅動模組不是在真空中執行，需要得到核心的支援，需要由核心為其構築起乙個執行環境，這個環境的主體就是核心匯出函式，此外還有一些全域性的變數和資料結構。這就是windows的「裝置驅動開發包」ddk中所定義（更準確地說是「宣告」）的函式和變數。
事物都是在發展的，windows的裝置驅動框架也不是一開始就這樣，更不是永遠這樣。前面所講的是為實現「即插即用」所必須要有的要素，主要就是模組的動態裝載以及模組堆疊的形成。有了這些要素，包括即插即用在內的分層裝置驅動就可以實現了，但是當然還可以有一些附加的要求。從windows 98和windows 2000開始，微軟定義了一種（在當時是）新的裝置驅動框架，稱為wdm即「windows裝置驅動模型（windows driver model）」。wdm要求裝置驅動模組除滿足pnp的需要外，還必須提供兩方面的功能支援：
對於wmi的支援。wmi是「windows管理手段（windows management instrumentation）」的縮寫。wmi與「簡單網路管理規程」snmp相似，要求每台windows主機都能應「管理器（manager）」的要求提供包括裝置驅動在內的各種狀態和統計資訊。這些資訊從哪兒來呢？對於裝置驅動，當然得要由相應的裝置驅動模組提供。
對於電源管理的支援。有些外設能耗不小，如果有一段較長的時間沒有實際使用，就沒有理由不將其轉入某種「省電模式」。即使是能耗不大的外設，在節能成為乙個環保問題的今天，也應該在不用時使其轉入省電模式。這就是電源管理要達到的目的之一。所以，微軟把支援電源管理列為wdm的要素之一。
總之，「老式」的裝置驅動（在形式上）是不分層、不堆疊的；如果形式上分層並堆疊，在微軟的術語中就稱為「pnp裝置驅動」。而wdm裝置驅動，則是至少在形式上滿足了上述兩項附加條件的pnp裝置驅動。對wmi的支援和電源管理的重要性當然不容低估，但是對於我們理解windows的裝置驅動框架卻並非技術關鍵，所以後面的敘述將集中在框架的構成與實現，而忽略這兩個方面。正因為這樣，我們將稱之為「windows裝置驅動框架」而不是「wdm」，以免混淆。
Windows的裝置驅動框架
windows的裝置驅動框架 windows核心管理層的部件之一是i o管理模組，有時候也稱為i o子系統。i o管理模組所管理的物件與活動縱向貫穿管理層 核心層乃至hal層，所以稱之為子系統其實也有道理。i o管理的主體就是我們所說的裝置驅動。很自然地，如果我們沿著縱向考察某項裝置的驅動，則一般而...
Windows的裝置驅動框架中的上層與下層模組
windows的裝置驅動框架中的上層與下層模組 在windows的裝置驅動框架中，下層模組向上層模組提供乙個資料結構指標。但是，上層模組並不直接從這個資料結構獲取具體的函式指標，更不直接使用這 些函式指標呼叫下層模組中的函式 而是通過一些由核心提供的函式下達 i o請求包 即irp，間接地呼叫下層模...
platform裝置驅動框架
這裡簡單總結下platform匯流排的裝置驅動 的框架。1 建立資料夾platform 2 在資料夾下編寫裝置檔案device.c include include include include include include module author wjb module license dua...