PowerPoint Presentation by 8g7js2

VIEWS: 8 PAGES: 50

									  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管理器做這個工作。
   為了與PnP管理器協同工作,驅動程式需要處理一些相關
    的IRP。 PNP&PM&WMI.doc
      PnP請求在WDM中的作用
   PnP請求指示驅動程式何時以及如何配置或取消其
    硬體或自身的設置 。有三個對過濾器驅動程式或
    功能驅動程式特別重要。PnP管理器使用
    IRP_MN_START_DEVICE來通知功能驅動程式其
    硬體被賦予了什麼I/O資源,以及指導功能驅動程
    式做任何必要的硬體或軟體設置以便設備能正常
    工作。IRP_MN_STOP_DEVICE告訴功能驅動程式
    關閉設備。IRP_MN_REMOVE_DEVICE告訴功能
    驅動程式關閉設備並釋放與之關聯的設備對象
      PnP請求在WDM中的作用
   PnP請求指導驅動程式完成一系列狀態轉換,
    如圖所示。WORKING和STOPPED是設備的
    兩個基本狀態。當創建設備對象后,設備
    就立即進入STOPPED狀態。WORKING狀態
    指出設備是全部可操作的。此外,還有兩
    個中間狀態,PENDINGSTOP和
    PENDINGREMOVE,它們出現下WORKING
    狀態前。SURPRISEREMOVED發生在物理
    硬體突然被移去的情況下。
    處理IRP_MJ_PNP 的分發函數
   使用函數指針表
   使用switch case語句
    啟動設備IRP_MN_START_DEVICE
   當PnP管理器檢測到硬體時,它首先參考註冊表以
    了解有哪些過濾器驅動程式將管理該硬體 ,如果
    必要,它將裝入這些驅動程式,並調用它們的
    AddDevice函數。最後AddDevice函數創建設備對象
    並連入設備堆棧。此后,PnP管理器將為所有設備
    驅動程式分發I/O資源。
   PnP管理器為每個設備創建一個資源需求列表並允
    許驅動程式過濾這個列表,或者對它進行更改。
    通常的驅動程式不用處理這個資源需求列表。透
    過需求列表,PnP管理器在分發資源時能協調當前
    系統中所有硬體的潛在資源衝突。
             啟動設備
   一旦資源分發確定,PnP管理器透過向每個設備發
    送一個帶IRP_MN_START_DEVICE副功能碼的PnP
    請求來通知設備。
   通常過濾器驅動程式對這個IRP不感興趣,所以它
    們使用DefaultPnpHandler模式把請求向下傳。而功
    能驅動程式正好相反,它需要在這個IRP上做大量
    工作,包括分發並配置額外的軟體資源以及為設
    備操作做準備。這個工作需要在PASSIVE_LEVEL
    級上進行,並在低層驅動程式處理完該IRP后完成。
   典型的處理IRP_MN_START_DEVICE 的例程如︰
    PNP&PM&WMI.doc
            停止設備
       IRP_MN_STOP_DEVICE
   設備停止請求通知程式關閉設備,然後PnP
    管理器重新分發I/O資源。
   在硬體級,關閉設備將包括暫停或停止當
    前活動並阻止后來的中斷。在軟體級,關
    閉設備將涉及釋放設備啟動時配置的I/O資
    源。
   典型的處理IRP_MN_STOP_DEVICE 的例程
    如︰PNP&PM&WMI.doc
             移除設備
      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
     IRP_MN_SURPRISE_REMOVAL
   有時用戶可能不經過任何用戶界面交互操作突然
    地拆卸設備。如果系統檢測到這種突然的刪除,
    它就向驅動程式發送副功能碼為
    IRP_MN_SURPRISE_REMOVAL的PnP請求,后面
    還會跟著一個IRP_MN_REMOVE_DEVICE請求。
   除非以前在處理IRP_MN_QUERY_CAPABILITIES
    時曾設置SurpriseRemovalOK標誌,否則系統將顯
    示一個對話框,通知用戶這樣做是危險的。
   我們意外拔出usb設備時可能會得到一個對話框,
    比如u盤,但是如果是usb鍵盤,可能不會得到。
    IRP_MN_SURPRISE_REMOVAL
   為了附應突然刪除請求,設備驅動程式應
    該禁止所有已註冊的界面。如果應用程式
    事先關注這種通知,這將給應用程式一個
    機會關閉設備的句柄。(很多情況下應用
    程式都會希望在設備被移除時得到一個事
    件通知,這就是需要驅動程式中調用禁止
    界面的函數)
   然後驅動程式應釋放I/O資源並向下傳遞請
    求︰
        Power management
   WDM驅動程式中電源管理的意義
   減少電力消耗
   移動設備電池問題
             電源管理模型
   在Windows 2000和Windows 98中,作業系統接管了大部分
    電源管理工作。這是因為只有作業系統才能真正了解電源
    管理的內部過程。例如,系統BIOS負責的電源管理不能區
    分應用程式使用的螢幕和螢幕保護程式使用的螢幕之間的
    區別。但作業系統可以區分開這種不同,從而確定是否可
    以關閉顯示器。
   作為計算機全局電源策略,作業系統支持一些用戶界面,
    用戶可以透過這些界面元素控制最終的電源管理策略。這
    些用戶界面元素包括控制面板、開始菜單上的命令、控制
    設備喚醒特徵的API
   透過向設備發送IRP,內核的電源管理部件實現了作業系
    統的電源策略。WDM驅動程式主要是作為附應這些IRP的
    被動角色。
         WDM驅動程式的角色
   設備的某個驅動程式充當設備電源策略的管理者。通常都
    是由功能驅動程式充當這個角色。電源管理器可以改變整
    個系統的電源狀態。功能驅動程式接收電源管理器發來的
    IRP(系統IRP),作為設備電源策略的管理者,功能驅動程
    式用設備理解的術語翻譯這些IRP並引發新的IRP(設備IRP)。
   當附應設備IRP時,功能驅動程式需要關心設備專有的細
    節。設備硬體會有自己的上下文訊息,不應該在設備處于
    低電源期間丟失這些訊息。例如,鍵盤驅動程式會保存鎖
    定鍵(如CAPS-LOCK、NUM-LOCK、SCROLL-LOCK)、LED
    等訊息。功能驅動程式有責任保存並恢復這些上下文訊息。
       WDM驅動程式的角色
   某些設備帶有喚醒特徵,當外部事件發生時,這
    些設備可以喚醒系統;功能驅動程式應與用戶協
    同工作以確保喚醒特徵在需要時有效。
   許多功能驅動程式還管理含有大量IRP的隊列(設
    備讀寫IRP),因此當設備電源狀態轉變時需要停
    止或釋放這些隊列。
   處于設備堆棧底端的匯流排驅動程式有責任控制
    設備的電流和執行任何與設備喚醒特徵相關的電
    氣步驟。
   過濾器驅動程式通常作為電源管理IRP透過的管道,
    它們用專用的協議向下層驅動程式傳遞電源管理
    請求。
    設備電源狀態與系統電源狀態
   WDM模型使用與ACPI(Advanced
    Configuration and Power Interface)規範相同的
    術語來描述電源狀態
   設備能呈現下圖所描述的四種電源狀態。
           設備電源狀態
   在D0狀態中,設備處于全供電狀態。在D3狀態中,設備
    處于無供電(或最小限度的電流)狀態。中間的D1和D2狀態
    指出設備的兩個不同睡眠狀態。隨著設備從D0狀態變化到
    D3狀態,設備將消耗越來越少的電力,同時需要保留的當
    前狀態上下文訊息也越來越少。而設備再轉變回D0狀態的
    延遲期則相應增加。
   Microsoft規定了不同類型設備的類專用電源需求。例如,
    這個規範要求每個設備至少要支持D0和D3兩個狀態。輸
    入設備(鍵盤、鼠標等)還應該支持D1狀態。Modem設備需
    要另外支持D2狀態。設備類上的這些不同規定可能來源于
    設備的用途和工業上的實踐。
   作業系統不直接處理設備的電源狀態,由設備驅動程式專
    門處理
         系統電源狀態
   系統使用一組與ACPI設備狀態類似的系統
    電源狀態來控制電源,如下圖。
           系統電源狀態
   Working狀態是全供電狀態,計算機可以實現全部
    功能。程式僅能在Working狀態下執行。
   其它系統電源狀態對應更小的電力需求配置,在
    這些系統電源狀態中,計算機不能執行任何指令。
    Shutdown狀態就是電源關閉狀態。Hibernate狀態是
    另一種Shutdown狀態,它把計算機的整個狀態都
    記錄到硬碟上,因此在電源恢復供電時可以使計
    算機快速恢復到記錄前的狀態。在Hibernate和
    Working狀態之間是三個有不同電力消耗級別的中
    間狀態。
         電源狀態轉換
   系統初始化后即進入Working狀態。大部分
    設備也以D0狀態啟動,但某些設備的驅動
    程式會在設備啟動時使設備進入低電源消
    耗狀態。在系統啟動並正常營運后,這些
    設備的驅動程式才使設備進入一個穩定的
    狀態,在這個狀態中,系統電源處于
    Working狀態,而設備處于的狀態取決于具
    體活動和設備自身的能力。
            電源狀態轉換
   用戶的活動或外部事件會導致電源狀態的改變。
   一個常見的電源狀態轉換情景是用戶在開始菜單上選擇
    “關閉系統”中的“等待”選項,使計算機進入等待狀態。
   在附應這個命令過程中,電源管理器首先向每個驅動程式
    發送帶有IRP_MN_QUERY_POWER副功能碼的
    IRP_MJ_POWER請求以詢問設備能否接受即將到來的電源
    關閉請求。如果所有驅動程式都同意,電源管理器將發送
    第二個帶有IRP_MN_SET_POWER副功能碼的電源管理IRP,
    然後驅動程式把其設備置入低電源狀態以附應這個IRP。
    如果有任何一個驅動程式否決了這個查詢,電源管理器仍
    舊發出這個IRP_MN_SET_POWER請求,但它使用現下的
    電源級別。
           電源狀態轉換
   系統並不總是發送IRP_MN_QUERY_POWER請求。
    某些事件(如電池電力將要耗盡)必須被無條件接受,
    並且作業系統也不再發出查詢請求。
   如果查詢發出后,並且驅動程式也接受了請求的
    電源狀態,那么驅動程式將不再啟動任何會妨礙
    未來電源狀態設置請求的操作。例如,卡帶機驅
    動程式在使一個進入低電源狀態的查詢請求成功
    返回前先確保當前沒有執行備份操作。另外,該
    驅動程式還拒絕任何后來的備份命令,除非是另
    一個電源狀態設置請求。
     處理IRP_MJ_POWER請求
   電源管理器與驅動程式溝通使用
    IRP_MJ_POWER類型的IRP
   下表列出了當前可以使用的四個副功能碼。
