WO2012151908A1

WO2012151908A1 - Drive processing method and apparatus

Info

Publication number: WO2012151908A1
Application number: PCT/CN2011/082364
Authority: WO
Inventors: 李焰峰; 范锁平
Original assignee: 中兴通讯股份有限公司
Priority date: 2011-08-16
Filing date: 2011-11-17
Publication date: 2012-11-15
Also published as: CN102385557A; CN102385557B

Abstract

Disclosed are a drive processing method and apparatus. The method includes: receiving a message and judging whether or not the protocol adopted by the message is a protocol supported by the original protocol processing module of the network drive, wherein the network drive is used for directly providing drive to a device; in the situation where the judgment result is no, sending the message to the previously added protocol processing module for processing; and in the situation where the judgment result is yes, sending the message to the original protocol processing module for processing. The present invention can make it easy to transplant to other systems a specific protocol in a certain operating system, thereby making the operating system more extensive.

Description

TECHNICAL FIELD The present invention relates to the field of communications, and in particular to a driving processing method and apparatus. BACKGROUND OF THE INVENTION Based on the global wireless chip format, the high-speed access solution for mobile broadband devices of Qualcomm and Microsoft's network driver interface spec (NDIS) + Qualcomm MSM Interface (QMI) has become One of the mainstream access methods for mobile broadband devices; however, the DIS+QMI method is currently only applied on Windows systems, and this access method has not been extended to more operating systems. The same problem may exist with other access methods, that is, it can only be used in some operating systems. For other operating systems (for example, Android Android mobile operating system), applications are also constantly being promoted, so adapting various mobile broadband devices on these systems has become one of the main tasks at present; For a driver applied to a specific system, it is difficult to copy it to other operating systems. For example, the NDIS driver applied to a Windows system is a set of specifications defined by Windows, which is difficult to copy or port to the Android operating system, so The driver for NDIS device access cannot be supported on the Android system. In the prior art, there is a problem that a specific protocol cannot be ported to another operating system on an operating system, and there is currently no solution. SUMMARY OF THE INVENTION The present invention provides a driving processing method and apparatus to solve at least the above problems.

According to an aspect of the present invention, a driving processing method is provided, including the steps of: receiving a message, and determining whether a protocol adopted by the message is a protocol supported by a network-driven original protocol processing module, where The network driver is configured to provide direct driving to the device; if the determination result is negative, the message is sent to a protocol processing module added in advance in the network driver for processing; if the determination result is yes, Sending the message to the original protocol processing module for processing.

Preferably, the added protocol processing module provides at least one of the following interfaces for supporting the network driver: an initialization interface, a read interface, a write interface, and an input/output control interface.

Preferably, the read operation performed by the added protocol processing module by the read interface includes: after detecting the message of the read operation, putting the read operation message into the read queue; after receiving the wakeup message, calling The read interface performs the read operation. Preferably, the writing operation by the added protocol processing module by using the write interface comprises: sending, by the write interface of the added protocol processing module, the message to the format supported by the network driver device.

Preferably, the network driver comprises: a USB device type communication-Ethernet control mode CDC-ECM. Preferably, the protocol processed by the added protocol processing module comprises: DIS and / or QMI. According to another aspect of the present invention, a driving processing apparatus is provided, including: a determining module configured to receive a message, and determine whether a protocol adopted by the message is a protocol supported by a network-driven original protocol processing module The network driver is configured to provide direct driving to the device; and the processing module is configured to send the message to a protocol processing module added in advance in the network driver for processing if the determination result is negative. If the judgment result is yes, the message is sent to the original protocol processing module for processing.

Preferably, the network driver comprises: a USB CDC-ECM.

Preferably, the protocol processed by the added protocol processing module comprises: DIS and / or QMI. According to the present invention, the receiving message is used, and it is determined whether the protocol adopted by the message is a protocol supported by the original protocol processing module of the network driver, wherein the network driver is used to provide direct driving to the device; If the result is no, the message is sent to a protocol processing module added in advance in the network driver for processing; if the determination result is yes, the message is sent to the original protocol processing. The module is processed to solve the problem that the specific protocol in a certain operating system cannot be transplanted to other operating systems in the prior art, and the specific protocol on a certain operating system can be easily transplanted to other systems. Make the operating system more scalable. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are set to illustrate,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, In the drawing:

