Device driving method, preset driving module, electronic device and storage medium

Abstract

The embodiment of the invention provides a device driving method, a preset driving module, an electronic device and a storage medium, and the method comprises the steps: monitoring a newly inserted target device in a system, obtaining a device identifier of the target device, and if it is queried that a preset conversion list contains the device identifier of the target device, switching the target device to the preset conversion list; if yes, storing an equipment handle and equipment information of the target equipment in a first equipment list, and modifying the equipment type into the target equipment type; creating a device object corresponding to the target device, and sending a notification message to the Wine kernel; receiving a calling request of the Wine kernel for the equipment adding interface, wherein the calling request carries the equipment object; and creating a functional device object corresponding to the target device based on the device identifier in the device object, and binding the functional device object of the target device with the physical device object of the target device. According to the application, the problem that the application program running in the Wine cannot identify and use the corresponding HID equipment can be solved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a device driving method, a preset driving module, an electronic device and a storage medium. Background Art

[0002] A USB (Universal Serial Bus) device is an external device that connects to a computer or other host device through a USB port. USB devices usually include the following:

[0003] Audio Class: such as microphone, speaker, etc.

[0004] Image Class: such as cameras, scanners, etc.

[0005] Printer Class: such as a printer.

[0006] Mass Storage Class: such as USB flash drives, mobile hard drives, and optical drives.

[0007] Human Interface Device (HID): such as mouse, keyboard, game controller, touchpad and handwriting tablet.

[0008] Wine is a compatibility layer that allows Windows applications to run on Linux systems. However, there are fewer types of drivers for HID devices in Linux systems than in Windows systems. Therefore, for some HID devices, since there are corresponding drivers in Windows systems, applications running in Windows systems can recognize and use the corresponding HID devices; while in Linux systems, due to the lack of drivers for these HID devices, applications running in Wine cannot recognize and use the corresponding HID devices. Summary of the invention

[0009] In view of the above problems, an embodiment of the present application is proposed to provide a device driving method that overcomes the above problems or at least partially solves the above problems. A preset driver module can be used to correctly drive the HID device, thereby solving the problem that the application running in Wine cannot recognize and use the corresponding HID device.

[0010] Correspondingly, the embodiment of the present application also provides a preset driving module, an electronic device, and a storage medium to ensure the implementation and application of the above method.

[0011] In a first aspect, an embodiment of the present application discloses a device driver method, which is applied to Wine, a compatibility layer of a Linux system, wherein a pre-set driver module is run with a kernel driver program in Wine, wherein a device adding interface and a main function processing function of a pre-set device are implemented in the pre-set driver module, and the method comprises:

[0012] In the case of monitoring that a target device is newly inserted into the Linux system, obtaining a device identification of the target device, and querying a preset conversion list, wherein the preset conversion list includes the device identification of the preset device;

[0013] If the preset conversion list contains the device identification of the target device, the device handle and device information of the target device are saved in the first device list; the device information includes the device identification and device type of the target device, and the device type is changed from the general USB device type to the target device type;

[0014] Create a device object corresponding to the target device, the device object includes the device identifier of the target device, and send a notification message to the Wine kernel, the notification message carries the device object;

[0015] receiving a call request from the Wine kernel to add an interface to the device, wherein the call request carries the device object;

[0016] Based on the device identification in the device object, a functional device object corresponding to the target device is created, and the functional device object of the target device is bound to the physical device object of the target device.

[0017] In a second aspect, an embodiment of the present application discloses a preset driver module, which is applied to Wine, a compatibility layer of a Linux system. In Wine, the preset driver module is run as a kernel driver. The preset driver module implements a device adding interface and a main function processing function of a preset device. The preset driver module includes:

[0018] An insertion monitoring module is used to obtain a device identification of the target device and query a preset conversion list when monitoring that a target device is newly inserted into the Linux system, wherein the preset conversion list includes the device identification of the preset device;

[0019] A device adding module, for saving the device handle and device information of the target device in the first device list if the device identifier of the target device is found in the preset conversion list; the device information includes the device identifier and device type of the target device, and the device type is changed from a general USB device type to a target device type;

[0020] A first creation module is used to create a device object corresponding to the target device, the device object includes a device identifier of the target device, and send a notification message to the Wine kernel, the notification message carries the device object;

[0021] The second creation module is used to receive a call request from the Wine kernel to add an interface to the device, the call request carrying the device object; based on the device identifier in the device object, create a functional device object corresponding to the target device, and bind the functional device object of the target device to the physical device object of the target device.

[0022] In the third aspect, an embodiment of the present application discloses an electronic device, comprising: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, and the executable instruction enables the processor to execute the steps of any device driving method described above.

[0023] In a fourth aspect, an embodiment of the present application discloses a readable storage medium, on which a program or instruction is stored, and when the program or instruction is executed by a processor, any device driving method described in the embodiment of the present application can be implemented.

[0024] The device driving method, pre-installed driving module, electronic device and storage medium provided by the embodiments of the present application have the following advantages:

[0025] The present application adds a preset driver module in Wine, and the preset driver module runs in Wine as a kernel driver. When a new target device is inserted into the Linux system, if the target device is found to be a preset device in the preset conversion list (such as a HID device that lacks a corresponding driver in the Linux system), the device handle and device information of the target device are saved in the first device list, and its device type is modified from a general USB device type to a target device type (such as a HID device type), so that the target device can be operated according to the correct device type. Further, the preset driver module implements a device adding interface and a main function processing function of the preset device. By calling the device adding interface, a functional device object corresponding to the target device can be created, and the functional device object of the target device can be bound to the physical device object of the target device, so that when the main function processing function is subsequently called, it can ensure that the I / O request can be correctly executed on the physical device. Through the embodiment of the present application, the preset driver module can be used to correctly drive the HID device, so that the HID device that lacks a driver in the Linux system can be driven by the preset driver module, and then the Windows application running in Wine can use the HID device normally. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 This is a flowchart of the abnormality caused by the lack of HID device driver in Linux system;

[0027] Figure 2 This is a flowchart of the present application for adding a preset driver module in Wine to eliminate anomalies;

[0028] Figure 3 is a flowchart of a device driving method embodiment of the present application;

[0029] Figure 4 It is a schematic diagram of the functional composition of the preset drive module provided by the present application;

