網絡驅動程序編程要點

編寫Windows 2000的任何網絡驅動程序時通常都需要考慮的幾點問題

1 可移植性

2 多處理器支持

3 IRQLs

4 同步和指示

5 包結構

6 使用共享內存

7 異步I/O和完成函數(shù)

1. 可移植性

NDIS驅動程序應很容易在支持Windows 2000的平臺間移植。一般說來，從一個硬件平臺移植到另一個平臺只需要將它在兼容系統(tǒng)的編譯中重新編譯即何。

驅動程序開發(fā)者應當避免調用與操作系統(tǒng)相關的函數(shù)，因為這將使他們的驅動程序不可移植。應用NDIS函數(shù)替換這些調用，只調用NDIS函數(shù)將使代碼在支持NDIS的微軟操作系統(tǒng)中可移植，NDIS為編寫驅動程序提供了很多支持函數(shù)，并且直接調用操作系統(tǒng)是不需要的。

驅動程序應用C來編寫。更近一步，驅動程序代碼應當限制在ANSI C標準并且應當避免使用不被其他兼容系統(tǒng)編譯器支持的語言特性。驅動程序代碼編寫不應當使用任何ANSI C標準指明為“implementation defined”的特性來編寫。

驅動程序應當避免使用任何在不同平臺上大小和結構變化的數(shù)據類型，驅動程序代碼不應該調用任何C的運行時庫函數(shù)，而是限于調用NDIS提供的函數(shù)。

在內核模式下漂移指針是不允許的。試圖運行這樣的操作將是一個致命的錯誤。

如果驅動程序代碼要支持特殊平臺的特性，那么這些代碼應當包含在#ifdef和#endif聲明之間。

2. 多處理器支持

編寫的代碼應當可以在多處理器系統(tǒng)中安全運行。這對于編寫可移植的Windows 2000驅動程序是很重要的。一個網絡驅動程序必須使用NDIS函數(shù)庫提供的多處理器安全保證。

在單處理器環(huán)境下，在一個時刻單處理器只運行一條機器指令，既使這樣，當包到達或時間中斷發(fā)生時，對于NIC或其他設備執(zhí)行的中斷也可能發(fā)生。典型的，當正在操縱數(shù)據結構時，例如它的隊列時，驅動程序對NIC發(fā)出停用中斷來操縱數(shù)據，隨后再發(fā)生可用中斷。許多線程在單處理器環(huán)境下表現(xiàn)的好像是在同一時刻運行的，但是實際上它們卻是在獨立的時間片上運行的。

在多處理器環(huán)境下，處理器同時可運行多條機器指令，一個驅動程序必須異步化，這使得當一個驅動程序函數(shù)正在操縱一個數(shù)據結構時，同樣的在其他處理器運行的驅動程序函數(shù)不能修改共享的數(shù)據。在一個SMP機器中，所有的驅動程序代碼都要重新裝入，為了消除這種資源保護問題，Windows 2000驅動程序使用自旋鎖。

3. IRQL

所有NDIS調用的驅動程序函數(shù)都運行在系統(tǒng)決定的IRQL下， PASSIVE_LEVEL<DLSPATCH_LEVEL<DIRQL中的一個。例如，一個微端口初始化函數(shù)、掛起函數(shù)、重啟函數(shù)和有時的關閉函數(shù)通常都運行在PASSIVE_LEVEL下。中斷代碼運行在DIRQL下，所以NDIS中層或協(xié)議驅動程序從不運行在DIRQL下。所有其他的NDIS驅動程序函數(shù)運行在IRQL<=DISPATCH_LEVEL下。

驅動程序函數(shù)運行于的IRQL將影響調用什么樣的NDIS函數(shù)。特定的函數(shù)只可在IRQL PASSIVE_LEVEL下調用，其他的函數(shù)可在DISPATCH_LEVEL或更低層調用。一個驅動程序的編寫者應當檢查每一個NDIS函數(shù)的IRQL限制。

任何與驅動程序的ISR共享資源的驅動程序函數(shù)必須能將它的IRQL升級到DTRQL來防止爭用情況的發(fā)生，NDIS提供了這種機質。

4. 同步和指示

當兩個線程共享可被同時訪問的資源時，無論是單處理機還是SMP，同步是必須的。例如，對于一個單處理機，如果一個驅動程序正在訪問一個共享資源時，被一個運行在更高IRQL（例如ISR）的函數(shù)中斷時，必須保護共享資源以阻止這種爭用的發(fā)生而使資源處于不確定狀態(tài)。在一個SMP中，兩個線程可以在同一時刻運行，在不同處理器上并且試圖來修改同一數(shù)據的訪問必須同步。