1 is a flow chart of a driving processing method according to an embodiment of the present invention;

2 is a block diagram showing the structure of a driving processing apparatus according to an embodiment of the present invention;

3 is a schematic diagram of a USB Ethernet driver of an Android system related to an embodiment of the present invention; FIG. 4 is a schematic diagram of an NDIS driving method of an Android system according to a preferred embodiment of the present invention; Figure 5 is a flow diagram of a write operation in accordance with an embodiment of the present invention; Figure 6 is a flow diagram of a read operation in accordance with an embodiment of the present invention. BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict. A driving processing method is provided in this embodiment. FIG. 1 is a flowchart of a driving processing method according to an embodiment of the present invention. As shown in FIG. 1, the method includes the following steps:

Step S102: Receive a message, and determine whether the protocol used by the message is a protocol supported by an original protocol processing module of the network driver, where the network driver is used to provide direct driving to the device.

Step S104: If the determination result is negative, the message is sent to the protocol processing module added in advance in the network driver for processing; if the determination result is yes, the message is sent to the original protocol processing. The module processes it.

Through the above steps, based on the original network driver in the operating system, only the modules supported by other protocols are added, and the developer only pays attention to the development of the protocol module, and the processing of the network driver is handed over to the original of the operating system. Some network drivers are available. For the original network driver, only the function of adding judgments can be added. There is no need to make a large number of changes, and the original functions of the network driver are not affected, that is, compatibility is achieved, and It is convenient to transplant the support of other protocols, so that the driving processing method in this embodiment has good scalability.

Preferably, at least one of the following interfaces may be selected to support the network driver according to the needs of the added protocol processing module: an initialization interface, a read interface, a write interface, and an input/output control interface. In a preferred embodiment, a better processing manner is provided for the read operation: after the message of the read operation is detected, the read operation message is put into the read queue; after receiving the wake-up message, the read interface is called. Read operation.

In another preferred processing mode, a better processing method is also provided for the write operation: The write interface of the added protocol processing module sends the message to the device in a format supported by the network driver. In the embodiment, a driving processing device is also provided, which is used to implement the above-mentioned embodiments and preferred embodiments, and has not been described again. As used hereinafter, the term "module" may implement a combination of software and/or hardware of a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware, is also possible and conceivable. 2 is a block diagram showing the structure of a driving processing apparatus according to an embodiment of the present invention. As shown in FIG. 2, the apparatus includes a judging module 22 and a processing module 24. The modules involved in the apparatus are described below. The determining module 22 is configured to receive the message, and determine whether the protocol used by the message is a protocol supported by the original protocol processing module of the network driver, where the network driver is used to provide direct driving to the device; the processing module 24 , if the judgment result is negative, the message is sent to the protocol processing module added in advance in the network driver for processing; if the determination result is yes, the message is sent to the original protocol processing module. Process it.

For the network driver, the USB CDC-ECM (Class Definitions for Communication Devices-Ethernet Control Model) can be used. For example, in the Android system, in this embodiment, the portable protocols include: NDIS and / Or QMI, but is not limited thereto, and the following description will be made by way of an example with reference to a preferred embodiment.

3 is a schematic diagram of a USB Ethernet driver of an Android system related to an embodiment of the present invention, as shown in FIG.

3, including Read/Write (read/write) interface, core space CDC ECM module, USB NET module and USB CORE module, and hardware device USB device, USB CDC ECM driver model existing drive mode on Android system The control protocol defined by the USB CDC ECM driver model is enumerated as a request. This method cannot support the existing NDIS device, and it cannot support the QMI protocol in this driver mode. The USB CDC ECM driver model is part of the USB CDC protocol and is part of the standard USB protocol. The current NDIS device does not fully comply with the standard USB protocol. It uses the NDIS specification for Windows and uses Qualcomm's custom QMI protocol. The control protocol for the host to communicate with the device, not the control protocol defined by the USB CDC ECM driver model.

In the preferred embodiment, a driving method on an Android system is provided for implementing driving and data access of a high speed mobile broadband device on an Android system.

