1 / 50

PNP&Power Management&WMI

PNP&Power Management&WMI. sigang@mti.xidian.edu.cn. Plug and play. 與 Hot plug 不一樣 沒有什麼跳線，開關之類，不會引起資源衝突，因為資源不再是驅動程式自己配置，而是即插即用 (Plug and Play -- PnP) 管理器自動配置。 PNP 管理器使用主功能碼為 IRP_MJ_PNP 的 IRP 與設備驅動程式交換訊息和請求 這種類型的請求是新引入 WDM 中的，在以前的驅動程式中，大部分檢測和配置設備的工作由設備驅動程式自己做。而 WDM 驅動程式可以讓 PnP 管理器做這個工作。

oria
Download Presentation

PNP&Power Management&WMI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PNP&Power Management&WMI sigang@mti.xidian.edu.cn

  2. Plug and play • 與Hot plug 不一樣 • 沒有什麼跳線，開關之類，不會引起資源衝突，因為資源不再是驅動程式自己配置，而是即插即用(Plug and Play -- PnP)管理器自動配置。 • PNP管理器使用主功能碼為IRP_MJ_PNP的IRP與設備驅動程式交換訊息和請求 • 這種類型的請求是新引入WDM中的，在以前的驅動程式中，大部分檢測和配置設備的工作由設備驅動程式自己做。而WDM驅動程式可以讓PnP管理器做這個工作。 • 為了與PnP管理器協同工作，驅動程式需要處理一些相關的IRP。 PNP&PM&WMI.doc

  3. PnP請求在WDM中的作用 • PnP請求指示驅動程式何時以及如何配置或取消其硬體或自身的設置 。有三個對過濾器驅動程式或功能驅動程式特別重要。PnP管理器使用IRP_MN_START_DEVICE來通知功能驅動程式其硬體被賦予了什麼I/O資源，以及指導功能驅動程式做任何必要的硬體或軟體設置以便設備能正常工作。IRP_MN_STOP_DEVICE告訴功能驅動程式關閉設備。IRP_MN_REMOVE_DEVICE告訴功能驅動程式關閉設備並釋放與之關聯的設備對象

  4. PnP請求在WDM中的作用 • PnP請求指導驅動程式完成一系列狀態轉換，如圖所示。WORKING和STOPPED是設備的兩個基本狀態。當創建設備對象后，設備就立即進入STOPPED狀態。WORKING狀態指出設備是全部可操作的。此外，還有兩個中間狀態，PENDINGSTOP和PENDINGREMOVE，它們出現下WORKING狀態前。SURPRISEREMOVED發生在物理硬體突然被移去的情況下。

  5. 處理IRP_MJ_PNP 的分發函數 • 使用函數指針表 • 使用switch case語句

  6. 啟動設備IRP_MN_START_DEVICE • 當PnP管理器檢測到硬體時，它首先參考註冊表以了解有哪些過濾器驅動程式將管理該硬體 ，如果必要，它將裝入這些驅動程式，並調用它們的AddDevice函數。最後AddDevice函數創建設備對象並連入設備堆棧。此后，PnP管理器將為所有設備驅動程式分發I/O資源。 • PnP管理器為每個設備創建一個資源需求列表並允許驅動程式過濾這個列表，或者對它進行更改。通常的驅動程式不用處理這個資源需求列表。透過需求列表，PnP管理器在分發資源時能協調當前系統中所有硬體的潛在資源衝突。

  7. 啟動設備 • 一旦資源分發確定，PnP管理器透過向每個設備發送一個帶IRP_MN_START_DEVICE副功能碼的PnP請求來通知設備。 • 通常過濾器驅動程式對這個IRP不感興趣，所以它們使用DefaultPnpHandler模式把請求向下傳。而功能驅動程式正好相反，它需要在這個IRP上做大量工作，包括分發並配置額外的軟體資源以及為設備操作做準備。這個工作需要在PASSIVE_LEVEL級上進行，並在低層驅動程式處理完該IRP后完成。 • 典型的處理IRP_MN_START_DEVICE 的例程如︰PNP&PM&WMI.doc

  8. 停止設備IRP_MN_STOP_DEVICE • 設備停止請求通知程式關閉設備，然後PnP管理器重新分發I/O資源。 • 在硬體級，關閉設備將包括暫停或停止當前活動並阻止后來的中斷。在軟體級，關閉設備將涉及釋放設備啟動時配置的I/O資源。 • 典型的處理IRP_MN_STOP_DEVICE 的例程如︰PNP&PM&WMI.doc

  9. 移除設備IRP_MN_REMOVE_DEVICE • 開始，PnP管理器透過調用驅動程式中的AddDevice函數來通知程式已經找到要管理的硬體實例，並給一個創建設備對象的機會。當設備將要被系統刪除時，PnP管理器發送副功能碼為IRP_MN_REMOVE_DEVICE的PnP請求。 • 因為系統在發送IRP_MN_REMOVE_DEVICE之前不一定發送IRP_MN_STOP_DEVICE，為了附應這個請求，應該做與IRP_MN_STOP_DEVICE相同事情，關閉設備，然後刪除設備對象 。 • 典型的處理IRP_MN_REMOVE_DEVICE 的例程如︰PNP&PM&WMI.doc

  10. IRP_MN_SURPRISE_REMOVAL • 有時用戶可能不經過任何用戶界面交互操作突然地拆卸設備。如果系統檢測到這種突然的刪除，它就向驅動程式發送副功能碼為IRP_MN_SURPRISE_REMOVAL的PnP請求，后面還會跟著一個IRP_MN_REMOVE_DEVICE請求。 • 除非以前在處理IRP_MN_QUERY_CAPABILITIES時曾設置SurpriseRemovalOK標誌，否則系統將顯示一個對話框，通知用戶這樣做是危險的。 • 我們意外拔出usb設備時可能會得到一個對話框，比如u盤，但是如果是usb鍵盤，可能不會得到。

  11. IRP_MN_SURPRISE_REMOVAL • 為了附應突然刪除請求，設備驅動程式應該禁止所有已註冊的界面。如果應用程式事先關注這種通知，這將給應用程式一個機會關閉設備的句柄。（很多情況下應用程式都會希望在設備被移除時得到一個事件通知，這就是需要驅動程式中調用禁止界面的函數） • 然後驅動程式應釋放I/O資源並向下傳遞請求︰

  12. Power management • WDM驅動程式中電源管理的意義 • 減少電力消耗 • 移動設備電池問題

  13. 電源管理模型 • 在Windows 2000和Windows 98中，作業系統接管了大部分電源管理工作。這是因為只有作業系統才能真正了解電源管理的內部過程。例如，系統BIOS負責的電源管理不能區分應用程式使用的螢幕和螢幕保護程式使用的螢幕之間的區別。但作業系統可以區分開這種不同，從而確定是否可以關閉顯示器。 • 作為計算機全局電源策略，作業系統支持一些用戶界面，用戶可以透過這些界面元素控制最終的電源管理策略。這些用戶界面元素包括控制面板、開始菜單上的命令、控制設備喚醒特徵的API • 透過向設備發送IRP，內核的電源管理部件實現了作業系統的電源策略。WDM驅動程式主要是作為附應這些IRP的被動角色。

  14. WDM驅動程式的角色 • 設備的某個驅動程式充當設備電源策略的管理者。通常都是由功能驅動程式充當這個角色。電源管理器可以改變整個系統的電源狀態。功能驅動程式接收電源管理器發來的IRP(系統IRP)，作為設備電源策略的管理者，功能驅動程式用設備理解的術語翻譯這些IRP並引發新的IRP(設備IRP)。 • 當附應設備IRP時，功能驅動程式需要關心設備專有的細節。設備硬體會有自己的上下文訊息，不應該在設備處于低電源期間丟失這些訊息。例如，鍵盤驅動程式會保存鎖定鍵(如CAPS-LOCK、NUM-LOCK、SCROLL-LOCK)、LED等訊息。功能驅動程式有責任保存並恢復這些上下文訊息。

  15. WDM驅動程式的角色 • 某些設備帶有喚醒特徵，當外部事件發生時，這些設備可以喚醒系統；功能驅動程式應與用戶協同工作以確保喚醒特徵在需要時有效。 • 許多功能驅動程式還管理含有大量IRP的隊列(設備讀寫IRP)，因此當設備電源狀態轉變時需要停止或釋放這些隊列。 • 處于設備堆棧底端的匯流排驅動程式有責任控制設備的電流和執行任何與設備喚醒特徵相關的電氣步驟。 • 過濾器驅動程式通常作為電源管理IRP透過的管道，它們用專用的協議向下層驅動程式傳遞電源管理請求。

  16. 設備電源狀態與系統電源狀態 • WDM模型使用與ACPI(Advanced Configuration and Power Interface)規範相同的術語來描述電源狀態 • 設備能呈現下圖所描述的四種電源狀態。

  17. 設備電源狀態 • 在D0狀態中，設備處于全供電狀態。在D3狀態中，設備處于無供電(或最小限度的電流)狀態。中間的D1和D2狀態指出設備的兩個不同睡眠狀態。隨著設備從D0狀態變化到D3狀態，設備將消耗越來越少的電力，同時需要保留的當前狀態上下文訊息也越來越少。而設備再轉變回D0狀態的延遲期則相應增加。 • Microsoft規定了不同類型設備的類專用電源需求。例如，這個規範要求每個設備至少要支持D0和D3兩個狀態。輸入設備(鍵盤、鼠標等)還應該支持D1狀態。Modem設備需要另外支持D2狀態。設備類上的這些不同規定可能來源于設備的用途和工業上的實踐。 • 作業系統不直接處理設備的電源狀態，由設備驅動程式專門處理

  18. 系統電源狀態 • 系統使用一組與ACPI設備狀態類似的系統電源狀態來控制電源，如下圖。

  19. 系統電源狀態 • Working狀態是全供電狀態，計算機可以實現全部功能。程式僅能在Working狀態下執行。 • 其它系統電源狀態對應更小的電力需求配置，在這些系統電源狀態中，計算機不能執行任何指令。Shutdown狀態就是電源關閉狀態。Hibernate狀態是另一種Shutdown狀態，它把計算機的整個狀態都記錄到硬碟上，因此在電源恢復供電時可以使計算機快速恢復到記錄前的狀態。在Hibernate和Working狀態之間是三個有不同電力消耗級別的中間狀態。

  20. 電源狀態轉換 • 系統初始化后即進入Working狀態。大部分設備也以D0狀態啟動，但某些設備的驅動程式會在設備啟動時使設備進入低電源消耗狀態。在系統啟動並正常營運后，這些設備的驅動程式才使設備進入一個穩定的狀態，在這個狀態中，系統電源處于Working狀態，而設備處于的狀態取決于具體活動和設備自身的能力。

  21. 電源狀態轉換 • 用戶的活動或外部事件會導致電源狀態的改變。 • 一個常見的電源狀態轉換情景是用戶在開始菜單上選擇“關閉系統”中的“等待”選項，使計算機進入等待狀態。 • 在附應這個命令過程中，電源管理器首先向每個驅動程式發送帶有IRP_MN_QUERY_POWER副功能碼的IRP_MJ_POWER請求以詢問設備能否接受即將到來的電源關閉請求。如果所有驅動程式都同意，電源管理器將發送第二個帶有IRP_MN_SET_POWER副功能碼的電源管理IRP，然後驅動程式把其設備置入低電源狀態以附應這個IRP。如果有任何一個驅動程式否決了這個查詢，電源管理器仍舊發出這個IRP_MN_SET_POWER請求，但它使用現下的電源級別。

  22. 電源狀態轉換 • 系統並不總是發送IRP_MN_QUERY_POWER請求。某些事件(如電池電力將要耗盡)必須被無條件接受，並且作業系統也不再發出查詢請求。 • 如果查詢發出后，並且驅動程式也接受了請求的電源狀態，那么驅動程式將不再啟動任何會妨礙未來電源狀態設置請求的操作。例如，卡帶機驅動程式在使一個進入低電源狀態的查詢請求成功返回前先確保當前沒有執行備份操作。另外，該驅動程式還拒絕任何后來的備份命令，除非是另一個電源狀態設置請求。

  23. 處理IRP_MJ_POWER請求 • 電源管理器與驅動程式溝通使用IRP_MJ_POWER類型的IRP • 下表列出了當前可以使用的四個副功能碼。

  24. 處理IRP_MJ_POWER請求 • 所有驅動程式，包括過濾器驅動程式和功能驅動程式通常都向其下面的驅動程式傳遞電源管理請求。唯一的例外是IRP_MN_QUERY_POWER請求。 • IO_STACK_LOCATION的Parameters聯合中的Power子架構有四個參數描述了電源管理請求，但大多數WDM驅動程式僅對其中兩個參數感興趣

  25. 處理IRP_MJ_POWER請求 • 控制如何把電源管理請求傳遞到低級驅動程式有特殊的規則。第一，在釋放一個電源管理請求的控制之前，必須調用PoStartNextPowerIrp，即使以錯誤狀態完成該IRP，也要這樣做。做這個調用的原因是，電源管理器自己需要維持一個電源管理請求隊列，所以必須通知它確實可以出隊一個請求，以及向設備發送下一個請求。除了調用PoStartNextPowerIrp，還必須調用專用例程PoCallDriver(代替IoCallDriver)來向下層驅動程式發送請求。 • 下圖顯示了三種可能的電源請求處理過程。

  26. 處理IRP_MJ_POWER請求 • 下面函數顯示了一個電源管理請求沿設備堆棧被向下傳遞的過程 • NTSTATUS DefaultPowerHandler(IN PDEVICE_OBJECT fdo, IN PIRP Irp) { • PoStartNextPowerIrp(Irp); • IoSkipCurrentIrpStackLocation(Irp); • PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) fdo->DeviceExtension; return PoCallDriver(pdx->LowerDeviceObject, Irp); • }

  27. 處理IRP_MJ_POWER請求 • 功能驅動程式使用兩個步驟來傳遞IRP並執行其設備相關的動作，當進入更低的電源狀態時，它先執行設備相關的步驟，然後向下傳遞請求。當回到更高的電源狀態時，它先向下傳遞請求，然後在完成例程中執行設備相關的步驟。這個巧妙的巢狀操作保證了當驅動程式操作硬體時，硬體一直處于供電狀態。

  28. 處理IRP_MJ_POWER請求 • 電源管理IRP到來時，程式處于一個系統線程的上下文中，不要阻塞這個線程。 • 如果設備有INRUSH特徵，或者清除了設備對象中的DO_POWER_PAGABLE標誌，那么電源管理器將在DISPATCH_LEVEL級上發送IRP。而當執行在DISPATCH_LEVEL級上時，不可能阻塞一個線程。 • 如果設置了DO_POWER_PAGABLE標誌，會在PASSIVE_LEVEL級上收到電源管理IRP，此時，如果在服務一個系統IRP時請求了設備電源管理IRP然後阻塞，將導致死鎖︰電源管理器不會向程式發送設備IRP，除非系統IRP派遣例程返回，因此將永遠等待下去

  29. 處理IRP_MJ_POWER請求 • 功能驅動程式在處理某些電源管理請求時會執行一些耗費時間的步驟。DDK指出，可以在用戶不易察覺的範圍內延遲電源管理IRP的完成，但是能夠延遲並不意味著能夠阻塞。在這些操作完成時，不能阻塞意味著需要使用完成例程來使這些步驟異步。 • 對IRP_MN_QUERY_POWER查詢可以回答“Yes”或“No”。即可以失敗該IRP。失敗該IRP就是說“No”。但對于IRP_MN_SET_POWER請求卻沒有這樣的自由︰必須執行它攜帶的指令。

  30. 管理電源狀態轉換 • 設備可以有喚醒系統的能力。設備可以決定成功還是失敗一個查詢，決定由哪個設備電源狀態來對應新系統電源狀態，這些都取決于設備當前是否使用了喚醒特徵。 • 可以在沒有任何活動時關閉設備的電源供應，當有IRP到來時再恢復設備的電源供應。也許設備是一個“INRUSH”設備，這種設備在上電時需要大的電流，因此電源管理器需要特殊對待這種設備。 • 道統方法解決query-power和set-power操作時，即用通常的派遣例程和完成例程，需要非常精確的編碼，需要面對許多複雜的原素。因此可以圍繞一個有限狀態機來建立電源管理程式，有限狀態機可以方便地處理異步活動。 • 最開始寫程式對電源管理的IRP處理可以是直接向下發送

  31. WMI (windows management and instrumentation) • Windows 2000支持一種稱為Windows管理診斷(WMI)的機製，用于管理計算機系統 • WBEM(基于Web的企業管理)是一個廣泛的工業標準，而WMI是這個工業標準的Microsoft實現。 • WMI的目標是為系統管理和企業網路中管理數據的描述提供了一個模型，並儘可能獨立于專用API或數據對象模型。這種獨立性促進了能創建、傳輸，和顯示控制數據的獨立系統部件的發展。

  32. WMI • 公用訊息模型(CIM)是由DMTF(Distributed Management Task Force)支持的基于Web的企業管理規範，以前被稱為DMTF。Microsoft命名其CIM實現為“WBEM”，其本質上是“CIM for Windows”。CIM for Windows的內核模式部分稱為“WMI”。為了使CIM被更廣泛地採納，DMTF啟動了一個市場行動並使用WBEM作為CIM的名稱。之后Microsoft重命名其WBEM實現為WMI，並重命名WMI(內核模式部分)為“WMI extensions for WDM”。這就是說，WMI兼容CIM和WBEM規範。

  33. WMI • WDM驅動程式以三種模式適應WMI，第一，WMI通常能附應提取性能數據的請求。第二，各種控制單元應用程式可以使用WMI模式控制設備的通用特徵。第三，WMI提供了一個事件通知機製，允許驅動程式通知應用程式有重要的事件發生。 • 看下圖

  34. WMI • 在WMI模型中，數據和事件被分成了消費者和生產者兩類。數據塊就是抽象類的實例，其概念與C++中的類概念一致。 • 如同C++中的類，WMI類也有數據成員和實現對象行為的方法。 • 數據塊中的內容並不是由WMI指定，而是由數據生產者和數據的使用目的決定的。送往驅動程式的數據最有可能來自管理者本身的操作。而驅動程式發出的數據通常是某種性能的統計數據，這些數據的消費者可能是某個性能監視程式。

  35. WMI • WMI允許存在多重命名空間，每個命名空間中包含的類屬于一個或多個用戶模式生產者。生產者使用平台SDK中公開的COM界面來註冊Windows管理服務(Windows Management Service)。一旦Windows 2000發行，作業系統(包括所有設備驅動程式)將支持一個名為root\cimv2的命名空間，裡麵包含了CIM版本2。在CIMV2命名空間的架構還未確定時，Microsoft決定臨時為設備驅動程式類使用另一個命名空間root\wmi。 • 可以下載WMI tools來查看wmi數據和事件或者幫助調試wmi程式，這些工具包括︰WMI object browser, WMI CIM studio, WMI Event Registration tool, WMI event viwer.

  36. WMI • WDM驅動程式可以作為WMI類實例的生產者。一個描述了驅動程式支持的各種類(驅動程式可以為這些類提供數據)的腳本稱為驅動程式規劃(schema)。可以使用MOF(Managed Object Format)語言定義規劃。系統則維護一個稱為repository的數據字典，它包含了所有已知的規劃定義。如果驅動程式做得正確，系統將在初始化驅動程式時自動把規劃放到repository中。

  37. 規劃 • 一個最簡單的WMI規劃的例子PNP&PM&WMI.doc • 用MOF編譯器編譯這個規劃並產生一個二進製文件，這個文件最後將成為驅動程式可執行文件的一個資源。在驅動程式初始化過程中，有一部分代碼就是告訴WMI生產者這個資源在那裡，以便它能讀取這個規劃並添入到repository。 • 編譯完規劃后，還應該營運WMIMOFCK.EXE工具，在DDK中可以找到該工具，該工具執行檢測以便規劃能與WMI兼容。

  38. WDM驅動程式與WMI • 內核模式驅動程式對WMI的支持主要是基于對主代碼為IRP_MJ_SYSTEM_CONTROL的IRP的支持。為了能接收到這種IRP，必須先註冊這種需求︰ • IoWMIRegistrationControl(fdo, WMI_ACTION_REGISTER); • 註冊調用的恰當時間是在AddDevice例程中，註冊完成后，一旦系統認為可以安全地向驅動程式發送系統控制IRP時，它就向驅動程式發出一個IRP_MJ_SYSTEM_CONTROL請求，以獲得設備的詳細註冊訊息。與註冊調用作用相反的調用應該在RemoveDevice函數中做出︰ • IoWMIRegistrationControl(fdo, 

  39. Minor Function Codes for IRP_MJ_SYSTEM_CONTROL

  40. 一個典型的查詢操作的流程

  41. 用戶模式程式與WMI • WMI使用COM模式支持用戶模式應用程式。透過實現幾個COM界面，Windows管理服務就象消費者與生產者之間的訊息流交易場所。生產者經由某個界面向Windows管理程式註冊它們的存在。消費者透過界面間接地與生產者通信。 • 如果想在用戶模式中訪問WMI訊息，首先需要與一個特殊的命名空間建立連接。在該命名空間的上下文中，可以找到WMI類的實例。可以查詢並設置與該類實例相關的的數據塊，調用它們的方法例程，監視它們生成的事件。

More Related