[0030] Figure 5 is a flowchart of processing an I / O request in an example of this application;

[0031] Figure 6 is a flowchart of processing a read / write request in an example of this application;

[0032] Figure 7 is a flowchart of processing a device removal operation in an example of the present application;

[0033] Figure 8 is a structural block diagram of an embodiment of a preset drive module of the present application;

[0034] Fig. 9 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0035] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, the present application is further described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0036] The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally a class, and the number of objects is not limited. For example, the first object can be one or more. In addition, the term "and / or" in the specification and claims is used to describe the association relationship of associated objects, indicating that three kinds of relationships can exist, for example, A and / or B can be represented: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the front and back associated objects are a kind of "or" relationship. In the embodiment of the present application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0037] Reference Figure 1 , shows a schematic diagram of the process of causing anomalies due to the lack of HID device drivers in the Linux system. Figure 1 As shown:

[0038] 1. Insert the USB device into the USB port of the operating system; the USB device is a HID device;

[0039] 2. The system detects the device connection and sends a request to the USB device to obtain the device descriptor information;

[0040] 3. The USB device returns device descriptor information;

[0041] 4. The system determines the device type based on the device descriptor information and identifies it as a HID device type, but cannot find the corresponding driver, so it uses a generic USB driver to bind;

[0042] 5. The device is ready and the system or application can use the device;

[0043] 6. The Wine kernel searches for HID devices in the system through libudev;

[0044] 7. The system returns an empty search result, which makes the application unable to use the USB device.

[0045] Since the Linux system lacks drivers for some HID devices, these HID devices are treated as generic USB devices in the Linux system (Exception 1), which in turn causes Wine to search for empty HID devices in the Linux system (Exception 2), which in turn causes the application to be unable to use the HID devices normally (Exception 3).

[0046] Reference Figure 2 , shows a flow chart of the present application for eliminating the above-mentioned anomaly by adding a preset driver module in Wine.

[0047] To solve Figure 1 In order to solve the exception that occurs in the process of using Wine, the present application adds a preset driver module in Wine, which can provide the following functions: for HID devices that are processed as generic USB device types due to the lack of drivers in the Linux system, convert their device types from generic USB device types to correct target device types (such as converting them to HID device types); and drive the correctly identified USB devices for use by applications.

[0048] The preset driver module runs in the compatibility layer Wine of the Linux system as a kernel driver. The preset driver module implements a device adding interface and a main function processing function of the preset device, so as to realize driving the preset device. The preset device can be a HID device that lacks a corresponding driver in the Linux system.

[0049] Figure 3 A flowchart of a device driver method embodiment of the present application is shown, which is applied to a pre-installed driver module running in the compatibility layer Wine of a Linux system. The method may include the following steps:

[0050] Step 101: when a target device is newly inserted into the Linux system, the device identification of the target device is acquired, and a preset conversion list is queried, wherein the preset conversion list includes the device identification of the preset device;

[0051] Step 102: If the preset conversion list contains the device identifier of the target device, the device handle and device information of the target device are saved in the first device list; the device information includes the device identifier and device type of the target device, and the device type is changed from the general USB device type to the target device type;

[0052] Step 103: Create a device object corresponding to the target device, the device object includes the device identifier of the target device, and send a notification message to the Wine kernel, the notification message carries the device object;

[0053] Step 104: receiving a call request from the Wine kernel to add an interface to the device, wherein the call request carries the device object;

[0054] Step 105: Create a functional device object corresponding to the target device based on the device identifier in the device object, and bind the functional device object of the target device to the physical device object of the target device.

[0055] The steps of the device driving method provided in the present application are mainly described with the preset driving module as the execution body. The present application implements a general device driving method by adding a preset driving module without changing the original processing flow of the operating system.

[0056] The device driving method provided in the present application can be applied to electronic devices based on the Linux operating system. The electronic devices may include but are not limited to any of the following: servers, smart phones, voice recorders, tablet computers, e-book readers, MP3 (Moving Picture Experts Group Audio Layer III) players, MP4 (Moving Picture Experts Group Audio Layer IV) players, laptop computers, car computers, desktop computers, set-top boxes, smart TVs, wearable devices, etc.

[0057] This application does not limit the type of the Linux operating system. For example, the Linux operating system may include but is not limited to any one of Debian, Ubuntu, CentOS (Community Enterprise Operating System), UOS (Unicom Desktop Operating System), Kylin Operating System, and Fangde Operating System.

[0058] The Linux system runs a compatibility layer Wine, which can run Windows applications. This application adds a pre-installed driver module in Wine, refer to Figure 4 , showing a schematic diagram of the functional structure of the preset drive module provided in the present application.

[0059] like Figure 4As shown, the driver module provides a driver entry function (DriverEntry) to implement driver entry; provides a device addition interface (AddDrvice) to implement adding device function objects; provides a driver unloading interface (Unload) to implement unloading the preset driver module; and provides a main function processing function of the preset device to implement operating the preset device. The main function processing function refers to the IRP (I / O Request Packet) main function. IRP refers to the I / O request packet, that is, the input and output request packet. IRP is a data structure used to transmit I / O requests in the Windows operating system. IRP contains relevant information about the I / O operation, such as the operation type, operation object, parameters, and completion status. This information is transmitted between various components of the operating system (such as applications, drivers, and Wine kernel, etc.) to complete the processing of I / O requests. I / O requests may include device creation (IRP_MJ_CREATE), device close (IRP_MJ_CLOSE), read data (IRP_MJ_READ), write data (IRP_MJ_WRITE), plug and play PnP (IRP_MJ_PNP), and device control (IOCTL), etc.

[0060] Wine kernel refers to the core component of Wine, which is responsible for managing device drivers, etc., and is also called a driver manager.

[0061] The preset driver module provides a driver entry function DriverEntry, so that the Wine kernel loads the preset driver module by calling the driver entry function after Wine is started. The driver entry function is used to initialize the preset driver module, register the main function processing function provided by the preset driver module, set the device type supported by the preset driver module, and return the loading result flag (such as whether the loading is successful). Exemplarily, the device type supported by the preset driver module includes the device type of the preset device, so that the Wine kernel can send the I / O request for the preset device to the preset driver module of the present application for processing.