The driver of the USB CDC-ECM has been provided on the existing Android system. On the basis of the driver, the preferred embodiment implements the driving support of the NDIS device, which solves the problem that the current Android system cannot support the access of the NDIS device. It also laid a solid foundation for the subsequent Android system to support NDIS devices.

4 is a schematic diagram of an NDIS driving method of an Android system according to a preferred embodiment of the present invention. As shown in FIG. 4, a CDC_ENCAP module is added to an existing USB CDC ECM driver, and a CDC_ECM module is modified. Added CDC_ENCAP module for support of own protocol, providing customized read, write, input/output (I/O) control interface; modified CDC_ECM module for device connection Intrusion detection, status detection, CDC_ENCAP module initialization, etc. The CDC_ECM module and the CDC_ENCAP module are described below. CDC_ECM module 201: The CDC_ECM module is modified for direct driving of the device; in this module, the support for the USB CDC ECM protocol in the existing driver is extended, and the notification message RESPONSE-AVAILABLE in the CDC state detection is added. Support (refer to section 3.8.2 of “usb cdcl.2”, which will not be described here), so that custom protocol (such as QMI protocol) messages from the mobile broadband device side can be processed; secondly in the device detection phase (probe) ), by calling the cdc_en _C ap_init interface, to achieve Custom protocol processing functions, mutex, and message queue initialization, so that the process of custom protocol processing can be transferred to the CDC_ENCAP module for processing.

CDC_ENCAP Module 202: Added CDC_ENCAP module to encapsulate support for proprietary protocols; In this module, CDC encap init, cdc encap read, cdc encap write, cdc encap ioctl file interface is provided, providing CDC_ECM Module support; the cdc_encap_init interface implements the initialization of the custom protocol handler, mutex, message queue, and the registration of the driver interface function through the initialization of the Linux system file interface structure file_operations; cdc_encap_read interface through USB The control message reads the response message of the mobile terminal side custom protocol; the cdc_encap_write interface sends the encapsulated custom protocol message to the mobile broadband device side in the form of a USB control message; cd _C _ _enca p_i ₀ ctl interface provides other Support for I/O class operations.

The functions of the USB NET module 203 and the USB CORE module 204 are similar to those of the existing modules and will not be described here. The following describes the read and write operations in conjunction with the above modules.

FIG. 5 is a flowchart of a write operation according to an embodiment of the present invention. As shown in FIG. 5, the flow includes the following steps:

Step S501: The user mode program invokes a write operation.

Step S502, the driver calls different processing processes according to different message types; if it is a USB CDC ECM message, go to step S503; otherwise, go to step S504;

Step S503, if it is a USB CDC ECM message, the process flow of installing the existing driver, go to step S506; Step S504, if it is not a USB CDC ECM message, enter the write operation process flow driven by the present invention, go to step S505;

Step S505, the upper layer of the write data is processed by calling the interface of the USB CORE; step S506, responsible for the specific USB data write operation;

Step S507, determining whether the data is successfully written, if successful, proceeding to step S508, otherwise proceeding to step S509; step S508, the data writing is successful, and the return is successful;

Step S509, the data write fails, and the exception processing is performed;

6 is a flow chart of a read operation according to an embodiment of the present invention. As shown in FIG. 6, the flow includes the following steps:

Step S601, driving initialization, initializing the read queue, and starting a message detection mechanism;

Step S602, detecting a CDC STATUS message (a status message of the CDC), determining a message type, such as If it is a CONNECTION message (connection message), the process goes to step S607, if it is a SPEED CHANGE message (shift message) to step S608, if it is a RESPONSE message (response message), the process goes to step S609; in step S603, the user mode program calls the read operation.

Step S604, after the user state to the core state is converted, enter the CDC_ENCAP module; Step S605, after the CDC_ENCAP module searches for the read operation message, put the message into the read queue; Step S606, the message in the read queue waits to be Wake up

Step S607, parsing the received CONNECTION message, detecting the validity, according to the original processing flow, proceeding to step S615;

Step S608, parsing the received SPEED CHANGE message, after detecting the validity, according to the original processing flow, proceeding to step S615;

Step S609, parsing the received SPEED CHANGE message, and detecting the validity, waking up the read message queue in the CDC_ENCAP module;