NDIS提供了自旋鎖可以用來對在同一IRQL下運行的線程間訪問共享資源實現(xiàn)同步。當兩個線程在不同IRQL下訪問共享資源時，NDIS提供了一種機制來臨時提高低IRQL代碼的IRQL，以使得訪問共享資源串行化。

    NDIS提供下面四種機制來保證同步：

自旋鎖

自旋鎖提供了一個用來保護共享資源的同步機制，這種資源是單處理器或一個多處理機下的、運行在IRQL>PASSIVE_LEVEL下的、內核模式中的線程所共享使用的。一個自旋鎖在同時運行在一個SMP機上不同的執(zhí)行線程之間提供同步。一個線程在訪問保護資源前獲得一個自旋鎖。自旋鎖使得任務線程中只有持有自旋鎖的線程可使用資源。一個等待自旋鎖的線程將在試圖獲得鎖時間內循環(huán)，直到持有鎖的線程釋放為止。

    自旋鎖還存在著一個不太明顯但很重要的事實：你僅能在低于或等于DISPATCH_LEVEL級上請求自旋鎖，在你擁有自旋鎖期間，內核將把你的代碼提升到DISPATCH_LEVEL級上運行。在內部，內核能在高于DISPATCH_LEVEL的級上獲取自旋鎖，但你和我都做不到這一點。當KeAcquireSpinLock獲取自旋鎖時，它會把IRQL提升到DISPATCH_LEVEL級上。當KeReleaseSpinLock釋放自旋鎖時，它會把IRQL降低到原來的IRQL級上。如果你知道代碼已經處在DISPATCH_LEVEL級上，你可以調用兩個專用函數(shù)來獲取自旋鎖。KeAcquireSpinLockAtDpcLevel及 KeReleaseSpinLockFromDpcLevel。一個編寫很好的網絡驅動程序應該會減少自旋鎖持有的時間。

    一個典型的使用自旋鎖的例子是保護一個隊列。例如，微端口發(fā)送函數(shù)MiniportSend將協(xié)議驅動程序傳來的包進行排隊。因為其他驅動程序函數(shù)也使用這個隊列，MiniportSend必須用一個自旋鎖保護這個隊列使得在一個時刻只有一個線程可操縱這個隊列。Miniport Send獲得自旋鎖，添加包到隊列后釋放自旋鎖。使用自旋鎖保證持鎖線程是唯一修改隊列的線程，同時使得包被安全地添加到隊列中。當NIC驅動程序從隊列中取走包時，通過同樣的自旋鎖保護這個訪問。當執(zhí)行指令修改隊列頭或任何隊列組成域時，驅動程序必須用自旋鎖保護隊列。

避免死鎖問題

Windows 2000并不限制網絡驅動程序同時持有多于一個的自旋鎖。但是，驅動程序的某部分在持有自旋鎖B時，試圖獲得自旋鎖A，并且其他部分在持有鎖A時，試圖獲得自旋鎖B時，死鎖就會發(fā)生。如果要獲得多于一個的自旋鎖，驅動程序應當通過強制以某一順序獲得鎖來避免死鎖，這就是說，如果一個驅動程序強制在獲得自旋鎖A之后才可獲得鎖B，那么上述情況就不會發(fā)生。

總得來說，使用自旋鎖將對系統(tǒng)性能帶來負面效應，所以驅動程序不應當使用許多鎖。

時鐘

時鐘被用來輪詢或進行超時操作的。一個驅動程序可以產生一個時鐘并與一個函數(shù)關聯(lián)上。當一個特定周期時鐘期滿時，調用相關函數(shù)。時鐘可以是一次的或周期性的，一但設置了一個周期時鐘，當每個周期結束時都會觸發(fā)，直到它被完全清除掉為止。一次性時鐘在觸發(fā)后必須重新設置。

時鐘通過調用NdisMInitializeTimer來產生和初始化，并且通過調用NdisMsetTimer來設置，也可調用NdisMsetPeriodicTimer設置周期時鐘。如果使用了一個非周期時鐘，那么通過調用NdisMSetPeriodicTimer重新設置時鐘。通過調用NdisMCancelTimer可以清除時鐘。

事件

