設備驅動消息處理方法及裝置的製作方法
2023-04-25 21:56:01
專利名稱：設備驅動消息處理方法及裝置的製作方法
技術領域：
本發明涉及通信領域，具體而言，涉及一種設備驅動消息處理方法及裝置。
背景技術：
基於全球無線晶片的格局，不同的廠商均在推出不同的設備驅動規範，例如，高通和微軟主推的網絡驅動接口規範(network driver interface spec，簡稱為NDIS) +高通 MSM接口(Qualcomm MSM hterface，簡稱為QMI)的移動寬帶設備高速接入方案成為當下移動寬帶設備的主流接入方式之一；但NDIS+QMI的方式目前在windows系統上得到了應用，並且，對於其他的系統，隨著技術的不斷發展，逐步的也可以支持該規範。同時，對於作業系統而言，其也在不斷推新，一方面，現有的作業系統在不停的發展以適應不同的終端類型，另一方面，也出現了其他類型的新的作業系統，例如，安卓 Android行動作業系統。由上述現有的技術發展的趨勢可以看出，作業系統與設備驅動規範的發展並不是統一的，這樣，作業系統需要支持原來越多的設備驅動，對於不同的設備驅動，在作業系統上均需要編寫對應的與上層應用對接的中間層代碼。即在現有技術中，作業系統對設備驅動的兼容性比較差。
發明內容
本發明的主要目的在於提供一種設備驅動消息處理方法及裝置，以至少解決上述問題。根據本發明的一方面，提供了一種設備驅動消息處理方法，包括如下步驟通過提供給上層協議的第一接口，與所述上層協議對應的上層進行消息的傳輸；將來自所述上層協議的消息按照設備驅動所支持的協議進行封裝，並且，將來自所述設備驅動的消息使用所述設備驅動所支持的協議將該消息解封裝為所述上層協議所支持的消息格式；通過提供給所述設備驅動的第二接口，與所述設備驅動傳輸消息，其中，該消息的格式為所述設備驅動所支持的協議的格式。優選地，在通過所述第一接口進行傳輸的消息中攜帶有設備標識的情況下，通過所述第二接口與所述設備驅動傳輸消息包括，根據所述設備標識通過所述第二接口將攜帶有該設備標識的消息發送給與所述設備標識對應的設備驅動。優選地，還包括對通過所述設備驅動接入的設備進行狀態檢測和管理。優選地，所述設備驅動為NDIS設備驅動，和/或，所述上層協議為RIL。根據本發明的另一方面，提供了一種設備驅動消息處理裝置，包括第一傳輸模塊，用於通過提供給上層協議的第一接口，與所述上層協議對應的上層進行消息的傳輸；消息處理模塊，用於將來自所述上層協議的消息按照設備驅動所支持的協議進行封裝，並且， 將來自所述設備驅動的消息使用所述設備驅動所支持的協議將該消息解封裝為所述上層協議所支持的消息格式；第二傳輸模塊，用於通過提供給所述設備驅動的第二接口，與所述設備驅動傳輸消息，其中，該消息的格式為所述設備驅動所支持的協議的格式。優選地，所述第二傳輸模塊，用於在通過所述第一接口進行傳輸的消息中攜帶有設備標識的情況下，根據所述設備標識通過所述第二接口將攜帶有該設備標識的消息發送給與所述設備標識對應的設備驅動。優選地，還包括設備管理模塊，用於對通過所述設備驅動接入的設備進行狀態檢
測和管理。優選地，所述設備驅動為NDIS設備驅動，和/或，所述上層協議為RIL。通過本發明，採用通過提供給上層協議的第一接口，與所述上層協議對應的上層進行消息的傳輸；將來自所述上層協議的消息按照設備驅動所支持的協議進行封裝，並且， 將來自所述設備驅動的消息按照所述設備驅動所支持的協議將該消息解封裝為所述上層協議所支持的消息格式；通過提供給所述設備驅動的第二接口，與所述設備驅動傳輸消息， 其中，該消息的格式為所述設備驅動所支持的協議的格式，解決了現有技術中作業系統對設備驅動的兼容性比較差問題，提高了作業系統對設備驅動的兼容性。
此處所說明的附圖用來提供對本發明的進一步理解，構成本申請的一部分，本發明的示意性實施例及其說明用於解釋本發明，並不構成對本發明的不當限定。在附圖中圖1是根據本發明實施例的設備驅動消息處理方法的流程圖；圖2是根據本發明實施例的設備驅動消息處理裝置的結構框圖；圖3是根據本發明實施例的Android系統的設備驅動的架構的示意圖一；圖4是根據本發明實施例的Android系統的設備驅動的架構的示意圖二 ；圖5是根據本發明實施例的下行數據傳輸的流程圖；圖6是根據本發明實施例的上行數據傳輸的流程圖。
具體實施例方式下文中將參考附圖並結合實施例來詳細說明本發明。需要說明的是，在不衝突的情況下，本申請中的實施例及實施例中的特徵可以相互組合。在本實施例中提供了一種設備驅動消息處理方法，圖1是根據本發明實施例的設備驅動消息處理方法的流程圖，如圖1所示，該流程包括如下步驟步驟S102，通過提供給上層協議的第一接口，與上層協議所對應的上層進行消息的傳輸；步驟S104，將來自該上層協議的消息按照設備驅動所支持的協議進行封裝，並且， 將來自設備驅動的消息使用設備驅動所支持的協議將該消息解封裝為上層協議所支持的消息格式；步驟S106，通過提供給設備驅動的第二接口，與設備驅動傳輸消息，其中，該消息的格式為設備驅動所支持的協議的格式。需要說明的是，上述的步驟不一定按照步驟S102至步驟S106的順序執行。通過上述步驟，提供了在設備驅動層和上層協議之間提供了一種中間層的處理方式，這樣，對於不同的驅動程序不需要再重新開發中間層的驅動，從而提高了作業系統對設備驅動的兼容性。為了同時支持多個設備驅動(例如，多個同類型的設備驅動)，在一個優選實施方式中，可以在第一接口傳輸的消息中設置設備標識，在這種情況下，通過第二接口與設備驅動傳輸消息包括；根據設備標識通過第二接口將攜帶有該設備標識的消息發送給與設備標識對應的設備驅動。通過該優選的實施方式，將對多個設備的處理也移植到中間層中，不需要上層和設備驅動進行任何的改動，使對多個設備驅動的支持更好。優選地，在該中間層中還可以增加對通過設備驅動接入的設備進行狀態檢測和管理的功能。通過這些功能的增加可以更好的對設備驅動進行控制。在目前的安卓系統中，並沒有提供能夠對多個NDIS設備驅動的支持，上述實施例及優選的實施方式可以應用在安卓系統中，在該系統中為了較小的改動系統架構，上述的中間呈位於無線寬帶業務處理(Radio Interface Layer，簡稱為RIL)(即上層協議中的一種)和設備驅動之間。這樣可以實現與Android系統現有RIL驅動的無縫對接，從而既能實現對多NDIS設備的無縫接入，提高Android系統的對多NDIS設備支持的缺陷，擴展了 Android系統的功能，提供了 Android系統更為豐富的寬帶設備接入，又能較少的修改 Android系統框架。在本實施例中還提供了一種設備接入處理裝置，該裝置用於實現上述實施例及優選實施方式，已經進行過說明的不再贅述。如以下所使用的，術語「模塊」可以實現預定功能的軟體和/或硬體的組合。儘管以下實施例所描述的裝置較佳地以軟體來實現，但是硬體，或者軟體和硬體的組合的實現也是可能並被構想的。圖2是根據本發明實施例的設備驅動消息處理裝置的結構框圖，如圖2所示，該裝置包括第一傳輸模塊22、消息處理模塊M 和第二傳輸模塊26，下面對該裝置涉及的模塊進行說明。第一傳輸模塊22，用於通過提供給上層協議的第一接口，與上層協議對應的上層進行消息的傳輸；消息處理模塊對，連接至第一傳輸模塊22，該模塊用於將來自上層協議的消息按照設備驅動所支持的協議進行封裝，並且，將來自設備驅動的消息按照設備驅動所支持的協議將該消息解封裝為上層協議所支持的消息格式；第二傳輸模塊沈，連接至消息處理模塊M，該模塊用於通過提供給設備驅動的第二接口，與設備驅動傳輸消息，其中， 該消息的格式為設備驅動所支持的協議的格式。優選地，第二傳輸模塊22用於在通過第一接口進行傳輸的消息中攜帶有設備標識的情況下，根據設備標識通過第二接口將攜帶有該設備標識的消息發送給與設備標識對應的設備驅動。優選地，該裝置還可以包括設備管理模塊，該模塊用於對通過設備驅動接入的設備進行狀態檢測和管理。下面以安卓系統為例，結合對NDIS設備驅動的支持對一個優選實施例進行說明。在優選實施例中，對於安卓系統如何支持NDIS單設備驅動並不是討論的重點，而重點在於如何提供一個中間層的處理方式，以及如何支持多個NDIS設備。對於安卓系統如何支持NDIS設備可以採用不同的方式來進行，其並不影響本優選實施例的實施，在此不再贅述。本優選實施例可以對多NDIS設備進行支持，實現了與Android系統現有RIL驅動的無縫對接。圖3是根據本發明實施例的Android系統的設備驅動的架構的示意圖一，如圖3所示，該驅動系統包括RIL框架、QMI/AT框架和設備驅動模塊，其中，該QMI/AT框架包括 QmiClient模塊304 (用於實現第一傳輸模塊22的功能)、QmiDaemon模塊302 (用於實現第二傳輸模塊26和消息處理模塊M的功能)，當然，為了支持AT命令，還可以增加AT命令模塊301。該QMI/AT框架實現了上述中間層的功能。圖4是根據本發明實施例的Android系統的設備驅動的架構的示意圖二，如圖4 所示，在該架構中增加了消息處理模塊403 (該消息處理模塊和QmiDaemon模塊結合實現了上述消息處理模塊M的功能)和設備管理模塊405。圖4中的QmiDaemon模塊402相對於圖3中的QmiDaemon模塊302也進行了修改，下面對此進行說明。QmiClient模塊404，依舊提供同步的接口調用給上層使用，除了在接口中增加了設備ID外、依舊保持了 RIL層接口的統一性。消息處理模塊403，主要負責消息的封裝和解析，其中對來自RIL層消息按無線數據服務(QMI Wireless Data Service，簡稱為 WDS)、QMI 控制服務(QMI Control Service, 簡稱為CTL)、QMI數據管理服務(QMI Device Management krvice，簡稱為DMS)等消息格式進行數據封裝，並將封裝好的消息數據，通過socket機制發送出去，接收則通過在接收線程中等待從socket收到的數據，接收線程收到數據後，解析接收到數據，並通過設備ID、 消息ID等信息匹配是哪個請求消息的響應，對於主動上報的消息，則只需要確定設備ID即可。QmiDaemon模塊402，主要負責消息的管理，異步發送和接收；消息的管理是指要接收來自消息處理模塊通過socket發送過來的消息，之後根據消息所對應的設備ID，將該消息放到對應設備的發送消息隊列中；接收線程中負責接收從設備讀取的數據，並將接收到數據放在接收隊列中。NDIS設備管理模塊405，主要負責多個NDIS設備的節點管理，狀態管理等。上述優選實施例提供的驅動方法及系統，具有以下優點(1)增加了對多個NDIS設備的支持，使得Android系統可以同時支持多個NDIS 設備，改變和擴展了現有Android系統中RIL驅動部分只能操作一個設備的情況，使得RIL 驅動部分可以增加對多個NDIS設備的支持、而RIL層之上的接口依舊保持不變，解決了 Android系統目前無法支持多個NDIS設備的問題。本優選實施例是將多NDIS設備的管理和接入方式融入到Android系統現有的RIL框架中，沒有修改Android系統RIL和Framwork 的架構，增加了 Android系統對移動寬帶設備的接入方式增加了 Android系統的擴展性；在 QmiDaemon模塊中增加了對自定義消息處理的邏輯、使得本技術方案在Qmi協議之外可以增加對私有協議的支持，增強了 Android系統的擴展性。( NDIS設備作為後續移動寬帶設備主流接入方式之一，可以一個系統上同時支持多個NDIS設備(例如不同制式的NDIS設備)，極大地符合了後續多制式、多PDP設備的接入方式和技術的發展趨勢，擴展了 Android系統的功能，使得Android系統有了更大的通用性，同時QMIClient模塊對上層提供的接口依舊才用同步API的方式，兼容了以前的方案，使得上層對QMI Client的接口調用，不需要做過多的修改即可使用，大大的提高了本技術方案的通用性。下面上述圖4中的模塊進行詳細的說明。QmiDaemon模塊402，該模塊可以通過如下三個線程完成
Qmi消息接收線程Qmi消息接收線程用於檢測發送消息隊列是否有消息需要處理，有則在此線程中調用NDIS設備管理模塊封裝的設備操作接口，將消息發送到對應的NDIS設備，如果發送成功，則通過消息郵箱(mail box)發送信號給響應消息處理線程，通知它發送ack ok的消息給消息處理模塊，否則發送ack error消息；response消息則等待從NDIS設備的返回值； 如果是自定義消息類型，則直接處理，處理完成後，首先發送ack ok或者ack error的消息，然後直接發送response的消息內容給通過socket將結果發送給消息處理模塊。NDIS設備數據接收線程NDIS設備數據接收線程用於檢測是否有從NDIS設備來的數據需要處理，有則將接收到的消息和設備ID —起封裝成預定義的格式，然後放進接收消息隊列，同時通過消息郵箱(mail box)發送信號給響應消息處理線程，通知它發送響應(Response)消息給消息處理模塊，否則繼續循環檢測。響應消息處理線程等待Qmi消息接收線程和NDIS設備數據接收線程發送過來的信號，根據信號類型分別處理如果是ack消息，則需要根據信號中攜帶的參數(設備ID和消息ID)匹配對應的消息請求，然後封裝ACK消息，並通過socket發送消息給消息處理模塊；如果是response 消息，同樣需要根據設備ID和消息ID匹配對應的消息請求，然後封裝response消息，並通過socket發送消息給消息處理模塊；如果是主動上報的消息，僅僅匹配設備ID，然後封裝主動上報的消息，並通過socket發送消息給消息處理模塊。消息處理模塊403該模塊用來封裝和解析消息；一是將來自QmiClient模塊的消息根據內容的不同封裝成為對應的QMI指令，例如，WDS、CTL、DMS等格式的NDIS報文數據，並通過socket發送給QmiDaemon模塊；二是啟動消息接收線程，通過socket接收來自QmiDaemon模塊的ACK 消息、response消息和主動上報等響應消息；針對response消息需要根據WDS、CTL、DMS等格式解析響應消息內容，並通過設備ID、消息ID等信息匹配是哪個請求消息的響應，然後返迴響應數據給QmiClient模塊，對於主動上報的消息，則只需要確定設備ID即可。QmiClient 模塊 404該模塊主要負責提供同步的應用程式接口(Application Program hterface，簡稱為API)函數給上層調用，使得QMI和RIL可以無縫對接；原有系統中，RIL層的接口不需要設備ID即可直接發送消息和接收響應，現在有了多設備的管理，RIL層的接口需要增加設備ID，用來標識對不同設備的操作，因此在這裡提供的API參數中增加了設備ID ；同時為了保持和以前接口的一致性和兼容性，接口的功能和業務上和原有系統基本保持一致， 僅僅增加了 NDIS設備特有的一些接口定義，例如獲取網絡接口名稱(qmi_get_netWOrk_ interface一name) >(qmi_get_conn_duration)、NDIS i殳Ι profile 1 (qmi_profile_get)等。設備管理模塊405該模塊主要處理對於設備的狀態檢測和管理一是對設備的熱插拔做出響應負責設備插入後，設備節點的註冊和設備隊列的維護，以及號量的初始化等；設備拔出後，設備節點隊列的維護，設備狀態信息的清理等；二是對設備操作API的封裝，如打開、關閉、讀、寫等，這些操作接口類似於文件的操作；三是設備狀態的維護，設備拔出等異常操作時， 設備狀態的維護。下面結合圖4對上行數據和下行數據的傳輸分別進行說明。圖5是根據本發明實施例的下行數據傳輸的流程圖，如圖5所示，該流程包括如下步驟步驟S501，RIL層接收到Android系統的各種功能調用；步驟S502，根據不同的業務類型，調用QmiClient模塊對應的接口 ；步驟S503，判斷消息的類型，如果是CTL相關，則轉往步驟S504 ；如果是WDS相關， 則轉往步驟S505 ；如果是DMS相關，則轉往步驟S506 ；步驟S504，根據CTL消息的格式，封裝對應的CTL消息，封裝完成後，轉往步驟 S507 ；步驟S505，根據WDS消息的格式，封裝對應的WDS消息，封裝完成後，轉往步驟 S507 ；步驟S506，根據DMS消息的格式，封裝對應的DMS消息，封裝完成後，轉往步驟 S507 ；步驟S507，消息處理模塊通過socket機制將封裝好的數據發送出去；步驟S508，QmiDaemon模塊接收來自sokcet的消息，收到消息後轉往步驟S509 ；步驟S509，處理消息隊列的維護；步驟S510，設備管理模塊檢測到消息隊列有需要處理的消息，則通過設備操作接口對設備進行操作。圖6是根據本發明實施例的上行數據傳輸的流程圖，如圖6所示，該流程包括如下步驟步驟S601，採用線程機制，啟動設備數據讀取線程。步驟S602，循環判斷設備是否有數據，如果有數據則轉入步驟S603處理，否則繼續等待並檢測消息。步驟S603，預先將收到的數據封裝成固定的消息格式，然後放進消息隊列。步驟S604，採用線程機制，預先啟動Qmi消息接收線程。步驟S605，循環判斷接收消息隊列是否有數據，如果有，則轉入步驟S606處理，否則繼續等待並檢測消息。步驟S606，解析從消息隊列獲取的消息。步驟S607，將解析後的消息通過socket機制發送。步驟S608，採用線程機制，預先啟動socket消息接收線程。步驟S609，在socket檢測線程中，循環檢測是否有socket消息，如果有，則轉入步驟S610處理，否則繼續等待並檢測消息。步驟S610，解析socket消息。步驟S611，將解析後的數據返回給RIL層接口。顯然，本領域的技術人員應該明白，上述的本發明的各模塊或各步驟可以用通用的計算裝置來實現，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網絡上，可選地，它們可以用計算裝置可執行的程序代碼來實現，從而可以將它們存儲在存儲裝置中由計算裝置來執行，或者將它們分別製作成各個集成電路模塊，或者將它們中的多個模塊或步驟製作成單個集成電路模塊來實現。這樣，本發明不限制於任何特定的硬體和軟體結合。 以上所述僅為本發明的優選實施例而已，並不用於限制本發明，對於本領域的技術人員來說，本發明可以有各種更改和變化。凡在本發明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發明的保護範圍之內。
權利要求
1.一種設備驅動消息處理方法，其特徵在於包括如下步驟通過提供給上層協議的第一接口，與所述上層協議對應的上層進行消息的傳輸；將來自所述上層協議的消息按照設備驅動所支持的協議進行封裝，並且，將來自所述設備驅動的消息使用所述設備驅動所支持的協議將該消息解封裝為所述上層協議所支持的消息格式；通過提供給所述設備驅動的第二接口，與所述設備驅動傳輸消息，其中，該消息的格式為所述設備驅動所支持的協議的格式。
2.根據權利要求1所述的方法，其特徵在於，在通過所述第一接口進行傳輸的消息中攜帶有設備標識的情況下，通過所述第二接口與所述設備驅動傳輸消息包括，根據所述設備標識通過所述第二接口將攜帶有該設備標識的消息發送給與所述設備標識對應的設備驅動。
3.根據權利要求1所述的方法，其特徵在於，還包括對通過所述設備驅動接入的設備進行狀態檢測和管理。
4.根據權利要求1至3中任一項所述的方法，其特徵在於，所述設備驅動為NDIS設備驅動，和/或，所述上層協議為RIL。
5.一種設備驅動消息處理裝置，其特徵在於包括第一傳輸模塊，用於通過提供給上層協議的第一接口，與所述上層協議對應的上層進行消息的傳輸；消息處理模塊，用於將來自所述上層協議的消息按照設備驅動所支持的協議進行封裝，並且，將來自所述設備驅動的消息使用所述設備驅動所支持的協議將該消息解封裝為所述上層協議所支持的消息格式；第二傳輸模塊，用於通過提供給所述設備驅動的第二接口，與所述設備驅動傳輸消息， 其中，該消息的格式為所述設備驅動所支持的協議的格式。
6.根據權利要求5所述的裝置，其特徵在於，所述第二傳輸模塊，用於在通過所述第一接口進行傳輸的消息中攜帶有設備標識的情況下，根據所述設備標識通過所述第二接口將攜帶有該設備標識的消息發送給與所述設備標識對應的設備驅動。
7.根據權利要求5所述的裝置，其特徵在於，還包括設備管理模塊，用於對通過所述設備驅動接入的設備進行狀態檢測和管理。
8.根據權利要求5至7中任一項所述的裝置，其特徵在於，所述設備驅動為NDIS設備驅動，和/或，所述上層協議為RIL。
全文摘要
本發明公開了設備驅動消息處理方法及裝置，該方法包括如下步驟通過提供給上層協議的第一接口，與上層協議對應的上層進行消息的傳輸；將來自上層協議的消息按照設備驅動所支持的協議進行封裝，並且，將來自設備驅動的消息使用設備驅動所支持的協議將該消息解封裝為上層協議所支持的消息格式；通過提供給設備驅動的第二接口，與設備驅動傳輸消息，其中，該消息的格式為設備驅動所支持的協議的格式。通過本發明提高了作業系統對設備驅動的兼容性。
文檔編號G06F13/10GK102360307SQ20111023588
公開日2012年2月22日 申請日期2011年8月17日 優先權日2011年8月17日
發明者李焰峰, 範鎖平 申請人:中興通訊股份有限公司