[0062] After the preset driver module is loaded successfully, it can monitor whether a USB device is inserted into the Linux system. If a USB device (called the target device) is inserted, the device identification of the target device is obtained. The device identification may include PID (Product ID) and VID (Vendor ID). PID is a unique identifier assigned to a specific product model by a device manufacturer, which is used to distinguish different products produced by the same manufacturer. VID is an identifier that uniquely identifies the manufacturer of the device.

[0063] Based on the device identification, a preset conversion list is queried, wherein the preset conversion list is pre-set and includes the device identification (such as PID and VID) of the preset device. In Windows system, the device type of the preset device can be correctly identified as a HID device type due to the existence of a corresponding driver; while in Linux system, the device type is identified as a general USB device type due to the lack of a corresponding driver.

[0064] If the preset conversion list contains the device identifier of the target device, it means that the target device is a preset device, and the Linux system lacks a driver for the target device, and needs to use the preset driver module of the present application to drive it.

[0065] Furthermore, after monitoring that a new target device is inserted into the Linux system in step 101, the method may further include:

[0066] Step S11, obtaining a second device list by calling a first function of a USB device access library, wherein the second device list includes device information of all USB devices connected to the Linux system;

[0067] Step S12: Compare the second device list with the preset conversion list to determine a target device that matches the second device list and has a device type that is a general USB device type;

[0068] Step S13: Open the target device by calling the second function of the USB device access library, and obtain the device handle of the target device.

[0069] The USB device access library (i.e., libusb) is an open source library for accessing USB devices. After initializing the libusb library, its first function (i.e., libusb_get_device_list) can be called to obtain the second device list. The second device list records the information of all USB devices connected to the system, and each connected USB device is represented as an object of the libusb_device type in the context of the libusb library. These objects contain information related to the USB device, such as PID, VID, device type, etc.

[0070] The preset driver module compares the second device list with the preset conversion list to determine a target device that matches the list and has a device type that is a universal USB device type. The target device that matches the list and has a device type that is a universal USB device type is a HID device that lacks a corresponding driver in the Linux system, and the Linux system has processed its device type as a universal USB device type, and the libusb library recognizes that the device type of the target device is a universal USB device type.

[0071] After querying the target device whose second device list matches the preset conversion list and whose device type is a universal USB device type, the present application opens the target device by calling the second function (i.e., libusb_open) of the libusb library and obtains the device handle of the target device.

[0072] The libusb_open function can be used to open a specified USB device and return a device handle (libusb_device_handle), which can be used to operate the USB device.

[0073] In the embodiment of the present application, the device handle (i.e., libusb_device_handle) and device information of the target device are saved in the first device list. The first device list is an internal list maintained by the preset driver module, which is used to save the device handle and device information of the preset device that has been opened; the device information includes the device identifier and device type of the target device. Since the device type of the target device enumerated by the libusb library is a general USB device type, that is, the device type of the target device in the second device list is a general USB device type, this device type is not the correct device type. Therefore, when the embodiment of the present application saves the device information of the target device in the first device list, the device type of the target device in the first device list is modified from the general USB device type to the HID device type, and modified to the correct device type, so that subsequent operations on the target device can be performed based on the correct device type. It should be noted that the present application does not modify the device type in the second device list obtained by the libusb library.

[0074] Furthermore, after the target device is opened by the second function libusb_open, the report descriptor information of the target device may be read and the report descriptor information may be stored in the memory.

[0075] Specifically, the descriptor information of each level can be obtained according to the hierarchical relationship of the descriptor information in the HID device. For example, after opening the target device through the second function libusb_open, the device handle (libusb_device_handle) of the target device can be obtained, and the file descriptor information of the target device can be obtained according to the device handle. According to the file descriptor information of the target device, the configuration descriptor information of the target device can be obtained. According to the configuration descriptor information of the target device, the interface descriptor information of the target device can be obtained. According to the interface descriptor information of the target device, the report descriptor information of the target device can be obtained.

[0076] The report descriptor information specifies the data format for communicating with the HID device. In addition to saving the device handle and device information of the target device in the first device list, the embodiment of the present application can also save the report descriptor information of the target device. As a result, when the subsequent preset driver module communicates with the target device, it can communicate based on the data format specified by the saved report descriptor information. Furthermore, the descriptor information of each level can also be saved for use in the subsequent operation of the target device.

[0077] Next, the preset driver module creates a device object corresponding to the target device, wherein the device object contains a device identifier for specifying the device to be operated. The preset driver module sends a notification message to the Wine kernel to notify the Wine kernel that a new device (target device) has been added, wherein the notification message carries the device object of the target device.

[0078] After receiving the notification message, the Wine kernel calls the device adding interface (ie AddDrvice) provided by the preset driver module. The preset driver module receives a calling request of the device adding interface sent by the Wine kernel, and the calling request carries the device object.

[0079] The device adding interface AddDrvice is used to create a functional device object corresponding to the target device based on the device identifier in the device object, and bind the functional device object of the target device to the physical device object of the target device.

[0080] A physical device object (PDO) is an abstraction of a physical device by the operating system. It represents the actual hardware device itself. PDO is usually created by the operating system.

[0081] Functional Device Object (FDO), located above PDO in the device stack, is mainly used to implement specific functions of the device. FDO is usually created by the device driver.

[0082] For example, for a USB camera device, PDO represents the physical USB connection, while FDO contains the logic to implement functions such as video acquisition, image format conversion, video streaming, etc. FDO processes various I / O requests through a series of main function processing functions to realize the functions of the device.

[0083] In the Linux system, the functional device object of the target device cannot be created due to the lack of the driver program of the target device. The pre-installed driver module in the embodiment of the present application implements the device adding interface AddDrvice. By calling this interface, the functional device object FDO corresponding to the target device can be created, and the functional device object FDO of the target device can be bound to the physical device object PDO of the target device.

[0084] FDO is used to implement device functions, such as data transmission, device control, etc., and the implementation of these functions needs to be based on the actual status and characteristics of the physical device. PDO contains the physical information of the device, such as PID and VID, bus information of the device connection (such as the port number and bus speed of the USB device connection), etc. After the preset driver module creates FDO for the target device, it binds the FDO of the target device to PDO, and obtains these key information of PDO to correctly implement the functions.

