摘 要： 針對Linux驅動程序開發(fā)缺少快速高效測試手段的問題，提出了精確硬件仿真、實時驅動狀態(tài)控制和高效數(shù)據(jù)注入技術，并應用到了無線驅動程序開發(fā)實踐中。結果證明,該技術能夠快速、有效地查找出驅動缺陷,提高驅動程序的可靠性,達到了豐富驅動開發(fā)測試手段、加快驅動開發(fā)進度的效果。
關鍵詞： Linux; WiFi; 驅動程序; 測試

    近年來，隨著WiFi技術的快速發(fā)展和普及，WiFi芯片及相關驅動的設計開發(fā)已成為短距離無線通信領域的研究熱點。根據(jù)研究，在系統(tǒng)運行過程中驅動模塊的缺陷出現(xiàn)頻度是其他內核模塊的3~7倍[1]，因此需要采用富有成效的開發(fā)測試方案和手段來提高驅動程序的穩(wěn)定可靠性。本文針對Linux平臺下的WiFi無線驅動程序的開發(fā)測試技術展開論述，對無線協(xié)議及驅動開發(fā)測試技術進行簡單概述，介紹驅動開發(fā)存在的開發(fā)測試手段匱乏問題，提出了硬件仿真、狀態(tài)控制和數(shù)據(jù)注入技術。
1 無線協(xié)議概述
    WiFi技術經(jīng)過十幾年的快速發(fā)展，所支持的無線傳輸速率已從最初的1 Mb/s提升到1 Gb/s以上。WiFi技術主要涉及到網(wǎng)絡協(xié)議簇的最低兩層：物理層和媒體接入層，其典型的實現(xiàn)方案如圖1所示。在圖1中，物理層采用純硬件的實現(xiàn)形式，而媒體接入層則采用軟硬件聯(lián)合的實現(xiàn)方式：對于時延特性要求高的功能,采用協(xié)議硬件加速器來實現(xiàn);對于網(wǎng)絡管理等對時延要求不高的其他功能,采用驅動程序來實現(xiàn)[2-3]。驅動在執(zhí)行過程中需根據(jù)網(wǎng)絡當前狀態(tài)對硬件進行實時配置，其可靠性和穩(wěn)定性直接決定了整個WiFi芯片及網(wǎng)絡的可用性。
    在驅動程序的開發(fā)中需要結合快速、有效的開發(fā)測試技術，但Linux系統(tǒng)在驅動開發(fā)方法和工具方面取得的進展有限，目前主要采用printk信息打印、kgdb源碼調試及kdump崩潰存儲技術[4]。由于需要開發(fā)人員精通內核底層數(shù)據(jù)結構，技術門檻較高，導致只有printk打印方式得到了廣泛的應用。對于非法內存訪問、無效內存管理及軟硬件響應不匹配等常見的無線驅動缺陷類型,當缺陷發(fā)生時會導致內核和系統(tǒng)的崩潰，而采用printk等技術很難查找出這些缺陷[1, 5]。而對于用戶空間驅動程序、高層建模開發(fā)語言等新興的驅動開發(fā)方案來說[1,5]，由于尚未提供完整的驅動開發(fā)解決方案,且執(zhí)行效率較低，不適合實時吞吐量大的網(wǎng)絡驅動程序的開發(fā)。

    因此需要在現(xiàn)有驅動開發(fā)測試手段的基礎上，提出新的高效的開發(fā)測試技術，以能夠快速全面查找和定位驅動缺陷，提高驅動程序的可靠性和穩(wěn)定性。
