專利名稱：驅動處理方法及裝置的制作方法
技術領域：
本發(fā)明涉及通信領域，具體而言，涉及一種驅動處理方法及裝置。
背景技術：
基于全球無線芯片的格局，高通和微軟主推的網絡驅動接口規(guī)范(network driver interface spec，簡稱為 NDIS) + 高通 MSM 接口(Qualcomm MSM Interface，簡稱為QMI)的移動寬帶設備高速接入方案成為當下移動寬帶設備的主流接入方式之一；但 NDIS+QMI的方式目前只在windows系統(tǒng)上得到了應用，這種接入方式并沒有擴展到更多操作系統(tǒng)上。對于其他的接入方式也可能存在兩樣的問題，即只能在某種操作系統(tǒng)使用。對于其他操作系統(tǒng)而言(例如，安卓Android移動操作系統(tǒng))，應用也在不斷的推廣，因此在這些系統(tǒng)上適配各種移動寬帶設備成為目前的主要工作之一；而目前對只能在某種特定系統(tǒng)上應用的驅動而言，很難照搬到其他操作系統(tǒng)上來，例如，應用于Windows系統(tǒng)上的NDIS驅動是Windows定義的一套規(guī)范，很難照搬或者移植到Android操作系統(tǒng)上， 因此在Android系統(tǒng)上無法支持NDIS設備接入的驅動。在現有技術中存在對于在某種操作系統(tǒng)上特定的協(xié)議無法移植到其他操作系統(tǒng)上的問題，目前還沒有解決方案。

發(fā)明內容
本發(fā)明的主要目的在于提供一種驅動處理方法及裝置，以至少解決上述問題。根據本發(fā)明的一方面，提供了一種驅動處理方法，包括以下步驟接收消息，并判斷所述消息所采用的協(xié)議是否為網絡驅動的原有的協(xié)議處理模塊所支持的協(xié)議，其中，所述網絡驅動用于提供對設備的直接驅動；在判斷結果為否的情況下，將所述消息發(fā)送給預先在所述網絡驅動中增加的協(xié)議處理模塊進行處理；在判斷結果為是的情況下，將所述消息發(fā)送給所述原有的協(xié)議處理模塊進行處理。優(yōu)選地，所述增加的協(xié)議處理模塊提供以下接口的至少之一用于支持所述網絡驅動初始化接口、讀接口、寫接口、輸入/輸出控制接口。優(yōu)選地，所述增加的協(xié)議處理模塊通過所述讀接口進行的讀操作包括檢測到讀操作的消息后，將所述讀操作的消息放入讀隊列中；在接收到喚醒消息之后，調用所述讀接口進行所述讀操作。優(yōu)選地，所述增加的協(xié)議處理模塊通過所述寫接口進行的寫操作包括所述增加的協(xié)議處理模塊的所述寫接口將所述消息以所述網絡驅動所支持的格式發(fā)送給所述設備。優(yōu)選地，所述網絡驅動包括USB設備類通訊-以太網控制模式⑶C-ECM。優(yōu)選地，所述增加的協(xié)議處理模塊所處理的協(xié)議包括NDIS和/或QMI。根據本發(fā)明的另一方面，提供了一種驅動處理裝置，包括判斷模塊，用于接收消息，并判斷所述消息所采用的協(xié)議是否為網絡驅動的原有的協(xié)議處理模塊所支持的協(xié)議， 其中，所述網絡驅動用于提供對設備的直接驅動；處理模塊，用于在判斷結果為否的情況下，將所述消息發(fā)送給預先在所述網絡驅動中增加的協(xié)議處理模塊進行處理；在判斷結果為是的情況下，將所述消息發(fā)送給所述原有的協(xié)議處理模塊進行處理。優(yōu)選地，所述增加的協(xié)議處理模塊提供以下接口的至少之一用于支持所述網絡驅動初始化接口、讀接口、寫接口、輸入/輸出控制接口。優(yōu)選地，所述網絡驅動包括USB CDC-ECM。優(yōu)選地，所述增加的協(xié)議處理模塊所處理的協(xié)議包括NDIS和/或QMI。通過本發(fā)明，采用接收消息，并判斷所述消息所采用的協(xié)議是否為網絡驅動的原有的協(xié)議處理模塊所支持的協(xié)議，其中，所述網絡驅動用于提供對設備的直接驅動；在判斷結果為否的情況下，將所述消息發(fā)送給預先在所述網絡驅動中增加的協(xié)議處理模塊進行處理；在判斷結果為是的情況下，將所述消息發(fā)送給所述原有的協(xié)議處理模塊進行處理，解決了現有技術中存在對于在某種操作系統(tǒng)上特定的協(xié)議無法移植到其他操作系統(tǒng)上問題，可以使在某種操作系統(tǒng)上的特定的協(xié)議比較容易移植到其他系統(tǒng)上來，使操作系統(tǒng)有了較大的擴展性。