[0085] In the Windows device driver architecture, the device stack is a hierarchical structure, with PDO at the bottom layer, representing the physical device, and FDO above it, used to implement device functions. When an I / O request (such as reading device data) passes from the application through the Wine kernel to the preset driver module, it will be passed down the device stack. FDO combines functional operations (such as data reading) with the actual data source of the physical device (through the physical connection represented by PDO) through the binding relationship with PDO, ensuring that the I / O request can be correctly executed on the physical device.

[0086] In addition, the physical state of the device may change for various reasons, such as the device being unplugged, the device entering low-power mode, or the device failing. PDO can reflect these physical state changes in real time. After binding FDO to PDO, FDO can obtain these state change information in a timely manner, thereby adjusting the implementation strategy of the device function accordingly. For example, when the target device is accidentally unplugged, PDO will be marked as a device unavailable state. FDO can detect this change, stop ongoing operations (such as data transmission) in time, and send a notification of device unavailability to the upper-level application or driver to avoid data loss or system errors.

[0087] The embodiment of the present application adds a preset driver module in Wine, and the preset driver module runs in Wine as a kernel driver. When a new target device is inserted into the Linux system, if the target device is found to be a preset device (a HID device that lacks a corresponding driver in the Linux system), the device handle and device information of the target device are saved in the first device list, and its device type is changed from a general USB device type to a target device type (such as a HID device type). The preset driver module implements a device adding interface and a main function processing function of the preset device. By calling the device adding interface, a functional device object corresponding to the target device can be created, and the functional device object of the target device is bound to the physical device object of the target device, so that subsequent calls to the main function processing function can ensure that the I / O request can be correctly executed on the physical device. Through the embodiment of the present application, the preset driver module can be used to correctly drive the preset device, so that the preset device that lacks a driver in the Linux system can be driven by the preset driver module, and then the Windows application running in Wine can use the preset device (the HID device that lacks a corresponding driver in the Linux system) normally.

[0088] Furthermore, the present application can also solve the problem that the application in Wine cannot use USB devices due to the insufficient driver support of the Linux system for certain USB device types (such as mass storage devices). Specifically, the pre-set device can be a mass storage device that lacks a corresponding driver in the Linux system. The pre-set driver module implements the device addition interface and the main function processing function of the pre-set device (the mass storage device that lacks a corresponding driver in the Linux system). In this case, the target device type refers to the mass storage device type, so that the Windows application running in Wine can use the pre-set device (the mass storage device that lacks a corresponding driver in the Linux system) normally.

[0089] It can be understood that, in a specific embodiment, the target device type may include but is not limited to a human-machine interface device type, a mass storage device type, a printing device type, an image device type, an audio device type, and the like.

[0090] In an optional embodiment of the present application, the method may further include:

[0091] Sending the registration related information of the target device to the Wine kernel so that the Wine kernel registers the target device in a registry based on the registration related information, thereby enabling the Windows application running in the Wine to discover and operate the target device.

[0092] After step 105 is completed, the preset driver module can send the registration related information of the target device to the Wine kernel, so that the Wine kernel registers the target device in the registry based on the registration related information. Thus, the Windows application running in the Wine can discover and operate the target device.

[0093] In an optional embodiment of the present application, after step 105, the method may further include:

[0094] Step S21, receiving a first input / output request packet sent by the Wine kernel; the first input / output request packet carries a first main function code and the device object; the first main function code indicates to open the target device;

[0095] Step S22, execute the first main function processing function, the first main function processing function is used to set a success status code in the first input and output request packet, and return the processed first input and output request packet to the Wine kernel, so that the Wine kernel returns an object handle for operating the device object to the application.

[0096] After the Wine kernel registers the target device in the registry, the application program running in Wine can discover and operate the target device.

[0097] Before an application performs any operation on a USB device, it first needs to open the USB device. When the application calls an API (such as CreateFile) provided by the operating system to request to open a USB device (such as a target device), the Wine kernel receives the CreateFile request and converts it into an IRP (here referred to as the first input / output request packet) and sends it to the preset driver module for processing.

[0098] In a specific implementation, the components of an IRP may include: header information, a main function code (sometimes also a sub-function code), a parameter area and an I / O status block.

[0099] The header information includes some basic metadata, such as the size and type of the IRP.

[0100] The major function code defines the type of I / O request. For example, the major function code IRP_MJ_CREATE is used to indicate the creation or opening of a device object, and the major function code IRP_MJ_READ is used to indicate the reading of the contents of a device object.

[0101] The sub-function code provides more detailed operation information to supplement the main function code. For example, for the main function code IRP_MJ_READ, the sub-function code can be used to specify the starting position of the read, the number of bytes to read, and other detailed information.

[0102] Depending on the type of I / O operation, the parameter area can contain different parameters.

[0103] The I / O status block is used to record the completion status of the I / O operation, such as success or failure and the corresponding error code. The Wine kernel can know whether the I / O operation is successful by looking at the I / O status block.

[0104] The main function code of the first IRP is the first main function code (ie, IRP_MJ_CREATE), and the parameters include the device object (Device Object) of the target device; the first main function code is used to indicate creating or opening a device object (eg, opening the target device).

[0105] The preset driver module executes the first main function processing function, namely the IRP_MJ_CREATE processing function, which is used to set a success status code in the I / O status block of the first IRP, and return the processed first IRP to the Wine kernel, so that the Wine kernel returns an object handle for operating the device object to the application.

[0106] It should be noted that, since the target device has been opened through the libusb library, the device handle of the target device has been saved in the first device list, and the preset driver module can obtain the device handle of the target device by querying the first device list, and then operate the target device. Therefore, after receiving the first IRP with the main function code IRP_MJ_CREATE, the preset driver module can directly set the success status code in the I / O status block of the first IRP.

[0107] The preset driver module returns the processed first IRP to the Wine kernel, and the Wine kernel determines whether the target device is opened successfully according to the I / O status block in the first IRP. If the I / O status block of the first IRP contains a success status code, it indicates that the preset driver module has successfully opened the target device, and the Wine kernel returns an object handle (handle) for operating the device object (DeviceObject) to the application program for subsequent operations on the target device. If the I / O status block of the first IRP contains a failure status code, it indicates that the preset driver module has not successfully opened the target device, and the Wine kernel returns an error message to the application program.

[0108] It should be noted that the device object refers to the device object that can be recognized by the Wine kernel. The interaction between the preset driver module and the Wine kernel uses the device object.