事件在兩個執(zhí)行線程之間實現(xiàn)同步操作。一個事件通過一個驅動程序裝入并且通過調用NdisInitializeEvent初始化。一個運行在IRQL PASSIVE_LEVEL下的線程調用NdisWaitEvent來將自身轉入等侯狀態(tài)。當一個驅動程序線程等待一個事件時，它指定了最大等待時間即等待事件的時間。當調用NdisSetEvent使時間得到信號量，或最大等待時間段結束時，它們兩個無論是誰先發(fā)生時都將結束線程等待狀態(tài)。

典型的，事件是通過相互協(xié)調的線程調用NdisSetEvent來設置的。事件被創(chuàng)建時是沒有信號量的，但為了指示等待線程，它必須要設置信號量，事件將一直處于保持有信號狀態(tài)，直到NdiResetEvent調用后為止。

5. 包結構

通過一個協(xié)議驅動程序可以分配NDIS包、填充數(shù)據，并且將它傳遞到下層的NDIS驅動程序，以便將數(shù)據發(fā)送到網絡上。一些最底層的NIC驅動程序分配包用來保存接收到的數(shù)據，并將包傳遞到對應的高層驅動程序。有時，一個協(xié)議驅動程序分配一個包，并且通過一個請求將它傳給NIC驅動程序，以使NIC驅動程序將接收到的數(shù)據拷貝到提供的包中。NDIS提供函數(shù)用來分配和操縱構成包的子結構。

包描述符 Flags：physicallPageCount： ToralLenth：FirstBuffer：P …

緩存描述符： StartVirtualAddress：P ByteOffset ByteCount PhysicalPage［］ Next P....

緩存

緩存描述符： StartVirtualAddress：P ByteOffset ByteCount PhysicalPage［］ Next P....

虛擬內存

虛擬頁

虛擬頁

虛擬頁

虛擬頁

虛擬頁

物理內存

物理頁

物理頁

物理頁

物理頁

物理頁

圖1：NDIS包結構

具體詳情可以參考：http://www.ndis.com/papers/ndispacket/ndispacket1.htm

6. 使用共享內存

    用作總線管理DMA設備的微端口驅動程序必須為NIC和NIC驅動程序分配共享內存。當在一個驅動程序和它的NIC之間共享cache時，特別的預防是必須的。在某種結構下，必須采取特別步驟來保證內存一致，因為NIC可以直接訪問共享的物理內存，而NIC驅動程序卻要通過cache訪問內存。這就引起驅動程序和NIC訪問內存的不同，即使它們看起來在同一位置。

7. 異步I/O和完成函數(shù)

因為在一些網絡操作中有繼承的因素，許多由NIC驅動程序提供的上層函數(shù)和協(xié)議驅動程序提供的下層函數(shù)被設計成支持異步操作，而不是用CPU消耗一定時間的循環(huán)來等待一個任務的完成或硬件事件的指示，網絡驅動程序依賴處理許多異步操作的能力。

通過使用完成函數(shù)來支持異步網絡I/O。以下的例子將說明網絡的send操作如何使用一個完成函數(shù)，同樣的機制也存在一個協(xié)議或NIC驅動程序的其他操作中。

當協(xié)議驅動程序調用NDIS發(fā)送一個包時，NDIS調用NIC驅動程序的MiniportSend函數(shù)發(fā)送請求，NIC驅動程序試圖立即完成這個請求并且返回一個恰當?shù)臓顟B(tài)值。對于同步操作，可能返回NDIS_STATUS_SUCCESS作為發(fā)送成功的標志，NDIS_STATUS_RESOURCES和NDIS_STATUS_FAILURE表明有某些失敗。

但是一個發(fā)送操作要花費一些時間來完成，此時NIC驅動程序(或NDIS)可將包排隊并且等侯NIC指示發(fā)送操作的結果。NIC驅動程序的MiniportSend函數(shù)可以通過返回一個NDIS_STATUS_PENDING的狀態(tài)值來異步處理這個操作，當NIC驅動程序完成了發(fā)送操作后，包調用完成函數(shù)NdisMSendComplete在調用中傳遞指向一個已被發(fā)送的包的描述符的指針。這個信息會傳給協(xié)議驅動程序，指示完成了操作。

許多需要一定時間來完成的驅動程序操作用完成數(shù)來完成支持異步的操作。這種函數(shù)有同一形式的名字NidisMXxxComplete。不僅可用于發(fā)送和接收函數(shù)，完成函數(shù)也可用于查詢、配置、重新設置硬件、狀態(tài)指示、指示收到數(shù)據和傳送收到數(shù)據。