此處所說明的附圖用來提供對本發(fā)明的進一步理解，構成本申請的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構成對本發(fā)明的不當限定。在附圖中圖1是根據本發(fā)明實施例的驅動處理方法的流程圖；圖2是根據本發(fā)明實施例的驅動處理裝置的結構框圖；圖3是與本發(fā)明實施例相關的Android系統(tǒng)的USB以太網驅動的示意圖；圖4是根據本發(fā)明優(yōu)選實施例的Android系統(tǒng)NDIS驅動方法的示意圖；圖5是根據本發(fā)明實施例的寫操作的流程圖；圖6是根據本發(fā)明實施例的讀操作的流程圖。
具體實施例方式下文中將參考附圖并結合實施例來詳細說明本發(fā)明。需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互組合。在本實施例中提供了一種驅動處理方法，圖1是根據本發(fā)明實施例的驅動處理方法的流程圖，如圖1所示，該方法包括以下步驟步驟S102，接收消息，并判斷該消息所采用的協(xié)議是否為網絡驅動的原有的協(xié)議處理模塊所支持的協(xié)議，其中，該網絡驅動用于提供對設備的直接驅動；步驟S104，在判斷結果為否的情況下，將該消息發(fā)送給預先在該網絡驅動中增加的協(xié)議處理模塊進行處理；在判斷結果為是的情況下，將該消息發(fā)送給原有的協(xié)議處理模塊進行處理。通過上述步驟，基于操作系統(tǒng)中原有的網絡驅動，僅僅添加了對其他協(xié)議支持的模塊，而是開發(fā)者僅僅關注與協(xié)議模塊的開發(fā)即可，對于網絡驅動的處理，則交由該操作系統(tǒng)的原有的網絡驅動來進行，對于原有的網絡驅動僅僅添加判斷的功能皆可，不需要進行大量的改動，對該網絡驅動的原有功能并沒有帶來任何影響，即實現了兼容，又可以是對其他協(xié)議的支持很方便的進行移植，從而是本實施例中的驅動處理方式有很好的擴展性。
優(yōu)選地，可以根據增加的協(xié)議處理模塊的需要選擇提供以下接口的至少之一以支持網絡驅動初始化接口、讀接口、寫接口、輸入/輸出控制接口。在一個優(yōu)選實施方式中，對于讀操作提供了一種較優(yōu)的處理方式檢測到讀操作的消息后，將讀操作的消息放入讀隊列中；在接收到喚醒消息之后，調用讀接口進行讀操作。
在另一個較優(yōu)的處理方式，對于寫操作也提供了一種較優(yōu)的處理方式增加的協(xié)議處理模塊的寫接口將消息以網絡驅動所支持的格式發(fā)送給設備。在本實施例中還提供了一種驅動處理裝置，該裝置用于實現上述實施例及優(yōu)選實施方式，已經進行過說明的不再贅述。如以下所使用的，術語“模塊”可以實現預定功能的軟件和/或硬件的組合。盡管以下實施例所描述的裝置較佳地以軟件來實現，但是硬件，或者軟件和硬件的組合的實現也是可能并被構想的。圖2是根據本發(fā)明實施例的驅動處理裝置的結構框圖，如圖2所示，該裝置包括判斷模塊22和處理模塊24，下面對該裝置涉及的模塊進行說明。判斷模塊22，用于接收消息，并判斷該消息所采用的協(xié)議是否為網絡驅動的原有的協(xié)議處理模塊所支持的協(xié)議，其中，該網絡驅動用于提供對設備的直接驅動；處理模塊 24，用于在判斷結果為否的情況下，將該消息發(fā)送給預先在網絡驅動中增加的協(xié)議處理模塊進行處理；在判斷結果為是的情況下，將該消息發(fā)送給原有的協(xié)議處理模塊進行處理。對于網絡驅動而言可以使用USB CDC-ECM(Class Definitions for Communication Devices-Ethernet Control Model)，例如在安卓系統(tǒng)中就采用的這種方式，在本實施例中，可以移植的協(xié)議包括NDIS和/或QMI，但并不限于此，以下以此為例結合一個優(yōu)選實施方式進行說明。圖3是與本發(fā)明實施例相關的Android系統(tǒng)的USB以太網驅動的示意圖，如圖3 所示，USB⑶C ECM驅動模型現有驅動方式通過在Android系統(tǒng)上枚舉出以USB以太網口， 使用USB CDC ECM驅動模型所定義的控制協(xié)議作為請求，這種方式是無法支持現有的NDIS 設備的，更無法在此驅動方式上實現對QMI協(xié)議的支持。USB⑶C ECM驅動模型是USB⑶C 協(xié)議的一部分，屬于標準的USB協(xié)議，而目前的NDIS設備并不完全遵守標準的USB協(xié)議，它使用了 windows系統(tǒng)的NDIS規(guī)范，并使用高通自定義的QMI協(xié)議做為主機與設備通訊的控制協(xié)議，而非USB⑶C ECM驅動模型所定義的控制協(xié)議。本優(yōu)選實施例中提供了一種Android系統(tǒng)上的驅動方法，用于實現Android系統(tǒng)上高速移動寬帶設備的驅動和數據接入。現有的Android系統(tǒng)上已經提供了 USB⑶C-ECM的驅動，本優(yōu)選實施例在此驅動的基礎上，實現NDIS設備的驅動支持，則既解決了目前Android系統(tǒng)無法支持NDIS設備的接入難題，又為后續(xù)Android系統(tǒng)支持NDIS設備打下了堅實的基礎。圖4是根據本發(fā)明優(yōu)選實施例的Android系統(tǒng)NDIS驅動方法的示意圖，如圖4所示，使用了在現有的USB⑶C ECM驅動的基礎上增加了 OTC_ENCAP模塊，并修改了 OTC_ECM 模塊，其中，增加了 CDC_ENCAP模塊，用于對自有協(xié)議的支持，提供自定義的讀，寫、輸入/輸出(input/output，簡稱為1/0)控制等接口 ；修改了 OTC_ECM模塊，用于對設備接入的探測、狀態(tài)檢測、CDC_ENCAP模塊初始化等。下面對CDC_ECM模塊和CDC_ENCAP模塊進行說明。OTC_ECM模塊201 修改了 OTC_ECM模塊，用于對設備的直接驅動；在本模塊中，擴展了現有的驅動中對USB CDC ECM協(xié)議的支持，增添了 CDC狀態(tài)檢測中對通知消息 RESPONSE_AVAILABLE的支持(參考《usb cdcl. 2》之3. 8. 2節(jié)，在此不再贅述)，使得來自移動寬帶設備側的自定義協(xié)議(如QMI協(xié)議)消息都可以得到處理；其次在設備探測階段 (probe)，通過調用cdc_encap_init接口，實現對自定義協(xié)議處理函數，互斥量、消息隊列的初始化，從而使得對自定義協(xié)議處理的流程可以轉動CDC_ENCAP模塊進行處理。
CDC_ENCAP模塊202 增加了 CDC_ENCAP模塊，用于封裝對自有協(xié)議的支持；在本模塊中，通過定義了 cdc_encap_init, cdc_encap_read, cdc_encap_write, cdc_encap_ ioc tl這樣的文件接口，提供對⑶C_ECM模塊的支持；其中cdc_encap_init接口實現對自定義協(xié)議處理函數，互斥量、消息隊列的初始化，并通過對Iinux系統(tǒng)文件接口結構體 file_operations的初始化完成了本驅動接口函數的注冊；cdc_encap_read接口通過對 USB控制消息的形式讀取移動終端側自定義協(xié)議的響應消息；cdc_encap_write接口通過USB控制消息的形式將封裝好的自定義協(xié)議消息發(fā)送到移動寬帶設備側；cdc_encap_ ioctl接口提供了其他I/O類操作的支持。 USB NET模塊203和USB CORE模塊204與現有的模塊的功能相似，在此不再贅述。 下面結合上述模塊，對讀寫操作進行說明。圖5是根據本發(fā)明實施例的寫操作的流程圖，如圖5所示，該流程包括如下步驟步驟S501，用戶態(tài)程序調用寫操作。步驟S502，驅動根據不同的消息類型，調用不同的處理流程；如果是是USB⑶C ECM消息，轉往步驟S503 ；否則，轉往步驟S504 ；步驟S503，如果是是USB⑶C ECM消息、安裝現有驅動的處理流程處理，轉往步驟 S506 ；步驟S504，如果不是USB⑶C ECM消息，進入本報發(fā)明驅動的寫操作處理流程，轉往步驟S505 ；步驟S505，將上層的寫數據，通過調用USB CORE的接口進行處理；步驟S506，負責具體的USB數據寫操作；步驟S507，判斷數據是否寫成功，成功則轉往步驟S508，否則轉往步驟S509 ；步驟S508，數據寫成功，返回成功；步驟S509，數據寫失敗，進入異常處理；圖6是根據本發(fā)明實施例的讀操作的流程圖，如圖6所示，該流程包括如下步驟步驟S601，驅動初始化，初始化讀隊列，啟動消息檢測機制；步驟S602，檢測⑶C的狀態(tài)消息，判斷消息類型，如果是CONNECTION消息，進入步驟S607, SPEED CHANGE消息進入步驟S608, RESPONSE消息進入步驟S609 ；步驟S603，用戶態(tài)程序調用讀操作。步驟S604，進行用戶態(tài)到和核心態(tài)的轉換后，進入OTC_ENCAP模塊；步驟S605，OTC_ENCAP模塊搜到讀操作的消息后，將該消息放進讀隊列中；步驟S606，讀隊列中的消息等待被喚醒；步驟S607，解析收到的CONNECTION消息，檢測有效性后，按照原有的處理流程，轉往步驟S615 ；步驟S608，解析收到的SPEED CHANGE消息，檢測有效性后，按照原有的處理流程，轉往步驟S615 步驟S609，解析收到的SPEED CHANGE消息，檢測有效性后，喚醒CDC_ENCAP模塊中的讀消息隊列；步驟S610，判斷讀隊列中的消息是否被喚醒，喚醒轉往步驟S611，否則轉往步驟 S606 ；步驟S611，讀隊列被喚醒后，判斷隊列中是否有消息，有的轉往步驟S612，否則轉往步驟S616，進行異常處理；步驟S612，通過接口 CDC_ENCAP_READ進行讀處理；步驟S613，判斷讀處理是否成功，成功則轉往步驟S613處理，否則轉往步驟S616， 進行異常處理；步驟S614，返回讀操作獲取到的數據；步驟S615，現有驅動已實現的消息處理流程；步驟S616，異常處理。通過上述實施例實現了如下效果，需要說明的是，以下的效果并不是每個實施均能達到的，有些效果是有些優(yōu)選實施例才具有的。1.擴展了現有的⑶C ECM驅動，使得現有⑶C ECM驅動既能支持原有的USB CDCECM設備，又能支持新的NDIS設備，既兼容了原有的設備驅動，又使得一些操作系統(tǒng)(例如，Android系統(tǒng))增加了對NDIS設備的支持、現有的NDIS設備不需要做任何的修改即可適配到Android系統(tǒng)使用，解決了某些操作系統(tǒng)無法支持NDIS設備和現有驅動無法有效提高與移動寬帶設備之間傳輸速度的問題。2.通用性NDIS設備無疑會是后續(xù)移動寬帶設備主流的接入方式之一，因此在不支持該協(xié)議的操作系統(tǒng)上設計和實現對NDIS設備的支持，極大了符合了后續(xù)多制式設備的接入方式和技術的發(fā)展趨勢，擴展了操作系統(tǒng)的功能和接入方式的通用性。3.擴展性上述優(yōu)選實施例的方案是將NDIS設備的接入方式融入到操作系統(tǒng)現有的驅動中，兼容了原有的設備驅動，沒有修改操作系統(tǒng)框架層的架構，增加了操作系統(tǒng)對移動寬帶設備的接入方式，增加了操作系統(tǒng)的擴展性；同時增添了對自定義協(xié)議(如高通的QMI協(xié)議)的支持，使得上述優(yōu)選實施例中的驅動方法有更大的擴展性。顯然，本領域的技術人員應該明白，上述的本發(fā)明的各模塊或各步驟可以用通用的計算裝置來實現，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網絡上，可選地，它們可以用計算裝置可執(zhí)行的程序代碼來實現，從而可以將它們存儲在存儲裝置中由計算裝置來執(zhí)行，或者將它們分別制作成各個集成電路模塊，或者將它們中的多個模塊或步驟制作成單個集成電路模塊來實現。這樣，本發(fā)明不限制于任何特定的硬件和軟件結合。以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領域的技術人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內。
權利要求
1.一種驅動處理方法，其特征在于，包括以下步驟接收消息，并判斷所述消息所采用的協(xié)議是否為網絡驅動的原有的協(xié)議處理模塊所支持的協(xié)議，其中，所述網絡驅動用于提供對設備的直接驅動；在判斷結果為否的情況下，將所述消息發(fā)送給預先在所述網絡驅動中增加的協(xié)議處理模塊進行處理；在判斷結果為是的情況下，將所述消息發(fā)送給所述原有的協(xié)議處理模塊進行處理。
2.根據權利要求1所述的方法，其特征在于，所述增加的協(xié)議處理模塊提供以下接口的至少之一用于支持所述網絡驅動初始化接口、讀接口、寫接口、輸入/輸出控制接口。
3.根據權利要求2所述的方法，其特征在于，所述增加的協(xié)議處理模塊通過所述讀接口進行的讀操作包括檢測到讀操作的消息后，將所述讀操作的消息放入讀隊列中；在接收到喚醒消息之后，調用所述讀接口進行所述讀操作。
4.根據權利要求2所述的方法，其特征在于，所述增加的協(xié)議處理模塊通過所述寫接口進行的寫操作包括所述增加的協(xié)議處理模塊的所述寫接口將所述消息以所述網絡驅動所支持的格式發(fā)送給所述設備。
5.根據權利要求1至4中任一項所述的方法，其特征在于，所述網絡驅動包括 USBCDC-ECM。
6.根據權利要求5所述的方法，其特征在于，所述增加的協(xié)議處理模塊所處理的協(xié)議包括:NDIS和/或QMI。
7.—種驅動處理裝置，其特征在于，包括判斷模塊，用于接收消息，并判斷所述消息所采用的協(xié)議是否為網絡驅動的原有的協(xié)議處理模塊所支持的協(xié)議，其中，所述網絡驅動用于提供對設備的直接驅動；處理模塊，用于在判斷結果為否的情況下，將所述消息發(fā)送給預先在所述網絡驅動中增加的協(xié)議處理模塊進行處理；在判斷結果為是的情況下，將所述消息發(fā)送給所述原有的協(xié)議處理模塊進行處理。
8.根據權利要求7所述的裝置，其特征在于，所述增加的協(xié)議處理模塊提供以下接口的至少之一用于支持所述網絡驅動初始化接口、讀接口、寫接口、輸入/輸出控制接口。
9.根據權利要求7或8所述的裝置，其特征在于，所述網絡驅動包括USB設備類通訊_以太網控制模式⑶C-ECM。
10.根據權利要求7或8所述的裝置，其特征在于，所述增加的協(xié)議處理模塊所處理的協(xié)議包括網絡驅動接口規(guī)范NDIS和/或高通MSM接口 QMI。
全文摘要
本發(fā)明公開了一種驅動處理方法及裝置，該方法包括接收消息，并判斷消息所采用的協(xié)議是否為網絡驅動的原有的協(xié)議處理模塊所支持的協(xié)議，其中，網絡驅動用于提供對設備的直接驅動；在判斷結果為否的情況下，將消息發(fā)送給預先在網絡驅動中增加的協(xié)議處理模塊進行處理；在判斷結果為是的情況下，將消息發(fā)送給原有的協(xié)議處理模塊進行處理。通過本發(fā)明可以使在某種操作系統(tǒng)上的特定的協(xié)議比較容易移植到其他系統(tǒng)上來，使操作系統(tǒng)有了較大的擴展性。
文檔編號H04L29/06GK102385557SQ201110234870
公開日2012年3月21日 申請日期2011年8月16日 優(yōu)先權日2011年8月16日
發(fā)明者李焰峰, 范鎖平 申請人:中興通訊股份有限公司