[0109] The device handle (libusb_device_handle) refers to the device handle of the target device obtained using the libusb library. The interaction between the preset driver module and the target device uses this device handle.

[0110] The object handle refers to the handle of the device object provided by the Wine kernel to the application program for use after receiving the first IRP carrying a success status code returned by the preset driver module.

[0111] The object handle has a corresponding relationship with the device object (Device Object) in the Wine kernel. The device handle in the first device list can be located through the device identifier in the device object (Device Object), and then the specific target device can be operated.

[0112] In an optional embodiment of the present application, after step S22, the method may further include:

[0113] Step S31, receiving a second input / output request packet sent by the Wine kernel; the second input / output request packet carries a second main function code and the device object; the second main function code indicates operating the target device according to the type of the second main function code;

[0114] Step S32: query the first device list according to the device identifier in the device object to obtain the device handle corresponding to the device object;

[0115] Step S33, executing a second main function processing function, where the second main function processing function is used to use the acquired device handle to call an interface corresponding to the type of the second main function code in a USB device access library.

[0116] After the application obtains the object handle of the target device returned by the Wine kernel, it can use the object handle to initiate I / O requests to operate the target device.

[0117] Reference Figure 5 , shows a flow chart of processing I / O requests in an example of the present application. Figure 5 The flow shown is after step S22.

[0118] like Figure 5As shown in the figure, the requester can be a Windows application or other component running in Wine, and the I / O request can include one of: reading data (IRP_MJ_READ), writing data (IRP_MJ_WRITE), and application device control (IRP_MJ_DEVICE_CONTROL). In some cases, the I / O request can be issued by the Wine kernel, and there is no Figure 2 In this case, the I / O request may include one of: kernel internal device control (IRP_MJ_INTERNAL_DEVICE_CONTROL), plug and play (IRP_MJ_PNP), and device close (IRP_MJ_CLOSE).

[0119] Take the example of an application program reading data from a target device. The application program can use the acquired object handle to request to read data from the target device by calling an API function provided by the system (such as ReadFile, etc.), and this request will be passed to the Wine kernel. The Wine kernel converts the request into an IRP and sends it to the preset driver module, which is referred to as the second IRP. The main function code of the second IRP is the second main function code (i.e., IRP_MJ_READ), and the parameters include the device object (Device Object) of the target device; the second main function code is used to indicate reading data from the target device.

[0120] The preset driver module queries the first device list according to the device identifier (such as PID and VIP) in the device object to obtain the device handle corresponding to the device object; and executes the second main function processing function, namely the IRP_MJ_READ processing function, which is used to call the interface corresponding to the IRP_MJ_READ type in the libusb library, such as libusb_bulk_transfer or libusb_interrupt_transfer, and the parameters passed in include the device handle and the number of bytes read, etc.

[0121] In the embodiment of the present application, the preset driver module converts the second IRP sent by the Wine kernel into an interface for calling a corresponding function in the libusb library to operate the target device. Depending on the type of the second main function code, the corresponding interface in the libusb library called is different. The type of the second main function code may include any one of the following: read data, write data, kernel internal device control, application device control, and close device.

[0122] It should be noted that after the preset driver module completes the processing of the IRP request (such as the first IRP, the second IRP, and the third IRP) sent by the Wine kernel, it can set the processing result in the I / O status block of the processed IRP and return the processed IRP to the Wine kernel.

[0123] Furthermore, when the type of the second main function code is read data IRP_MJ_READ or write data IRP_MJ_WRITE, in order to ensure the correctness of read data and write data, the preset driver module also needs to declare the interface control right of the target device before operating the target device; and release the interface control right of the target device after operating the target device.

[0124] Reference Figure 6 , shows a flowchart of processing a read / write request in an example of the present application. A read / write request refers to an I / O request for reading data or an I / O request for writing data, which specifically includes the following steps:

[0125] Step A1: The application sends a read / write request to the USB device (target device). Specifically, the application uses the handle of the device object of the target device as a parameter, calls the API function (such as ReadFile / WriteFile) provided by the system, and triggers the read / write request for the target device.

[0126] Step A2: The Wine kernel receives the read / write request and forwards it to the preset driver module. Specifically, after receiving the read / write request triggered by the application, the Wine kernel converts it into an IRP (second IRP) and sends it to the preset driver module, and the second main function code is IRP_MJ_READ / IRP_MJ_WRITE.

[0127] Step A3: Claim the interface control right of the device to ensure exclusive use. Specifically, the device handle and interface number of the target device are used as parameters to call the libusb_claim_interface function of the libusb library to claim the interface control right. The device handle and interface number can be obtained and saved when the device is inserted. The interface number can be obtained from the configuration descriptor.

[0128] Step A4: Send a read / write request to the USB device. Specifically, the preset driver module converts the received IRP into an interface for calling a corresponding function in the libusb library, such as calling a libusb_bulk_transfer or libusb_interrupt_transfer interface.

[0129] Step A5: Receive the result returned by the USB device.

[0130] Step A6: Release the interface control right of the device. Specifically, the device handle and interface number of the target device are used as parameters to call the libusb_release_interface function of the libusb library to release the interface control right.

[0131] Step A7: Return the request result.

[0132] Step A8: The application receives the request result.

[0133] In the embodiment of the present application, the preset driver module also implements the IRP main function of two device control (IOCTL) requests: application device control (IRP MJ DEVICE CONTROL) and kernel internal device control (IRP_MJ_INTERNAL_DEVICE_CONTROL).

[0134] Among them, the IRP_MJ_DEVICE_CONTROL request is used for communication between applications and USB devices in user mode. For example, when an application needs to perform some device-specific operations, such as configuring device parameters, obtaining device status information, sending device-specific commands, etc., and these operations cannot be directly completed through standard read / write operations (such as IRP_MJ_READ or IRP_MJ_WRITE), the IRP_MJ_DEVICE_CONTROL request can be used.

[0135] Kernel internal device control, used for communication between drivers in kernel mode. For example, device control operations are performed inside a device driver. Unlike IRP_MJ_DEVICE_CONTROL, IRP_MJ_INTERNAL_DEVICE_CONTROL is usually not directly initiated by an application, but is used for inter-level communication within a driver (pre-installed driver module) or system-level device management operations.