Step S610, determining whether the message in the read queue is awakened, and waking up to step S611, otherwise proceeding to step S606; step S611, after the read queue is awakened, determining whether there is a message in the queue, if there is a step S612, otherwise Go to step S616 to perform exception processing;

Step S612, performing read processing by using the interface CDC_ENCAP_READ;

Step S613, determining whether the read processing is successful, if successful, proceeding to step S613, otherwise proceeding to step S616 to perform exception processing; step S614, returning data acquired by the read operation;

Step S615, the message processing flow that the existing driver has implemented;

Step S616, exception processing. The following effects are achieved by the above embodiments, and it is to be noted that the following effects are not achieved by each of the embodiments, and some effects are possessed by some preferred embodiments.

1. Expanded the existing CDC ECM driver, enabling the existing CDC ECM driver to support both the original USB CDC ECM device and the new NDIS device. It is compatible with both the original device driver and some operating systems. (For example, Android system) Added support for NDIS devices, existing NDIS devices can be adapted to Android system without any modification, and some operating systems cannot support NDIS devices and existing drivers cannot be effective. Improve the speed of transmission between mobile broadband devices. 2. Versatility: NDIS equipment will undoubtedly be one of the mainstream access methods for subsequent mobile broadband devices. Therefore, the design and implementation of NDIS devices are supported on operating systems that do not support the protocol, which greatly complies with the subsequent multi-standard devices. The development trend of access methods and technologies extends the versatility of operating system functions and access methods.

3. Scalability: The solution of the preferred embodiment is to integrate the access mode of the DIS device into the existing driver of the operating system, compatible with the original device driver, without modifying the architecture of the operating system framework layer, and adding an operating system. The access mode of the mobile broadband device increases the scalability of the operating system; at the same time, the support for the custom protocol (such as Qualcomm's QMI protocol) is added, so that the driving method in the above preferred embodiment has greater scalability.

Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device so that they may be stored in the storage device by the computing device, or they may be separately fabricated into individual integrated circuit modules, or Multiple modules or steps are made into a single integrated circuit module. Thus, the invention is not limited to any specific combination of hardware and software. The above description is only a preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and scope of the present invention are intended to be included within the scope of the present invention.

Claims

Claim

1. A drive processing method comprising the following steps:

Receiving a message, and determining whether the protocol used by the message is a protocol supported by an original protocol processing module of the network driver, where the network driver is used to provide direct driving to the device; And sending the message to a protocol processing module added in advance in the network driver for processing; if the determination result is yes, sending the message to the original protocol processing module for processing.

2. The method of claim 1, wherein the added protocol processing module provides at least one of the following interfaces for supporting the network driver:

Initialize interface, read interface, write interface, input/output control interface.

The method according to claim 2, wherein the read operation performed by the added protocol processing module by using the read interface comprises:

After detecting the message of the read operation, the message of the read operation is put into the read queue; after receiving the wake-up message, the read interface is called to perform the read operation.

4. The method according to claim 2, wherein the writing by the added protocol processing module through the write interface comprises:

The write interface of the added protocol processing module sends the message to the device in a format supported by the network driver.

The method according to any one of claims 1 to 4, wherein the network driver comprises: a USB CDC-ECM.

6. The method according to claim 5, wherein the protocol processed by the added protocol processing module comprises: DIS and/or QMI.

7. A drive processing device comprising:

The determining module is configured to receive the message, and determine whether the protocol used by the message is a protocol supported by the original protocol processing module of the network driver, where the network driver is used to provide direct driving to the device; The processing module is configured to: if the determination result is negative, send the message to a protocol processing module added in advance in the network driver for processing; if the determination result is yes, send the message to The original protocol processing module performs processing. The apparatus of claim 7, wherein the added protocol processing module provides at least one of the following interfaces for supporting the network driver:

Initialize interface, read interface, write interface, input/output control interface. The apparatus according to claim 7 or 8, wherein the network driver comprises: a USB device type communication - an Ethernet control mode CDC-ECM. The apparatus according to claim 7 or 8, wherein the protocol handled by the added protocol processing module comprises: a network driver interface specification DIS and/or a Qualcomm MSM interface QMI.