Linux無線驅動程序的開發測試

馬洪亮

(國家安全生產監督管理總局信息研究院,北京100029)

近年來，隨著WiFi技術的快速發展和普及，WiFi芯片及相關驅動的設計開發已成為短距離無線通信領域的研究熱點。根據研究，在系統運行過程中驅動模塊的缺陷出現頻度是其他內核模塊的3～7倍[1]，因此需要采用富有成效的開發測試方案和手段來提高驅動程序的穩定可靠性。本文針對Linux平臺下的WiFi無線驅動程序的開發測試技術展開論述，對無線協議及驅動開發測試技術進行簡單概述，介紹驅動開發存在的開發測試手段匱乏問題，提出了硬件仿真、狀態控制和數據注入技術。

1 無線協議概述

WiFi技術經過十幾年的快速發展，所支持的無線傳輸速率已從最初的1 Mb/s提升到1 Gb/s以上。WiFi技術主要涉及到網絡協議簇的最低兩層：物理層和媒體接入層，其典型的實現方案如圖1所示。在圖1中，物理層采用純硬件的實現形式，而媒體接入層則采用軟硬件聯合的實現方式：對于時延特性要求高的功能,采用協議硬件加速器來實現;對于網絡管理等對時延要求不高的其他功能,采用驅動程序來實現[2-3]。驅動在執行過程中需根據網絡當前狀態對硬件進行實時配置，其可靠性和穩定性直接決定了整個WiFi芯片及網絡的可用性。

圖1 無線協議組成及典型實現方式

在驅動程序的開發中需要結合快速、有效的開發測試技術，但Linux系統在驅動開發方法和工具方面取得的進展有限，目前主要采用printk信息打印、kgdb源碼調試及kdump崩潰存儲技術[4]。由于需要開發人員精通內核底層數據結構，技術門檻較高，導致只有printk打印方式得到了廣泛的應用。對于非法內存訪問、無效內存管理及軟硬件響應不匹配等常見的無線驅動缺陷類型,當缺陷發生時會導致內核和系統的崩潰，而采用printk等技術很難查找出這些缺陷[1,5]。而對于用戶空間驅動程序、高層建模開發語言等新興的驅動開發方案來說[1,5]，由于尚未提供完整的驅動開發解決方案,且執行效率較低，不適合實時吞吐量大的網絡驅動程序的開發。

因此需要在現有驅動開發測試手段的基礎上，提出新的高效的開發測試技術，以能夠快速全面查找和定位驅動缺陷，提高驅動程序的可靠性和穩定性。

2 開發測試方案

無線驅動程序需要實現Linux系統對無線網絡的管理接口，必須與硬件實時交互。因此，無線驅動程序的開發涉及到軟硬件聯合開發測試,其面臨的主要問題包括：

(1)硬件不可用。由于硬件開發周期長，驅動必須能夠在硬件尚不可用的情形下獨立開展開發和測試。

(2)聯合測試問題多且不易定位。在軟硬件聯合測試時，必須能夠快速定位出問題的位置是位于驅動還是位于硬件部分。

(3)驅動測試手段匱乏，開發效率低。這是驅動程序開發所面臨的一個共同問題，必須提出一個行之有效的驅動開發測試方案來加快驅動的開發進程。

針對上述問題，在實際的無線驅動開發過程中，本文提出了以下幾種開發測試技術：

(1)精確硬件仿真。為了解決硬件尚不可用的問題，編寫了可精確模擬硬件的接口及行為的內核仿真模塊，提供了對硬件接口、硬件協議加速器和基帶的精確模擬。具體來說，模擬的功能包括硬件中斷的產生和處理、數據的發送和接收、硬件發送隊列的管理，以及對硬件寄存器和存儲區的模擬等。除了模擬硬件正常工作時的場景，還可以模擬硬件在實際工作中可能會產生的各種錯誤，進而測試軟件驅動模塊在硬件發生異常時的行為及穩定性，而這是在采用實際的硬件進行測試時很難做到的。通過采用精確硬件仿真技術，使得無線驅動程序代碼在與實際的硬件聯合測試時只需要進行少量修改，甚至不需要修改也能夠正常運行。

(2)實時驅動狀態控制。無線協議本質上是一個FSM有限狀態機，相應的驅動程序也被設計為一個基于事件-消息驅動的系統：根據最新發生的事件或接收到的消息確定下一步的行為和狀態。如果能夠對驅動程序的狀態進行控制，能夠將驅動設置為任意的狀態，就可以遍歷驅動程序的狀態進行測試。為了實現驅動狀態控制功能，在保持驅動程序具有良好的層次結構和清晰的狀態轉移過程的同時，增加了驅動狀態控制模塊，能夠按需控制和設置驅動的當前狀態及所需數據。在具體實現時，該控制功能由位于用戶空間的控制程序和位于內核空間的控制模塊組成，采用netlink接口作為兩者之間的通信接口，運行自定義的接口通信協議。在測試時，控制模塊根據所接收到的控制程序的設置命令，將驅動程序配置為指定的運行狀態，并全面收集驅動程序的最新事件和消息，并及時反饋給控制程序，從而實現了所需的實時驅動狀態控制功能。