[0136] Exemplarily, the IRP with the main function code IRP_MJ_DEVICE_CONTROL includes sub-function codes, operations corresponding to each sub-function code, and devices involved in the operation, as shown in Table 1.

[0137] Table 1

[0138]

[0139]

[0140] Exemplarily, the sub-function codes included in the IRP with the main function code IRP_MJ_INTERNAL_DEVICE_CONTROL, the operations corresponding to the sub-function codes, and the devices involved in the operations are shown in Table 2.

[0141] Table 2

[0142]

[0143] In an optional embodiment of the present application, the method may further include:

[0144] Step S41, receiving a third input / output request packet sent by the Wine kernel; the third input / output request packet carries a third main function code, a sub-function code and the device object; the sub-function code indicates a method of removing the target device (normal removal or accidental removal);

[0145] Step S42: triggering the removal processing function corresponding to the sub-function code, and removing the target device according to the removal method indicated by the sub-function code.

[0146] In a specific implementation, USB device removal may include normal removal and accidental removal.

[0147] Normal removal means uninstalling the USB device from the operating system by performing the "Safely Remove Hardware" operation, disabling the USB device, or removing the USB device when the system is shut down.

[0148] Accidental removal refers to the removal of a USB device from an interface without performing the "Safely Remove Hardware" operation, or when a hardware connection failure occurs.

[0149] Reference Figure 7 , shows a schematic diagram of a process for processing a device removal operation in an example of the present application. Figure 7 As shown, when a USB device (such as a target device) is unplugged from the system (including normal removal or accidental removal) and needs to be removed by the system, the Wine kernel will send an IRP (here referred to as the third IRP) to the preset driver module to notify the preset driver module that the target device is about to be removed, and the preset driver module needs to perform a series of cleanup and resource release operations.

[0150] The third IRP carries a third major function code, a sub-function code and the device object. The third major function code is IRP_MJ_PNP, indicating that this is a plug-and-play (PnP) device-related operation. In case of normal removal, the sub-function code is IRP_MN_REMOVE_DEVICE; in case of accidental removal, the sub-function code is IRP_MN_SURPRISE_REMOVAL. The sub-major function code can indicate the method of removing the target device (such as normal removal or accidental removal).

[0151] After receiving the third IRP, the preset driver module triggers the removal processing function corresponding to the sub-function code, and removes the target device according to the removal method indicated by the sub-function code.

[0152] In the case of normal removal, the removal processing function performs the following operations: stops all I / O operations on the target device (ongoing I / O operations need to wait for completion), releases the resources allocated to the target device, and unregisters the callback function.

[0153] In the case of an unexpected removal, the removal handler performs the following operations: immediately stops all I / O operations to the target device (without waiting for ongoing I / O operations to complete), releases resources allocated to the target device, and unregisters the callback function.

[0154] Further, after completing the processing of the IRP_MN_REMOVE_DEVICE request or the IRP_MN_SURPRISE_REMOVAL request, the preset driver module may set the processing result in the I / O status block of the third IRP, and return the processed third IRP to the Wine kernel to notify the Wine kernel of the removal processing result.

[0155] It should be noted that the IRP with the main function code IRP_MJ_PNP (the third IRP) is sent by the Wine kernel to the preset driver module when the Wine kernel detects that the device is plugged in or unplugged.

[0156] IRP_MJ_PNP is the main function code of the I / O request packet used to process plug-and-play (PnP) device-related operations. It is mainly used to manage operations related to the PnP function, such as adding and removing devices and reallocating resources. In specific implementations, the above operations related to the PnP function can be implemented by using different sub-function codes.

[0157] For example, when a PnP device (such as a target device) is detected and needs to be started, after step 105, the Wine kernel can send an IRP_MJ_PNP request with a sub-function code of IRP_MN_START_DEVICE to the preset driver module. The preset driver module responds to the request and performs an operation to start the target device. This operation is used to initialize the target device and allocate necessary resources to it so that the target device can work normally.

[0158] Exemplarily, the sub-function codes included in the IRP whose main function code is IRP_MJ_PNP, the operations corresponding to each sub-function code, and the devices involved in the operations are shown in Table 3.

[0159] Table 3

[0160] operate Sub-function code Involved equipment Start the device IRP_MN_START_DEVICE FDO and PDO Query device ID IRP_MN_QUERY_ID PDO Query device capabilities IRP_MN_QUERY_CAPABILITIES PDO Query device relationships IRP_MN_QUERY_DEVICE_RELATIONS FDO Accidental device removal IRP_MN_SURPRISE_REMOVAL FDO and PDO Remove the device normally IRP_MN_REMOVE_DEVICE FDO and PDO

[0161] Furthermore, before step 101, the method may further include:

[0162] Create a driver file and installation information file corresponding to the preset driver module, and modify the configuration file of Wine to enable the compilation of the preset driver module. After compilation, when running Wine, the preset driver module runs in the Wine environment in the form of a kernel driver.

[0163] Furthermore, the present application can be configured and compiled through the following steps, so that when running Wine, the preset driver module runs in the Wine environment as a service and a kernel driver. Specifically:

[0164] a. Create a driver program file corresponding to the preset driver module so that the preset driver module generates a file with a .sys suffix after compilation.

[0165] b. Create a .inf file for the pre-installed driver module (i.e., Windows installer information file, used to install the pre-installed driver module). In the .inf file, use the AddService keyword to create a service that matches the pre-installed driver module. Add the following content:

[0166] b1. Description of the service.

[0167] b2. Name of the service.

[0168] b3. The path of the executable program corresponding to the service, that is, the path where the preset driver module file is stored after compilation.

[0169] b4. Specify the load order group for the service, such as setting it to WinePlugPlay.

[0170] b5. The type of service, such as specifying it as a kernel driver.

[0171] b6. Service startup type, such as setting it to automatic startup.

[0172] b7. Specify the error control behavior when the service fails to start, such as setting it to display an error message and continue starting.

[0173] c. Modify the Wine configuration file (wine.inf.in). Add the .inf file of the preset driver module and the driver information in the InfFiles section.

[0174] d. Modify the Wine configuration file (configure) to enable compilation of the preset driver module.

