2011年2月28日 星期一

[ Windows DDP ] IRP 的同步 : 插斷服務常式 & DPC 常式

前言 : 
插斷服務常式是裝置觸發插斷後進入的常式. 當進入插斷服務常式後, IRQL 會提升到裝置對應的 IRQL 層級. 這裡將介紹插斷服務常式的概念和編寫方法做簡單介紹. 

插斷操作的必要性 : 
在介紹插斷服務常式之前, 先討論一下插斷操作的必要性. 在早期的 PC 中, 很多裝置都是 "輪詢(Polling)" 裝置. CPU 發出指令去操作裝置時, 操作一般不能迅速完成, 因此 CPU 需要不停地讀取裝置狀態, 從而判斷操作是否結束. 後來出現了 "插斷" 裝置. CPU 發出一個指令操做裝置後, CPU 並不急於知道操作是否已經完畢. 這時候 CPU 可以去做別的事. 當裝置完成操作後, 裝置會向 CPU 發出插斷要求. 插斷要求相當於通知裝置的操作已經完畢. "插斷" 裝置比 "輪詢" 裝置的效率高, 不會浪費太多的 CPU 時間. 
另外插斷要求可以巢狀嵌套. 當 CPU 處理一個低優先順序的插斷時, 它可以被更高優先順序的插斷打斷, 轉而執行優先順序高的插斷處理常式. 當執行完高優先順序的插斷服務常式後, 轉而讓剛被打斷的低優先順序的插斷恢復執行. 

插斷優先順序 : 
傳統 PC 用兩片插斷控制器 (8259A) 晶片層疊, 可以連接 16 個插斷信號. 給個插斷信號分配一個插斷號, 依次從 0~15. 多個裝置可以共用一個插斷號. 新一代的 PC 中使用新的插斷控制器, 並將插斷信號擴充到 24 個. 底下從裝置管理員可以看到插斷編號 : 
 
Windows 將插斷的概念進行了擴充, 擴充為 32 個插斷層級 (IRQL). 其中 0~2 層級, 即 PASSIVE_LEVEL 到 DISPATCH_LEVEL 層級為軟體插斷. 從 3~31 層級為硬體插斷. 優先順序從 0 到 31, 層級逐次升高. 
一般執行緒執行在 PASSIVE_LEVEL 層級, 而負責調度執行緒的內核程式碼執行在 DISPATCH_LEVEL 層級. 如果執行緒希望不要被切換到別的執行緒, 可以將執行緒從 PASSIVE_LEVEL 提升到 DISPATCH_LEVEL 層級. 硬體裝置發出的插斷訊號都是硬體插斷. 硬體插斷的優先順序都高於軟體優先順序, 也就是說執行的執行緒會隨時被硬體插斷打斷. DDK 把硬體插斷稱為 DIRQL. 

插斷服務常式 (ISR) : 
當硬體裝置的插斷信號發生後, IRQL 會提升到對應的 DIRQL 層級, 作業系統會呼叫對應的插斷服務常式 (ISR). 在驅動程式中使用 ISR 首先要獲得插斷物件, 該插斷物件是一個名為 INTERRUPT 的資料結構. 對於 NT 式 DDK 驅動和 WDM 驅動, 得到插斷物件使用不同的方法, 在後面章節會進行介紹. 
DDK 提供內合核函式 IoConnecInterrupt 將插斷物件和 ISR 聯繫起來, 這樣當插斷信號來臨時就會進入 ISR 處理. ISR 執行在 DIRQL 層級, 要高於普通執行緒的優先順序. 自旋鎖只能對 DISPATCH_LEVEL 以下的程式進行同步, 所以這時自旋鎖無法滿足同步的需求. 派遣函式, StartIO 常式隨時會被插斷程式所打斷. 為了不讓 ISR 打斷, 只需將 IRQL 提升到對應的 IRQL 即可. DDK 提供了與 ISR 函式同步的內核函式 KeSynchronizeExecution, 其宣告如下 : 

- Syntax :
  1. BOOLEAN KeSynchronizeExecution(  
  2.   __inout   PKINTERRUPT Interrupt,  
  3.   __in      PKSYNCHRONIZE_ROUTINE SynchronizeRoutine,  
  4.   __in_opt  PVOID SynchronizeContext  
  5. );  

- 參數說明 :
* 參數 Interrupt : 這個參數是插斷物件指標, ISR 和這個物件關聯.
* 參數 SynchronizeRoutine : 將當前 IRQL 提升至插斷物件對應的 DIRQL, 並執行 SynchronizeRoutine 函式.
* 參數 SynchronizeContext : 為 SynchronizeRoutine 提供的參數.

當執行到 KeSynchronizeExecution 的時候, ISR 不會打斷 KeSynchronizeExecution 提供的同步函式, 這需要將同步程式碼放入 KeSynchronizeExecution 提供的同步函式中. 

DPC 常式 : 
DPC 常式一般和插斷服務常式配合使用. 由於插斷服務常式處於很高的 IRQL, 會打斷正常執行的執行緒. 而 DPC 常式執行於相對低的 DISPATCH_LEVEL 層級, 因此一般將不需要緊急處理的程式碼放在 DPC 常式中, 而將需要緊急處理的程式碼放在插斷服務常式中. 
- 延遲程式呼叫常式 (DPC) 
延遲程式呼叫 (DPC) 廣泛應用於驅動程式開發中, 它執行在 DISPATCH_LEVEL 的 IRQL 層級, 因此除了 ISR, 其他的常式是不會將其打斷. 一般來說 ISR 執行時間不宜過長. 如果過長, 插度層級低的程式就無法得到回應, 例如滑鼠, 鍵盤的插斷就不能及時回應. 為了能回應更多的插斷, 應該讓 ISR 程式碼儘量少. 故 DDK 建議將一些不重要的回應程式碼從 ISR 移到 DPC 常式中. 
ISR 會將 DPC 插入一個內部佇列, 這樣當 IRQL 從高恢復到 DISPATCH_LEVEL 時, DPC 會依次從佇列中彈出, 並執行對應的 DPC 常式. 總結就是 ISR 的程式碼應該盡量少, 而將不重要的程式碼放入 DPC 常式中. 

- DpcForISR 
使用 DPC 常式, 首先要初始化 DPC 物件, 該動作使用內核函式 KeInitializeDpc, 其宣告如下 : 

- Syntax :
  1. VOID KeInitializeDpc(  
  2.   __out     PRKDPC Dpc,  
  3.   __in      PKDEFERRED_ROUTINE DeferredRoutine,  
  4.   __in_opt  PVOID DeferredContext  
  5. );  

- 參數說明 :
* 參數 Dpc : 需要初始化的 DPC 物件指標
* 參數 DeferredRoutine : 與 DPC 關聯的 DPC 常式
* 參數 DeferredContext : 傳入 DPC 常式的參數

更多的 DPC 常式使用會在後面章節進行說明. 

補充說明 : 
* [ Windows DDP ] 驅動程式的同步處理 : 插斷要求層級

沒有留言:

張貼留言

[Git 常見問題] error: The following untracked working tree files would be overwritten by merge

  Source From  Here 方案1: // x -----删除忽略文件已经对 git 来说不识别的文件 // d -----删除未被添加到 git 的路径中的文件 // f -----强制运行 #   git clean -d -fx 方案2: 今天在服务器上  gi...