(3)高效用戶態數據的注入和輸出。在對無線驅動進行測試時，除了需要實時控制驅動程序的狀態，還需要向驅動注入大量的測試數據。常規的方法是通過ioctl接口傳輸配置命令，通過用戶空間的測試程序發送和接收待測數據包。該方法存在的問題∶一是數據傳輸效率低，二是開發人員可控的因素較少，很難構造出復雜多變及特殊的測試數據。為了解決上述問題，本文提出了一種高效的用戶態數據的注入和輸出解決方案。在該方案中，由位于用戶空間的測試程序產生符合各種測試需求的測試數據，通過netlink接口直接注入到位于內核空間的無線驅動程序中；由位于內核空間的測試代理模塊及時收集驅動的測試結果及相關數據，并通過netlink接口直接輸出到用戶空間的測試程序。采用本方案，可以構造出任意格式的測試數據，覆蓋各種測試功能，可以編寫功能強大的用戶空間分析測試程序對測試數據和結果進行分析，快速發現和定位驅動缺陷。

為了實現上述開發方案，需要在既有的無線驅動模塊的基礎上增加如圖2所示的其他內核模塊和用戶程序。在圖2中，既有的驅動程序模塊實現了無線協議的功能；新增的位于用戶空間的控制程序實時控制和監視驅動狀態、生成各種測試數據并分析驅動的處理結果；新增的內核控制模塊是控制程序的內核代理，負責根據控制程序的命令設置驅動的狀態、將測試數據注入到驅動中，并收集驅動的狀態和數據上傳給控制程序進行分析處理；新增的硬件仿真模塊提供對硬件的精確模擬功能。通過在既有的驅動模塊基礎上增加上述軟件模塊，可以在硬件尚不具備的情況下獨立開展無線驅動程序的開發測試工作。

圖2 驅動軟件模塊組成

3 測試結果

在進行驅動開發時，為了避免由驅動缺陷導致的系統崩潰時調試信息丟失的問題，采用了如圖3所示的雙機遠程開發測試方案。在圖3中，將被測機器(運行無線驅動程序的機器)通過有線網絡連接到遠程控制機器，與圖2采用的單機開發測試方案相比，將位于用戶空間的控制程序遷移到遠程控制機器，而用遠程控制程序代理守護進程來代替控制程序，該代理負責轉發遠程控制程序發送的設置命令和測試數據到內核控制模塊，收集內核控制模塊發送的狀態信息和測試結果再轉發給遠程的控制程序。采用這種開發配置方案，由于遠程控制機器與被測機器相互獨立，當驅動程序在運行過程中由于缺陷導致被測機器崩潰時，則可以在被測機器重新啟動的同時，在遠程控制機器上分析驅動程序輸出的運行期信息和調試日志，確定系統崩潰時驅動程序的狀態及相關的數據，查找出缺陷并及時更正，然后通過svn下載到被測機器運行測試，從而可以節約驅動調試時間，加快驅動缺陷修復的進度。

圖3 遠程開發方案示意圖

采用本文介紹的驅動程序開發技術和方案，經過4個多月的開發測試，成功開發出了一款滿足課題需求的無線驅動程序，其中和硬件聯合測試的時間僅用了一個月左右，80%以上的驅動缺陷都已經在軟硬件聯合測試之前就被找到和得以解決。在無線驅動的開發過程中，統計出來的驅動缺陷的類別及該缺陷所占的比例總結如表1所示。

表1 驅動缺陷分類

在驅動開發過程中發現，由于涉及模塊較多、軟件和硬件單獨開發等原因，出現了較多的軟件模塊間及軟硬件間定義不一致的問題，這類問題以及較為普遍的空指針問題，容易導致地址非法訪問而系統崩潰。這些問題均通過本文所提出的數據注入和驅動狀態遠程輸出技術得以發現和解決，并通過實時驅動狀態控制技術發現和解決了程序邏輯錯誤類型的缺陷。硬件本身所具有的缺陷占到了1/4以上，通過對硬件進行精確全面的仿真，驅動程序代碼基本上不需要做過多的改動，即可在真正的硬件上通過測試，并在輔助硬件開發人員定性和定位硬件缺陷方面發揮了較大的作用。

在Linux驅動程序開發過程中，由于高效的開發測試手段的匱乏，使得驅動程序的開發變得緩慢和困難。本文提出了硬件仿真、狀態控制和數據注入等技術，可以有效地輔助完成驅動的開發測試工作，快速高效地查找出驅動缺陷，加快驅動開發的進度，在驅動程序開發測試方面具有良好的借鑒意義。

[1]秦瑩,戴華東,顏躍進.單一內核操作系統設備驅動程序缺陷研究[J].計算機科學,2011,38(4)∶182-184.

[2]潘志鵬,吳斌,楊坤,等.基于AHB總線的靈活可配置WLAN芯片架構設計[J].電子技術應用,2012,38(7)∶62-65.

[3]何柳,程鵬,陳勇,等.802.11網卡Windows驅動的設計與實現[J].微型機與應用,2013,32(4)∶3-5.

[4]VENKATESWARAN S.精通Linux設備驅動程序開發[M].宋寶華,譯.北京∶人民郵電出版社,2010.

[5]劉軍衛,李曦,陳香蘭,等.用戶態驅動框架的研究與實現[J].計算機系統應用,2011,20(11)∶67-71.