[0175] Among them, the driver file (.sys file) contains the actual code of the preset driver module, which is used to implement various operations and functions of the device. In this file, there are main function functions that handle device I / O requests (such as IRP_MJ_CREATE, IRP_MJ_READ, IRP_MJ_WRITE, etc.), which define how to respond to operations such as opening, reading, and writing to the device. The driver file also contains device initialization code. For example, in the DriverEntry function (the entry point of the driver), device objects are created, resources are allocated (such as memory buffer allocation, interrupt resource application, etc.), and other operations are performed.

[0176] The installation information file (.inf file) is a text-formatted file that is mainly used to provide the system with device identification information and driver installation configuration information. The .inf file also provides detailed steps and configuration information for driver installation. It specifies the location of the driver file (.sys file) and other related files that need to be copied to the system directory during the installation process. At the same time, it tells the system how to register the driver service, including information such as the service name, display name, dependencies, etc. When installing the driver, the system will follow the instructions in the .inf file, place the driver file in the correct location, and perform necessary registration and configuration.

[0177] After the compilation is completed, during the initialization process of Wine startup, the Wine kernel loads the preset driver module through the driver entry of the preset driver module, initializes the preset driver module according to the system driver object format, and registers the necessary entry point functions (such as AddDrvice and Unload) and the necessary IRP main function functions (such as device creation, reading data, writing data, IOCTL, PnP, and device shutdown, etc.) of the driver module. After the preset driver module is loaded successfully, the callback function of the libusb library can be registered to monitor the plugging and unplugging of USB devices. The preset driver module of the present application can be notified and perform corresponding operations when a specific USB event occurs by registering the callback function of the libusb library. For example, when a USB device is plugged in or out of the system, or when an event occurs during data transmission, these situations can be handled in a timely manner through the callback function without the need to constantly poll the device status. When a device is plugged in, step 101 is executed.

[0178] In an optional embodiment of the present application, the method may further include:

[0179] In response to the Wine kernel's call request to the driver uninstallation interface, a driver uninstallation operation is performed.

[0180] like Figure 4 As shown, the preset driver module of the present application provides a driver unloading interface (such as Unload) for unloading the preset driver module. When the Wine kernel is restarted or shut down and the kernel main loop program exits, the driver unloading interface Unload of the preset driver module is called to trigger the preset driver module to execute the Unload function and perform the unloading operation. The Unload function is specifically used to clear and release the first device list.

[0181] The driver uninstallation operation is used to release the resources occupied by the preset driver module when the user actively uninstalls the preset driver module or the system is shut down.

[0182] In summary, the present application adds a preset driver module in Wine, and the preset driver module runs in Wine as a kernel driver. When a new target device is inserted into the Linux system, if the target device is found to be a preset device in the preset conversion list (such as a HID device that lacks a corresponding driver in the Linux system), the device handle and device information of the target device are saved in the first device list, and its device type is modified from a general USB device type to a target device type (such as a HID device type), so that the target device can be operated according to the correct device type. Further, the preset driver module implements a device addition interface and a main function processing function of the preset device. By calling the device addition interface, a functional device object corresponding to the target device can be created, and the functional device object of the target device is bound to the physical device object of the target device, so that when the main function processing function is subsequently called, it can ensure that the I / O request can be correctly executed on the physical device. Through the embodiment of the present application, the preset driver module can be used to correctly drive the HID device, so that the HID device that lacks a driver in the Linux system can be driven by the preset driver module, and then the Windows application running in Wine can use the HID device normally.

[0183] It should be noted that, for the method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of the present application are not limited by the described order of actions, because according to the embodiments of the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present application.

[0184] Reference Figure 8 , shows a structural block diagram of an embodiment of a preset driver module of the present application, which is applied to Wine, a compatibility layer of a Linux system, wherein the preset driver module is run as a kernel driver in Wine, wherein the preset driver module implements a device adding interface and a main function processing function of a preset device, and the preset driver module includes:

[0185] The insertion monitoring module 201 is used to obtain the device identification of the target device and query the preset conversion list when monitoring that a new target device is inserted into the Linux system, wherein the preset conversion list includes the device identification of the preset device;

[0186] The device adding module 202 is used for saving the device handle and device information of the target device in the first device list if the device identification of the target device is found in the preset conversion list; the device information includes the device identification and device type of the target device, and the device type is changed from the general USB device type to the target device type;

[0187] A first creation module 203 is used to create a device object corresponding to the target device, the device object includes a device identifier of the target device, and send a notification message to the Wine kernel, the notification message carries the device object;

[0188] The second creation module 204 is used to receive a call request from the Wine kernel to add an interface to the device, the call request carrying the device object; based on the device identifier in the device object, create a functional device object corresponding to the target device, and bind the functional device object of the target device to the physical device object of the target device.

[0189] Optionally, the preset driving module further includes:

[0190] A list acquisition module, used for acquiring a second device list by calling a first function of a USB device access library, wherein the second device list includes device information of all USB devices connected to the Linux system;

[0191] A target determination module, used for comparing the second device list with the preset conversion list, and determining a target device which matches the second device list and has a device type of a general USB device type;

[0192] The handle acquisition module is used to open the target device by calling the second function of the USB device access library and acquire the device handle of the target device.

[0193] Optionally, the preset driving module further includes:

[0194] A first request receiving module, configured to receive a first input / output request packet sent by the Wine kernel; the first input / output request packet carries a first main function code and the device object; the first main function code indicates to open the target device;

[0195] The first request processing module is used to execute a first main function processing function, wherein the first main function processing function is used to set a success status code in the first input / output request packet and return the processed first input / output request packet to the Wine kernel, so that the Wine kernel returns an object handle for operating the device object to the application.

[0196] Optionally, the preset driving module further includes:

[0197] A second request receiving module is used to receive a second input / output request packet sent by the Wine kernel; the second input / output request packet carries a second main function code and the device object; the second main function code indicates to operate the target device according to the type of the second main function code;

[0198] The second request processing module is used to query the first device list according to the device identifier in the device object, obtain the device handle corresponding to the device object; and execute a second main function processing function, wherein the second main function processing function is used to use the obtained device handle to call the interface corresponding to the type of the second main function code in the USB device access library.

[0199] Optionally, the type of the second main function code includes one of the following: reading data, writing data, kernel internal device control, application device control, plug and play, and shutting down a device.

[0200] Optionally, the preset driving module further includes:

[0201] The registration information sending module is used to send the registration related information of the target device to the Wine kernel, so that the Wine kernel registers the target device in a registration table based on the registration related information.

