个处理IRP的模型.ppt

8個處理IRP的模型,,一.設置完成例程然後向下發送,從其它的組件或者驅動程式得到一個IRP，需要低層驅動程式先進行處理，然後自己還需要處理。如下頁圖 使用時的必備條件1.從其它的組件或者驅動程式得到一個IRP，而不是自己創建的。2.這個IRP在DISPATCH_LEVEL 上獲得或者在一個任意的上下文環境下處理，因此在底層處理這個IRP時不能夠阻塞。3.后期的處理代碼可以營運在DISPATCH_LEVEL上，因為有些完成例程在DISPATCH_LEVEL級執行。,設置完成例程然後向下傳送,可能的分發例程和完成函數代碼架構都差不多。 例如IRP處理.doc,二.直接向下發送,從其它的組件或者驅動程式得到一個IRP，需要低層驅動程式進行處理，不關心低層驅動程式的處理結果。如下頁圖 使用時的必備條件 1.從其它的組件或者驅動程式得到一個IRP，而不是自己創建的 2.自己不關心這個IRP，不需要進行后期處理,說明,上面這種模型使用做多的情況就是在過濾驅動程式裡面，通常過濾驅動程式在處理不關心的IRP時使用上面的模型，有些WMI和PNP以及電源請求的處理也採用這種模型。 通常可以寫一個輔助函數來實現這種模型IRP處理.doc,三.直接在分發例程裡面完成,從其它的組件或者驅動程式得到一個IRP，直接在分發例程裡面完成這個IRP，如下頁圖 使用時的必備條件 1.從其它的組件或者驅動程式得到一個IRP，而不是自己創建的。2.可以在分發例程裡面立刻完成，比如取得簡單的訊息。3.這個IRP出現了錯誤，這時立刻以錯誤狀態返回。 IRP處理.doc,四.排隊IRP，后面處理,從其它的組件或者驅動程式得到一個IRP，需要排隊（標準模型或者自己的隊列），后面進行處理。如下頁圖 使用時的必備條件 1.從其它的組件或者驅動程式得到一個IRP，而不是自己創建的 2.不知道是立即處理還是排隊，這通常發生在需要串行訪問硬體的情況。 通常的程式框架如下IRP處理.doc,五.自己創建的異步IRP,自己創建異步IRP，並且向某個驅動程式發送。如下頁圖 使用時的必備條件1.需要某個驅動程式替自己實現某個功能。2.自己在任意線程上下文，或者在DISPATCH_LEVEL ，這些都使得我們不能阻塞這個線程。 IRP處理.doc,六.自己創建的同步IRP,自己創建同步IRP，並且向某個驅動程式發送。如下頁圖 使用時的必備條件 1.需要某個驅動程式替自己實現某個功能。2.在繼續之前，必須等待操作完成，也就是說是一個同步的請求。3.代碼營運在一個非任意線程上下文，並且代碼的IRQL為PASSIVE_LEVEL 。 IRP處理.doc,同步向下發送,從其它的組件或者驅動程式得到一個IRP，同步的發送到低層驅動程式進行處理，然後繼續處理。如下頁圖 使用時的必備條件 1.從其它的組件或者驅動程式得到一個IRP，而不是自己創建的 2.代碼營運在一個非任意線程上下文，並且代碼的IRQL為PASSIVE_LEVEL 。3.后面對IRP的處理必須也在PASSIVE_LEVEL級 IRP處理.doc,八.同步處理異步IRP,自己創建異步IRP，並且向某個驅動程式發送，然後等待請求的完成。如下頁圖 使用時的必備條件 1.需要某個驅動程式替自己