2 開發(fā)測試方案
    無線驅動程序需要實現(xiàn)Linux系統(tǒng)對無線網(wǎng)絡的管理接口，必須與硬件實時交互。因此，無線驅動程序的開發(fā)涉及到軟硬件聯(lián)合開發(fā)測試,其面臨的主要問題包括：
    (1)硬件不可用。由于硬件開發(fā)周期長，驅動必須能夠在硬件尚不可用的情形下獨立開展開發(fā)和測試。
    (2)聯(lián)合測試問題多且不易定位。在軟硬件聯(lián)合測試時，必須能夠快速定位出問題的位置是位于驅動還是位于硬件部分。
    (3)驅動測試手段匱乏，開發(fā)效率低。這是驅動程序開發(fā)所面臨的一個共同問題，必須提出一個行之有效的驅動開發(fā)測試方案來加快驅動的開發(fā)進程。
    針對上述問題，在實際的無線驅動開發(fā)過程中，本文提出了以下幾種開發(fā)測試技術：
    (1)精確硬件仿真。為了解決硬件尚不可用的問題，編寫了可精確模擬硬件的接口及行為的內核仿真模塊，提供了對硬件接口、硬件協(xié)議加速器和基帶的精確模擬。具體來說，模擬的功能包括硬件中斷的產(chǎn)生和處理、數(shù)據(jù)的發(fā)送和接收、硬件發(fā)送隊列的管理，以及對硬件寄存器和存儲區(qū)的模擬等。除了模擬硬件正常工作時的場景，還可以模擬硬件在實際工作中可能會產(chǎn)生的各種錯誤，進而測試軟件驅動模塊在硬件發(fā)生異常時的行為及穩(wěn)定性，而這是在采用實際的硬件進行測試時很難做到的。通過采用精確硬件仿真技術，使得無線驅動程序代碼在與實際的硬件聯(lián)合測試時只需要進行少量修改，甚至不需要修改也能夠正常運行。
    (2)實時驅動狀態(tài)控制。無線協(xié)議本質上是一個FSM有限狀態(tài)機，相應的驅動程序也被設計為一個基于事件-消息驅動的系統(tǒng)：根據(jù)最新發(fā)生的事件或接收到的消息確定下一步的行為和狀態(tài)。如果能夠對驅動程序的狀態(tài)進行控制，能夠將驅動設置為任意的狀態(tài)，就可以遍歷驅動程序的狀態(tài)進行測試。為了實現(xiàn)驅動狀態(tài)控制功能，在保持驅動程序具有良好的層次結構和清晰的狀態(tài)轉移過程的同時，增加了驅動狀態(tài)控制模塊，能夠按需控制和設置驅動的當前狀態(tài)及所需數(shù)據(jù)。在具體實現(xiàn)時，該控制功能由位于用戶空間的控制程序和位于內核空間的控制模塊組成，采用netlink接口作為兩者之間的通信接口，運行自定義的接口通信協(xié)議。在測試時，控制模塊根據(jù)所接收到的控制程序的設置命令，將驅動程序配置為指定的運行狀態(tài)，并全面收集驅動程序的最新事件和消息，并及時反饋給控制程序，從而實現(xiàn)了所需的實時驅動狀態(tài)控制功能。
    (3)高效用戶態(tài)數(shù)據(jù)的注入和輸出。在對無線驅動進行測試時，除了需要實時控制驅動程序的狀態(tài)，還需要向驅動注入大量的測試數(shù)據(jù)。常規(guī)的方法是通過ioctl接口傳輸配置命令，通過用戶空間的測試程序發(fā)送和接收待測數(shù)據(jù)包。該方法存在的問題:一是數(shù)據(jù)傳輸效率低，二是開發(fā)人員可控的因素較少，很難構造出復雜多變及特殊的測試數(shù)據(jù)。為了解決上述問題，本文提出了一種高效的用戶態(tài)數(shù)據(jù)的注入和輸出解決方案。在該方案中，由位于用戶空間的測試程序產(chǎn)生符合各種測試需求的測試數(shù)據(jù)，通過netlink接口直接注入到位于內核空間的無線驅動程序中；由位于內核空間的測試代理模塊及時收集驅動的測試結果及相關數(shù)據(jù)，并通過netlink接口直接輸出到用戶空間的測試程序。采用本方案，可以構造出任意格式的測試數(shù)據(jù)，覆蓋各種測試功能，可以編寫功能強大的用戶空間分析測試程序對測試數(shù)據(jù)和結果進行分析，快速發(fā)現(xiàn)和定位驅動缺陷。
    為了實現(xiàn)上述開發(fā)方案，需要在既有的無線驅動模塊的基礎上增加如圖2所示的其他內核模塊和用戶程序。在圖2中，既有的驅動程序模塊實現(xiàn)了無線協(xié)議的功能；新增的位于用戶空間的控制程序實時控制和監(jiān)視驅動狀態(tài)、生成各種測試數(shù)據(jù)并分析驅動的處理結果；新增的內核控制模塊是控制程序的內核代理，負責根據(jù)控制程序的命令設置驅動的狀態(tài)、將測試數(shù)據(jù)注入到驅動中，并收集驅動的狀態(tài)和數(shù)據(jù)上傳給控制程序進行分析處理；新增的硬件仿真模塊提供對硬件的精確模擬功能。通過在既有的驅動模塊基礎上增加上述軟件模塊，可以在硬件尚不具備的情況下獨立開展無線驅動程序的開發(fā)測試工作。

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

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

    在驅動開發(fā)過程中發(fā)現(xiàn)，由于涉及模塊較多、軟件和硬件單獨開發(fā)等原因，出現(xiàn)了較多的軟件模塊間及軟硬件間定義不一致的問題，這類問題以及較為普遍的空指針問題，容易導致地址非法訪問而系統(tǒng)崩潰。這些問題均通過本文所提出的數(shù)據(jù)注入和驅動狀態(tài)遠程輸出技術得以發(fā)現(xiàn)和解決，并通過實時驅動狀態(tài)控制技術發(fā)現(xiàn)和解決了程序邏輯錯誤類型的缺陷。硬件本身所具有的缺陷占到了1/4以上，通過對硬件進行精確全面的仿真，驅動程序代碼基本上不需要做過多的改動，即可在真正的硬件上通過測試，并在輔助硬件開發(fā)人員定性和定位硬件缺陷方面發(fā)揮了較大的作用。
    在Linux驅動程序開發(fā)過程中，由于高效的開發(fā)測試手段的匱乏，使得驅動程序的開發(fā)變得緩慢和困難。本文提出了硬件仿真、狀態(tài)控制和數(shù)據(jù)注入等技術，可以有效地輔助完成驅動的開發(fā)測試工作，快速高效地查找出驅動缺陷，加快驅動開發(fā)的進度，在驅動程序開發(fā)測試方面具有良好的借鑒意義。
參考文獻
[1] 秦瑩,戴華東,顏躍進.單一內核操作系統(tǒng)設備驅動程序缺陷研究[J]. 計算機科學,2011,38(4):182-184.
[2] 潘志鵬,吳斌,楊坤,等.基于AHB總線的靈活可配置WLAN芯片架構設計[J]. 電子技術應用,2012,38(7):62-65.
[3] 何柳,程鵬,陳勇,等. 802.11網(wǎng)卡Windows驅動的設計與實現(xiàn)[J].微型機與應用,2013,32(4):3-5.
[4] VENKATESWARAN S.精通Linux設備驅動程序開發(fā)[M].宋寶華,譯. 北京:人民郵電出版社,2010.
[5] 劉軍衛(wèi), 李曦, 陳香蘭,等. 用戶態(tài)驅動框架的研究與實現(xiàn)[J].計算機系統(tǒng)應用,2011,20(11):67-71.