Minor Function Code   Description

                      Determines whether prospective
IRP_MN_QUERY_POWER      change in power state can
                        safely occur
                      Instructs driver to change power
IRP_MN_SET_POWER
                         state

                      Instructs bus driver to arm wake-
                         up feature; provides way for
IRP_MN_WAIT_WAKE
                         function driver to know when
                         wake-up -signal occurs

IRP_MN_POWER_SEQUE    Provides optimization for context
  NCE                   saving and restoring
      處理IRP_MJ_POWER請求
   所有驅動程式,包括過濾器驅動程式和功
    能驅動程式通常都向其下面的驅動程式傳
    遞電源管理請求。唯一的例外是
    IRP_MN_QUERY_POWER請求。
   IO_STACK_LOCATION的Parameters聯合中
    的Power子架構有四個參數描述了電源管理
    請求,但大多數WDM驅動程式僅對其中兩
    個參數感興趣
                A context value used internally by the Power
SystemContext
                  Manager

                DevicePowerState or SystemPowerState
Type              (values of POWER_STATE_TYPE
                  enumeration)


                Power state─either a
                  DEVICE_POWER_STATE enumeration
State
                  value or a SYSTEM_POWER_STATE
                  enumeration value

                A code indicating the reason for a transition to
ShutdownType
                  PowerSystem-Shutdown
       處理IRP_MJ_POWER請求
   控制如何把電源管理請求傳遞到低級驅動程式有
    特殊的規則。第一,在釋放一個電源管理請求的
    控制之前,必須調用PoStartNextPowerIrp,即使以
    錯誤狀態完成該IRP,也要這樣做。做這個調用的
    原因是,電源管理器自己需要維持一個電源管理
    請求隊列,所以必須通知它確實可以出隊一個請
    求,以及向設備發送下一個請求。除了調用
    PoStartNextPowerIrp,還必須調用專用例程
    PoCallDriver(代替IoCallDriver)來向下層驅動程式發
    送請求。

   下圖顯示了三種可能的電源請求處理過程。
        處理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);
   }
     處理IRP_MJ_POWER請求
   功能驅動程式使用兩個步驟來傳遞IRP並執
    行其設備相關的動作,當進入更低的電源
    狀態時,它先執行設備相關的步驟,然後
    向下傳遞請求。當回到更高的電源狀態時,
    它先向下傳遞請求,然後在完成例程中執
    行設備相關的步驟。這個巧妙的巢狀操作
    保證了當驅動程式操作硬體時,硬體一直
    處于供電狀態。
      處理IRP_MJ_POWER請求
   電源管理IRP到來時,程式處于一個系統線程的上下文中,
    不要阻塞這個線程。
   如果設備有INRUSH特徵,或者清除了設備對象中的
    DO_POWER_PAGABLE標誌,那么電源管理器將在
    DISPATCH_LEVEL級上發送IRP。而當執行在
    DISPATCH_LEVEL級上時,不可能阻塞一個線程。
   如果設置了DO_POWER_PAGABLE標誌,會在
    PASSIVE_LEVEL級上收到電源管理IRP,此時,如果在服
    務一個系統IRP時請求了設備電源管理IRP然後阻塞,將導
    致死鎖︰電源管理器不會向程式發送設備IRP,除非系統
    IRP派遣例程返回,因此將永遠等待下去
      處理IRP_MJ_POWER請求
   功能驅動程式在處理某些電源管理請求時會執行
    一些耗費時間的步驟。DDK指出,可以在用戶不
    易察覺的範圍內延遲電源管理IRP的完成,但是能
    夠延遲並不意味著能夠阻塞。在這些操作完成時,
    不能阻塞意味著需要使用完成例程來使這些步驟
    異步。
   對IRP_MN_QUERY_POWER查詢可以回答“Yes”
    或“No”。即可以失敗該IRP。失敗該IRP就是說
    “No”。但對于IRP_MN_SET_POWER請求卻沒有
    這樣的自由︰必須執行它攜帶的指令。
          管理電源狀態轉換
   設備可以有喚醒系統的能力。設備可以決定成功還是失敗
    一個查詢,決定由哪個設備電源狀態來對應新系統電源狀
    態,這些都取決于設備當前是否使用了喚醒特徵。
   可以在沒有任何活動時關閉設備的電源供應,當有IRP到
    來時再恢復設備的電源供應。也許設備是一個“INRUSH”
    設備,這種設備在上電時需要大的電流,因此電源管理器
    需要特殊對待這種設備。
   道統方法解決query-power和set-power操作時,即用通常的
    派遣例程和完成例程,需要非常精確的編碼,需要面對許
    多複雜的原素。因此可以圍繞一個有限狀態機來建立電源
    管理程式,有限狀態機可以方便地處理異步活動。
   最開始寫程式對電源管理的IRP處理可以是直接向下發送
     WMI (windows management and
           instrumentation)
   Windows 2000支持一種稱為Windows管理診斷
    (WMI)的機製,用于管理計算機系統
   WBEM(基于Web的企業管理)是一個廣泛的工業標
    準,而WMI是這個工業標準的Microsoft實現。
   WMI的目標是為系統管理和企業網路中管理數據
    的描述提供了一個模型,並儘可能獨立于專用API
    或數據對象模型。這種獨立性促進了能創建、傳
    輸,和顯示控制數據的獨立系統部件的發展。
                 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規範。
            WMI
   WDM驅動程式以三種模式適應WMI,第一,
    WMI通常能附應提取性能數據的請求。第
    二,各種控制單元應用程式可以使用WMI
    模式控制設備的通用特徵。第三,WMI提
    供了一個事件通知機製,允許驅動程式通
    知應用程式有重要的事件發生。
   看下圖
             WMI
   在WMI模型中,數據和事件被分成了消費者和生
    產者兩類。數據塊就是抽象類的實例,其概念與
    C++中的類概念一致。
   如同C++中的類,WMI類也有數據成員和實現對
    象行為的方法。
   數據塊中的內容並不是由WMI指定,而是由數據
    生產者和數據的使用目的決定的。送往驅動程式
    的數據最有可能來自管理者本身的操作。而驅動
    程式發出的數據通常是某種性能的統計數據,這
    些數據的消費者可能是某個性能監視程式。
                         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.
                 WMI
   WDM驅動程式可以作為WMI類實例的生產
    者。一個描述了驅動程式支持的各種類(驅
    動程式可以為這些類提供數據)的腳本稱為
    驅動程式規劃(schema)。可以使用
    MOF(Managed Object Format)語言定義規劃。
    系統則維護一個稱為repository的數據字典,
    它包含了所有已知的規劃定義。如果驅動
    程式做得正確,系統將在初始化驅動程式
    時自動把規劃放到repository中。
              規劃
   一個最簡單的WMI規劃的例子PNP&PM&WMI.doc
   用MOF編譯器編譯這個規劃並產生一個二進製文
    件,這個文件最後將成為驅動程式可執行文件的
    一個資源。在驅動程式初始化過程中,有一部分
    代碼就是告訴WMI生產者這個資源在那裡,以便
    它能讀取這個規劃並添入到repository。
   編譯完規劃后,還應該營運WMIMOFCK.EXE工具,
    在DDK中可以找到該工具,該工具執行檢測以便
    規劃能與WMI兼容。
          WDM驅動程式與WMI
   內核模式驅動程式對WMI的支持主要是基于對主代碼為
    IRP_MJ_SYSTEM_CONTROL的IRP的支持。為了能接收到
    這種IRP,必須先註冊這種需求︰
   IoWMIRegistrationControl(fdo, WMI_ACTION_REGISTER);
   註冊調用的恰當時間是在AddDevice例程中,註冊完成后,
    一旦系統認為可以安全地向驅動程式發送系統控制IRP時,
    它就向驅動程式發出一個IRP_MJ_SYSTEM_CONTROL請求,
    以獲得設備的詳細註冊訊息。與註冊調用作用相反的調用
    應該在RemoveDevice函數中做出︰
   IoWMIRegistrationControl(fdo,
 Minor Function Codes for IRP_MJ_SYSTEM_CONTROL

Minor Function Code          Description
IRP_MN_QUERY_ALL_DATA        Gets all instances of every item in a data block
IRP_MN_QUERY_SINGLE_INSTAN   Gets every item in a single instance of a data
CE                           block
IRP_MN_CHANGE_SINGLE_INSTA   Replaces every item in a single instance of a data
NCE                          block
IRP_MN_CHANGE_SINGLE_ITEM    Changes one item in a data block

IRP_MN_ENABLE_EVENTS         Enables event generation

IRP_MN_DISABLE_EVENTS        Disables event generation
IRP_MN_ENABLE_COLLECTION     Starts collecting “expensive” statistics

IRP_MN_DISABLE_COLLECTION    Stops collecting “expensive” statistics

IRP_MN_REGINFO_EX            Gets detailed registration information

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

								
To top