[0202] Optionally, the preset driver module provides a driver entry function so that the Wine kernel loads the preset driver module by calling the driver entry function after Wine is started. The driver entry function is used to initialize the preset driver module, register the main function processing function provided by the preset driver module, and set the device type supported by the preset driver module.

[0203] The preset driver module provided by the present application runs in Wine as a kernel driver. When a new target device is inserted into the Linux system, if the target device is found to be a preset device in the preset conversion list (such as a HID device that lacks a corresponding driver in the Linux system), the device handle and device information of the target device are saved in the first device list, and its device type is modified from a general USB device type to a target device type (such as a HID device type), so that the target device can be operated according to the correct device type. Further, the preset driver module implements a device adding interface and a main function processing function of the preset device. By calling the device adding interface, a functional device object corresponding to the target device can be created, and the functional device object of the target device can be bound to the physical device object of the target device, so that when the main function processing function is subsequently called, it can be ensured that the I / O request can be correctly executed on the physical device. Through the embodiment of the present application, the preset driver module can be used to correctly drive the HID device, so that the HID device that lacks a driver in the Linux system can be driven by the preset driver module, and then the Windows application running in Wine can use the HID device normally.

[0204] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0205] Reference Fig. 9 , is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Fig. 9 As shown, the electronic device includes: a processor, a memory, a communication interface and a communication bus, and the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, and the executable instruction enables the processor to execute the steps of the device driving method of the aforementioned embodiment.

[0206] An embodiment of the present application provides a non-transitory computer-readable storage medium. When the instructions in the storage medium are executed by a program or processor of a terminal, the terminal is enabled to execute the steps of the device driving method of the aforementioned embodiment.

[0207] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0208] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, pre-set driver modules, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0209] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0210] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing terminal device to operate in a predictable manner, so that the instructions stored in the computer readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0211] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0212] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements.

[0213] Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for those skilled in the art, according to the idea of ​​the present application, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A device driving method, characterized in that: A compatibility layer Wine applied to a Linux system, wherein a pre-installed driver module is run by a kernel driver in the Wine, wherein a device adding interface and a main function processing function of a pre-installed device are implemented in the pre-installed driver module, and the method comprises: In the case of monitoring that a target device is newly inserted into the Linux system, obtaining a device identification of the target device, and querying a preset conversion list, wherein the preset conversion list includes the device identification of the preset device; If the preset conversion list contains the device identification of the target device, the device handle and device information of the target device are saved in the first device list; the device information includes the device identification and device type of the target device, and the device type is changed from the general USB device type to the target device type; Create a device object corresponding to the target device, the device object includes the device identifier of the target device, and send a notification message to the Wine kernel, the notification message carries the device object; receiving a call request from the Wine kernel to add an interface to the device, wherein the call request carries the device object; Based on the device identification in the device object, a functional device object corresponding to the target device is created, and the functional device object of the target device is bound to the physical device object of the target device.

2. The method according to claim 1, characterized in that After monitoring that a new target device is inserted into the Linux system, the method further includes: Acquire a second device list by calling a first function of a USB device access library, wherein the second device list includes device information of all USB devices connected to the Linux system; Compare the second device list with the preset conversion list to determine a target device that matches the second device list and whose device type is a general USB device type; The target device is opened by calling the second function of the USB device access library, and the device handle of the target device is obtained.

3. The method according to claim 1, characterized in that: The method further comprises: receiving a first input / output request packet sent by the Wine kernel; the first input / output request packet carries a first main function code and the device object; the first main function code indicates to open the target device; Execute a first main function processing function, wherein the first main function processing function is used to set a success status code in the first input / output request packet, and return the processed first input / output request packet to the Wine kernel, so that the Wine kernel returns an object handle for operating the device object to the application.

4. The method according to claim 3, characterized in that The method further comprises: receiving a second input / output request packet sent by the Wine kernel; the second input / output request packet carries a second main function code and the device object; the second main function code indicates operating the target device according to the type of the second main function code; Query the first device list according to the device identifier in the device object to obtain the device handle corresponding to the device object; Execute a second main function processing function, where the second main function processing function is used to use the acquired device handle to call an interface corresponding to the type of the second main function code in the USB device access library.

5. The method according to claim 4, characterized in that The type of the second main function code includes one of the following: read data, write data, kernel internal device control, application device control, and close device.

6. The method according to claim 1, characterized in that The method further comprises: Sending registration related information of the target device to the Wine kernel, so that the Wine kernel registers the target device in a registration table based on the registration related information.

7. The method according to claim 1, characterized in that The preset driver module provides a driver entry function so that the Wine kernel loads the preset driver module by calling the driver entry function after Wine is started. The driver entry function is used to initialize the preset driver module, register the main function processing function provided by the preset driver module, and set the device type supported by the preset driver module.

8. A pre-installed driving module, characterized in that: A compatibility layer Wine applied to a Linux system, wherein a pre-installed driver module is run as a kernel driver in Wine, wherein a device adding interface and a main function processing function of a pre-installed device are implemented in the pre-installed driver module, and the pre-installed driver module includes: An insertion monitoring module is used to obtain a device identification of the target device and query a preset conversion list when monitoring that a target device is newly inserted into the Linux system, wherein the preset conversion list includes the device identification of the preset device; A device adding module, for saving the device handle and device information of the target device in the first device list if the device identification of the target device is found in the preset conversion list; the device information includes the device identification and device type of the target device, and the device type is changed from the general USB device type to the target device type; A first creation module is used to create a device object corresponding to the target device, the device object includes a device identifier of the target device, and send a notification message to the Wine kernel, the notification message carries the device object; The second creation module is used to receive a call request from the Wine kernel to add an interface to the device, the call request carrying the device object; based on the device identifier in the device object, create a functional device object corresponding to the target device, and bind the functional device object of the target device to the physical device object of the target device.

9. An electronic device, characterized in that: include: A processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other via the communication bus; The memory is used to store at least one executable instruction, and the executable instruction enables the processor to execute the steps of the device driving method according to any one of claims 1 to 7.

10. A readable storage medium, characterized in that: The readable storage medium stores a program or instruction, and when the program or instruction is executed by a processor, the steps of the device driving method according to any one of claims 1 to 7 are implemented.

Images