Acquisition method and device of drive program, equipment and medium

Abstract

The invention discloses a driver obtaining method and device, equipment and a medium, and belongs to the technical field of computers. The method comprises the steps that a first driving code of hardware equipment is obtained, the first driving code is used for generating a first driving program, and the first driving program is used for driving the hardware equipment to interact with an application program installed in a first operating system; extracting a target function code used for realizing the function of the hardware equipment from the first drive code; obtaining a target interface code used for providing an interface related to the second operating system; determining a second driving code based on the target interface code and the target function code; and compiling the second driving code to obtain a second driving program which is used for driving the hardware equipment to interact with an application program installed in the second operating system. According to the method, the drive code can be quickly obtained, so that the obtaining efficiency of the drive program is improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technology, and in particular to a method, apparatus, device, and medium for obtaining a driver. Background Art

[0002] With the advancement of computer technology, hardware devices such as chips are widely used in a variety of electronic devices, including mobile phones, computers, smart watches, and smart appliances. Typically, each electronic device corresponds to an operating system, and the operating system's driver is required to drive the hardware device to run on the electronic device. However, different electronic devices may correspond to different operating systems, necessitating the acquisition of drivers for different operating systems. Therefore, how to quickly obtain drivers for multiple operating systems has become a pressing issue. Summary of the Invention

[0003] The present application provides a method, apparatus, device and medium for obtaining a driver, which can be used to quickly obtain driver code and improve the efficiency of obtaining the driver. The technical solution includes the following contents.

[0004] In one aspect, a method for obtaining a driver is provided, the method comprising:

[0005] Obtaining a first driver code for a hardware device, where the first driver code is used to generate a first driver program, and the first driver program is used to drive the hardware device to interact with an application program installed in a first operating system;

[0006] Extracting a target function code for implementing a function of the hardware device from the first driver code;

[0007] Acquire a target interface code for providing an interface related to the second operating system;

[0008] Determining a second driving code based on the target interface code and the target function code;

[0009] The second driver code is compiled to obtain a second driver program, where the second driver program is used to drive the hardware device to interact with an application program installed in the second operating system.

[0010] In another aspect, a device for obtaining a driver is provided, the device comprising:

[0011] an acquisition module, configured to acquire a first driver code of a hardware device, wherein the first driver code is used to generate a first driver program, and the first driver program is used to drive the hardware device to interact with an application program installed in a first operating system;

[0012] an extraction module, configured to extract a target function code for implementing a function of the hardware device from the first driver code;

[0013] The acquisition module is further configured to acquire a target interface code for providing an interface related to the second operating system;

[0014] A determination module, configured to determine a second driving code based on the target interface code and the target function code;

[0015] A compiling module is used to compile the second driver code to obtain a second driver program, where the second driver program is used to drive the hardware device to interact with an application program installed in the second operating system.

[0016] In a possible implementation, the target function code includes at least one of a user-mode function code or a kernel-mode function code;

[0017] The user-state function code is used to implement the function of the hardware device in the user state; the kernel-state function code is used to implement the function of the hardware device in the kernel state.

[0018] In a possible implementation, the target interface code includes at least one of a user-mode interface code or a kernel-mode interface code;

[0019] The user-mode interface code is used to provide a user-mode interface for interacting with the second operating system; and the kernel-mode interface code is used to provide a kernel-mode interface for interacting with the second operating system.

[0020] In a possible implementation, the target interface code includes a user-mode interface code;

[0021] The acquisition module is used to extract a first interface code from the first driver code, where the first interface code includes a first structure that conforms to the first operating system, and the first structure is used to define the user-mode interface; the first structure is redefined by a second structure that conforms to the second operating system to obtain the user-mode interface code.

[0022] In a possible implementation, the target interface code includes a kernel-mode interface code;

[0023] The acquisition module is used to extract the second interface code from the first driver code, where the second interface code includes a third structure that complies with the first operating system, and the third structure is used to define the kernel-state interface; the kernel-state interface code is obtained by redefining the third structure through a fourth structure that complies with the second operating system.

[0024] In one possible implementation, the determination module is used to obtain a framework code, which is used to define a function called when operating the second driver or at least one of the hardware devices; and determine the second driver code based on the framework code, the target interface code and the target function code.

[0025] In a possible implementation, the second driver code includes a user-mode interface code and a user-mode function code, and the second driver includes a user-mode driver;

[0026] The compilation module is used to compile the user-state interface code to obtain a user-state interface library, and the user-state interface library is used to provide a user-state interface for interacting with the second operating system; based on the user-state interface library, the user-state function code is compiled to obtain the user-state driver, and the user-state driver is used to interact with the application installed in the second operating system through the user-state interface to realize the function of the hardware device in user state.

[0027] In a possible implementation, the second driver code includes a kernel-state interface code and a kernel-state function code, and the second driver program includes a kernel-state driver program;

[0028] The compilation module is used to compile the kernel-state function code based on the kernel-state interface code to obtain the kernel-state driver. The kernel-state driver is used to communicate with the hardware device through the kernel-state interface provided by the kernel-state interface code to realize the function of the hardware device in the kernel state.

[0029] On the other hand, an electronic device is provided, comprising a processor and a memory, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor so that the electronic device implements any of the above-mentioned methods for obtaining a driver.

[0030] On the other hand, a computer-readable storage medium is provided, in which at least one computer program is stored. The at least one computer program is loaded and executed by a processor to enable an electronic device to implement any of the above-mentioned methods for obtaining a driver.

[0031] On the other hand, a computer program is further provided. The computer program is at least one, and the at least one computer program is loaded and executed by a processor to enable an electronic device to implement any of the above-mentioned methods for obtaining a driver.

[0032] On the other hand, a computer program product is further provided. The computer program product stores at least one computer program. The at least one computer program is loaded and executed by a processor to enable an electronic device to implement any of the above-mentioned methods for obtaining a driver.

[0033] The technical solution provided by this application brings at least the following beneficial effects:

[0034] The technical solution provided by this application extracts the target function code from the first driver code based on the first driver code that has been obtained and is adapted to the first operating system, thereby reusing the target function code, thereby quickly determining the second driver code adapted to the second operating system through the target function code and the target interface code adapted to the second operating system. Since the target function code accounts for a large proportion and the target interface code accounts for a small proportion, by reusing the target function code, the acquisition time of the second driver code can be greatly reduced, thereby quickly acquiring the driver adapted to the second operating system based on the second driver code, and improving the efficiency of driver acquisition. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0036] Figure 1 This is a schematic diagram of an implementation environment of a method for obtaining a driver program provided in an embodiment of the present application;

[0037] Figure 2 This is a flowchart of a method for obtaining a driver provided in an embodiment of the present application;

[0038] Figure 3 This is a schematic diagram of compiling a user-mode driver provided in an embodiment of the present application;

[0039] Figure 4 This is a schematic diagram of compiling a kernel-mode driver provided in an embodiment of the present application;

[0040] Figure 5 This is a schematic diagram of a software stack provided by an embodiment of the present application;

[0041] Figure 6 This is a schematic diagram of the structure of a device for obtaining a driver program provided in an embodiment of the present application;

[0042] Figure 7 This is a schematic diagram of the structure of a terminal device provided in an embodiment of the present application;

[0043] Figure 8 This is a structural diagram of a server provided in an embodiment of the present application. DETAILED DESCRIPTION

[0044] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0045] With the advancement of computer technology, an increasing number of hardware devices are being used in electronic devices such as mobile phones, computers, smart watches, and smart appliances. Typically, these electronic devices are equipped with an operating system, and drivers adapted to that operating system are required to operate the hardware devices on these devices. However, different electronic devices may operate with different operating systems, necessitating the acquisition of drivers adapted to each operating system. However, how to quickly obtain drivers for multiple operating systems has become a pressing issue.

[0046] An embodiment of the present application provides a method for obtaining a driver program. Based on the first driver code adapted to the first operating system that has been obtained, the target function code in the first driver code is reused to quickly obtain the second driver code based on the target function code, thereby quickly obtaining the driver program adapted to the second operating system based on the second driver code, thereby improving the efficiency of driver program acquisition.

[0047] Figure 1 This is a schematic diagram of an implementation environment of a method for obtaining a driver provided in an embodiment of the present application, such as Figure 1 As shown, the implementation environment includes a terminal device 101 and a server 102. The driver acquisition method in the embodiment of the present application can be executed by the terminal device 101, or by the server 102, or by both the terminal device 101 and the server 102.

[0048] The terminal device 101 can be a smart phone, a game console, a desktop computer, a tablet computer, a laptop computer, a smart TV, a smart car device, an intelligent voice interaction device, a smart home appliance, etc. The server 102 can be a single server, or a server cluster consisting of multiple servers, or any one of a cloud computing platform and a virtualization center, which is not limited in the embodiments of the present application. The server 102 can be connected to the terminal device 101 via a communication network, which is a wired network or a wireless network. The server 102 can have functions such as data processing, data storage, and data transmission and reception, which are not limited in the embodiments of the present application. The number of terminal devices 101 and servers 102 is not limited and can be one or more.

[0049] In an exemplary embodiment, the terminal device 101 or the server 102 may obtain a first driver code. The terminal device 101 or the server 102 then extracts a target function code from the first driver code, obtains a target interface code, and determines a second driver code adapted for the second operating system based on the target interface code and the target function code.

[0050] In another exemplary embodiment, terminal device 101 sends a request to server 102 for obtaining first driver code adapted for a first operating system. Server 102 responds to the request and sends the first driver code to terminal device 101. After obtaining the first driver code, terminal device 101 extracts a target function code from the first driver code, obtains a target interface code, and determines a second driver code adapted for a second operating system based on the target interface code and the target function code.

[0051] Next, the second driver code may be compiled to obtain a second driver program. The second driver program is adapted to a second operating system, and an application program is installed on the second operating system. The second driver program drives the hardware device to interact with the application program.

[0052] like Figure 2 As shown, Figure 2 This is a flowchart of a method for obtaining a driver provided by an embodiment of the present application, which can be applied to the above implementation environment. For ease of description, the terminal device 101 or server 102 that executes the method for obtaining a driver in the embodiment of the present application is referred to as an electronic device, and the method can be executed by an electronic device. Figure 2 As shown, the method includes the following steps.

[0053] Step 201: Acquire a first driver code of a hardware device, where the first driver code is used to generate a first driver program, and the first driver program is used to drive the hardware device to interact with an application program installed in a first operating system.

[0054] In an embodiment of the present application, the electronic device can obtain the first drive code, and the method for obtaining the first drive code is not limited herein. Exemplarily, the electronic device reads the first drive code from a storage device (such as a flash drive, a mobile hard disk, etc.). Alternatively, the code library includes the first drive code, and the electronic device sends an acquisition request for the first drive code to a server for managing the code library. The server responds to the acquisition request, reads the first drive code from the code library and sends the first drive code to the electronic device, and so on.

[0055] The first driver code is a code adapted to the first operating system. The embodiment of the present application does not limit the first operating system. Exemplarily, the first operating system is at least one of the Linux operating system (an operating system for a computer), the Windows operating system (an operating system for another computer), the Android operating system (an operating system for a mobile terminal), etc.

[0056] The first driver code is a code for controlling and managing a hardware device, which enables the hardware device to interact with the first operating system. The embodiment of the present application does not limit the hardware device. For example, the hardware device includes at least one of a chip, a network card, a sound card, a graphics card, a mouse, etc., and the chip includes at least one of a system-level chip, a codec chip, a processor chip, etc. Among them, the system-level chip is a chip that integrates a system and embedded software. A codec chip is an integrated circuit chip that is used to encode or decode an input signal. Encoding is the process of converting an input signal in its original form into an output signal in its encoded form, and decoding is the process of converting an input signal in its encoded form into an output signal in its original form. Codec chips can be widely used in communications, embedded systems, audio, video and other fields.

[0057] In one implementation, the first driver code can be compiled to obtain a first driver program. Since the generation method of the first driver program is similar to the generation method of the second driver program, please refer to the description of step 205 and will not be repeated here. The first driver program is a special program added to the first operating system, which contains device information of the driven hardware device, and enables the first operating system to communicate with the hardware device through the device information. In an embodiment of the present application, the first driver program is a software program that drives the hardware device, which is used to drive the hardware device of the electronic device to interact with the first operating system of the electronic device and the application installed on the first operating system.

[0058] It is understood that applications that interact with hardware devices can utilize the functions of the hardware devices. For example, if the hardware device is a codec chip that has the function of encoding and decoding audio and video, based on this, the application can include at least one of a music application, a film and television application, a reading application, etc.

[0059] In an embodiment of the present application, a first driver provides an interface adapted to a first operating system. Through this interface, an application program can perform data input, data output, and control operations with a hardware device, thereby enabling interaction between the application program and the hardware device. For example, the hardware device is a codec chip, and the application program is video software. Through the interface provided by the first driver, the codec chip can encode or decode input signals from the video software to generate output signals, which are then accessible to the application program.

[0060] Step 202: extracting a target function code for implementing a function of the hardware device from the first driver code.

[0061] In the embodiment of the present application, after obtaining first driver code adapted for a first operating system, it is desired to quickly obtain second driver code adapted for a second operating system based on the first driver code. It is understandable that the first operating system and the second operating system are different operating systems, and the driver codes adapted for different operating systems also differ.

[0062] Typically, driver code consists of driver framework code and functional mechanism code. The driver framework is the underlying structure of the driver code, providing tools, libraries, specifications, and design patterns to help developers develop driver code more efficiently. Optionally, the driver framework includes a series of abstract components and their interaction methods, which implement specific functions and adhere to a set of interface standards. The driver framework code can provide a unified data interface to facilitate subsequent registration by calling this data interface, thereby enabling driver code development. The functional mechanism refers to the working methods and the inherent laws and operating rules of the interactions between all elements in a system structure to achieve a specific purpose or function. For example, the functional mechanism of a mutex lock includes a series of operating rules such as initializing the mutex lock, locking, and unlocking the mutex lock. The functional mechanism code is the code portion used to implement the functional mechanism.

[0063] It's understandable that the driver framework code is a collection of code classes, methods (functions), variables, and constants. The driver framework code is structural and has little relevance to the hardware device's functionality. Functional mechanism code is the logic code related to the hardware device's functionality. For example, functional code involves logical operations such as adding, deleting, modifying, and querying modules.

[0064] The following takes the Linux operating system as the first operating system and the Windows operating system as the second operating system as an example to illustrate the differences between the two operating systems in the driver framework code and the functional mechanism code.

[0065] As shown in Table 1 below, Table 1 shows the differences in driver framework code between a Linux operating system and a Windows operating system provided in an embodiment of the present application. It is understood that Table 1 only shows a portion of the differences in driver framework code between the two operating systems. In actual application, the differences in driver framework code between the two operating systems include but are not limited to the differences shown in Table 1.

[0066] Table 1

[0067]

[0068] Table 1 shows differences in the driver framework code between Linux and Windows operating systems. A macro is a term for batch processing. Macros replace certain text patterns according to a set of predefined rules. For example, macros can convert small commands or actions into a series of instructions. A routine is similar to a function, but with a more comprehensive meaning. It is a collection of functional interfaces provided by the system.

[0069] Taking driver loading as an example, the Linux operating system provides the module_init macro, which is used to define the initialization function to be executed when the driver is loaded; while the Windows operating system provides the DriverEntry routine, which is the first driver-provided routine called after the driver is loaded. The DriverEntry routine is responsible for initializing the driver.

[0070] Taking the purpose of driver uninstallation as an example, the Linux operating system provides the module_exit macro, which is used to define the cleanup function to be executed when the driver is uninstalled; while the Windows operating system provides the EvtDriverUnload routine, which is called when the driver is uninstalled.

[0071] Next, take the high-speed serial computer expansion bus standard Peripheral Component Interconnect Express (PCIE) as an example. When writing a driver for a PCIE device, it is necessary to register the pci_driver macro with the system to specify operations such as initialization or deletion of the PCIE device. However, Windows only provides the WDFDRIVER routine, which is used to implement operations such as device initialization or deletion.

[0072] As shown in Table 2 below, Table 2 shows the differences in functional mechanism codes between a Linux operating system and a Windows operating system provided in an embodiment of the present application. It should be understood that Table 2 only illustrates a portion of the differences in functional mechanism codes between the two operating systems. In actual applications, the functional mechanism codes between the two operating systems include, but are not limited to, the differences shown in Table 2.

[0073] Table 2

[0074]

[0075]

[0076] As shown in Table 2, there are also some differences in the functional mechanism codes between the Linux and Windows operating systems. A structure is an important data type, consisting of a set of members (sometimes also called fields or elements) containing different data types, each of which can have a different type. In other words, a structure can be used to represent multiple related data types of different types.

[0077] For example, the Linux operating system implements the softirq mechanism through the tasklet structure, a lightweight interrupt handling mechanism used to execute delayed, non-blocking work within the context of a softirq. The Windows operating system, on the other hand, provides the Deferred Procedure Call (DPC) mechanism, which is used to execute high-priority tasks outside of the interrupt context.

[0078] Taking synchronization as an example, the Linux operating system implements synchronization through mutex_t, semaphore_t, spinlock_t, atomic_t, and wait_queue_head_t, while the Windows operating system implements synchronization through KMUTEX, KSEMAPHORE, KSPIN_LOCK, Volatile LONG, and KEVENT.

[0079] In general, the driver framework codes of Windows operating system and Linux operating system are quite different, so that the driver framework code adapted to Windows operating system cannot be compatible with the driver framework code adapted to Linux operating system. Similarly, the driver framework code adapted to Linux operating system cannot be compatible with the driver framework code adapted to Windows operating system. In other words, the difference of the driver framework codes between different operating systems is relatively large, the compatible workload is relatively large, and the compatibility difficulty is relatively high. Generally speaking, the driver framework code in the driver code accounts for a relatively low proportion of the entire driver code.

[0080] The differences in the functional mechanism codes of the Windows operating system and the Linux operating system are relatively small, making the functional mechanism codes adapted for the Windows operating system compatible with the functional mechanism codes adapted for the Linux operating system. Similarly, the functional mechanism codes adapted for the Linux operating system can be compatible with the functional mechanism codes adapted for the Windows operating system. In other words, the differences in the functional mechanism codes between different operating systems are relatively small, the compatibility workload is low, and the compatibility difficulty is relatively low. Generally speaking, the functional mechanism codes in the driver code account for a large proportion of the entire driver code.

[0081] In the embodiment of the present application, the first driver code includes a driver framework code and a functional mechanism code. The driver framework code in the first driver code is adapted to the first operating system and is difficult to be compatible with the driver framework code adapted to the second operating system, while the functional mechanism code in the first driver code is compatible with the functional mechanism code adapted to the second operating system.

[0082] It is understandable that the functional mechanism code includes an interface code and a function code. Different operating systems have different interfaces, and therefore, different operating systems have different interface codes. Different operating systems can implement the functions of hardware devices according to similar logic, and therefore, the function codes of different operating systems are compatible. Based on this, the target function code is a function code extracted from the first driver code and is used to implement the function of the hardware device. For example, the hardware device is a codec chip, and the codec chip has at least one of encoding or decoding functions. Therefore, the target function code is used to implement at least one of encoding or decoding functions.

[0083] The embodiment of the present application does not limit the method of extracting the target function code from the first driver code. For example, the first driver code includes multiple files, the target function code is located in several files, the file names of these texts include the same keywords, and the target function code is extracted from the multiple files included in the first driver code by keyword matching, thereby obtaining the target function code. Alternatively, the first driver code includes multiple lines of code, the start position of the target function code has a first annotation information, and the end position of the target function code has a second annotation information. The target function code is obtained by obtaining the code between the first annotation information and the second annotation information.

[0084] In an exemplary embodiment, the target function code includes at least one of a user-mode function code or a kernel-mode function code. In an embodiment of the present application, the user-mode function code is used to implement the function of the hardware device in user mode. User mode is an access state. Generally, if a program runs in user mode, the program can only access memory with limited access, is not allowed to access peripheral devices, and the program's ability to occupy the central processing unit (CPU) is deprived, and CPU resources can be obtained by other programs.

[0085] User-mode function code is used to generate user-mode drivers. User-mode drivers run in user mode and implement hardware device functions. For example, a user-mode driver can retrieve application data, perform business operations on the retrieved data to obtain operation results, or send the operation results to the application or kernel-mode driver, etc.

[0086] The electronic device can extract the user-state function code from the first driver code, and the extraction method is not limited here. For example, the electronic device can determine the code selected by the selection operation as the user-state function code based on the selection operation of the operation object on the first driver code. Alternatively, the first driver code includes a folder where the user-state function code is located, and the electronic device extracts the folder to obtain the user-state function code. Alternatively, the electronic device can obtain a configuration file, and the configuration text configures the position of the user-state function code in the first driver code, for example, the xth line to the yth line are the user-state function code, and the electronic device extracts the user-state function code from the first driver code based on the position in the configuration file.

[0087] In the embodiments of the present application, kernel-state function codes are used to implement the functions of hardware devices in kernel state. Kernel state is an access state. Generally, if a program runs in kernel state, the program has unrestricted access to memory and is allowed to access peripheral devices. For example, the program is allowed to access peripheral devices such as the hard disk and network card, and the program can occupy the CPU.

[0088] Kernel-mode function code is used to generate kernel-mode drivers. Kernel-mode drivers are the core component of the driver program, running in the operating system's kernel space and implementing hardware device functionality. For example, kernel-mode drivers perform business operations on the results of user-mode drivers to obtain hardware device data. Kernel-mode drivers are responsible for directly interacting with hardware devices, handling low-level operations such as interrupts and direct memory access (DMA), and providing user-mode drivers with access interfaces to hardware devices.

[0089] The electronic device can extract the kernel-state function code from the first driver code, and the extraction method is not limited here. For example, the electronic device can determine the code selected by the selection operation as the kernel-state function code based on the selection operation of the operation object on the first driver code. Alternatively, the first driver code includes a folder where the kernel-state function code is located, and the electronic device extracts the folder to obtain the kernel-state function code. Alternatively, the electronic device can obtain a configuration file, and the configuration text configures the position of the kernel-state function code in the first driver code, for example, the mth line to the nth line are the kernel-state function code, and the electronic device extracts the kernel-state function code from the first driver code based on the position in the configuration file.

[0090] Step 203: Acquire a target interface code for providing an interface related to the second operating system.

[0091] As mentioned above, different operating systems have different interfaces, and therefore, different operating systems have different interface codes. In other words, the interface code adapted for one operating system may not be applicable to a second operating system. Based on this, the electronic device needs to obtain the target interface code and use it to provide the interface related to the second operating system.

[0092] In an exemplary embodiment, the target interface code includes at least one of a user-mode interface code or a kernel-mode interface code. In an embodiment of the present application, the electronic device can obtain the user-mode interface code. The user-mode interface code is used to provide a user-mode interface for interacting with the second operating system. The user-mode interface is an interface used in user mode. The embodiment of the present application does not limit the manner in which the electronic device obtains the user-mode interface code.

[0093] For example, a developer of the driver code may write a user-mode interface code in the electronic device, and the electronic device acquires the user-mode interface code in response to the writing operation.

[0094] In another exemplary embodiment, the target interface code includes user-mode interface code. Obtaining the target interface code for providing an interface associated with the second operating system includes: extracting first interface code from the first driver code, the first interface code including a first structure that conforms to the first operating system and is used to define the user-mode interface; and redefining the first structure using a second structure that conforms to the second operating system to obtain the user-mode interface code.

[0095] The embodiment of the present application does not limit the method for extracting the first interface code from the first driver code. For example, the electronic device can determine the code selected by the selection operation as the first interface code based on the selection operation of the operation object on the first driver code. Alternatively, the first driver code includes the file where the first interface code is located, and the electronic device extracts the file to obtain the first interface code. Alternatively, the electronic device can obtain a configuration file, and the configuration text configures the position of the first interface code in the first driver code. The electronic device extracts the first interface code from the first driver code based on the position.

[0096] The first interface code includes at least one first structure, any of which complies with the first operating system. Figure 2 As shown, if the first operating system is a Linux operating system, the first structure may be a sem_t structure, a tasklet_struct structure, etc.; if the first operating system is a Windows operating system, the first structure may be a HANDLE structure, a KDPC structure, etc.

[0097] The first structure is used to define at least one user-mode interface, and each user-mode interface has a corresponding function. In other words, the user-mode interface is used to implement the corresponding function, and its implementation principle can be achieved by calling related functions. It is understandable that different first structures will also have different user-mode interfaces and corresponding functions.

[0098] For example, the first operating system is a Linux operating system, and the first structure is a sem_t structure. The sem_t structure is a semaphore-related structure used to define user-mode interfaces such as sem_init (semaphore initialization), sem_destroy (semaphore destruction), sem_wait (semaphore acquisition), sem_post (semaphore release), and sem_getvalue (semaphore count acquisition).

[0099] The sem_init user-mode interface mainly calls the CreateSemaphore function to create a semaphore and initialize the semaphore count. The sem_destroy user-mode interface mainly calls the CloseHandle function to destroy the semaphore and clear the semaphore count. The sem_wait user-mode interface mainly calls the WaitForSingleObject function to obtain a semaphore. Each time a semaphore is obtained, it is equivalent to a successful semaphore wait, at which point the semaphore count is reduced by 1. The sem_post user-mode interface mainly calls the ReleaseSemaphore function to release the semaphore and increase the semaphore count by 1. The sem_getvalue user-mode interface mainly obtains the semaphore count.

[0100] The first structure can be redefined using the second structure to obtain user-mode interface code. The second structure complies with the second operating system. It is understood that the first structure and the second structure correspond to the same functional mechanism, and the corresponding relationship can be seen in Table 2 above.

[0101] For example, if the first operating system is Linux and the second operating system is Windows, a user-mode interface similar to the Linux one can be implemented on Windows based on Windows' functional mechanisms. For example, in Linux, semaphores are implemented using the sem_t structure, while in Windows, they are implemented using the HANDLE structure and atomic variable structures.

[0102] In this case, the Linux operating system's sem_t structure can be redefined based on the Windows functional mechanism, that is, based on the HANDLE structure and the atomic variable structure. In other words, when adapting to the Linux operating system, the sem_t structure is defined, and when adapting to the Windows operating system, the sem_t structure can be redefined using the HANDLE structure and the atomic variable structure.

[0103] By redefining each of the first structures included in the first interface code one by one in the above manner, the user-mode interface code is obtained, thereby improving the efficiency of obtaining the user-mode interface code. Because the first structure is redefined using the second structure, and the first structure is used to define the user-mode interface, the second structure is compliant with the second operating system, making the user-mode interface compliant with the second operating system. Subsequently, when the second driver is running, it can directly call the encapsulated user-mode interface that complies with the second operating system.

[0104] In an embodiment of the present application, the electronic device may further obtain kernel-mode interface code. The kernel-mode interface code is used to provide a kernel-mode interface for interacting with the second operating system. The kernel-mode interface is an interface used in kernel mode. The embodiment of the present application does not limit the manner in which the electronic device obtains the kernel-mode interface code.

[0105] For example, a developer of the driver code can write kernel-mode interface code in the electronic device, and the electronic device obtains the kernel-mode interface code in response to the writing operation.

[0106] In another exemplary embodiment, the target interface code includes kernel-mode interface code. Obtaining the target interface code for providing an interface associated with the second operating system includes: extracting second interface code from the first driver code, the second interface code including a third structure consistent with the first operating system, the third structure being used to define the kernel-mode interface; and redefining the third structure using a fourth structure consistent with the second operating system to obtain the kernel-mode interface code.

[0107] The embodiment of the present application does not limit the method of extracting the second interface code from the first driver code. For example, the electronic device can determine the code selected by the selection operation as the second interface code based on the selection operation of the operation object on the first driver code. Alternatively, the first driver code includes the file where the second interface code is located, and the electronic device extracts the file to obtain the second interface code. Alternatively, the electronic device can obtain a configuration file, and the configuration text configures the position of the second interface code in the first driver code. The electronic device extracts the second interface code from the first driver code based on the position.

[0108] The second interface code includes at least one third structure, any of which complies with the first operating system. Figure 2 As shown, if the first operating system is a Linux operating system, the third structure may be a mutex_t structure, etc.; if the first operating system is a Windows operating system, the third structure may be a KMUTEXT structure, etc.

[0109] The third structure is used to define at least one kernel-mode interface, each of which has a corresponding function. In other words, the kernel-mode interface is used to implement the corresponding function, which can be achieved by calling the relevant function. It is understandable that different third structures will result in different kernel-mode interfaces and corresponding functions.

[0110] For example, the first operating system is Linux, and the third structure is a mutex_t structure. The mutex_t structure is a structure related to mutex locks and is used to define kernel state interfaces such as mutex_init (mutex lock initialization), mutex_lock (mutex lock locking), and mutex_unlock (mutex lock unlocking).

[0111] The mutex_init kernel-state interface mainly calls the KeInitializeMutex function to initialize the mutex. The mutex_lock kernel-state interface mainly calls the KeWaitForSingleObject function to lock the mutex. The mutex_unlock kernel-state interface mainly calls the KeReleaseMutex function to unlock the mutex.

[0112] The third structure can be redefined using the fourth structure to obtain kernel-mode interface code. The fourth structure complies with the second operating system. It is understood that the third and fourth structures correspond to the same functional mechanism, and the corresponding relationship can be seen in Table 2 above.

[0113] For example, if the first operating system is Linux and the second is Windows, the kernel-mode interface on Windows is implemented based on the Windows functional mechanisms, which are identical to those on Linux. For example, in Linux, mutex-related functional mechanisms are implemented using the mutex_t structure, while in Windows, they are implemented using the KMUTEX structure.

[0114] In this case, you can redefine the Linux mutex_t structure based on the Windows functionality, namely the KMUTEX structure. In other words, define the mutex_t structure when adapting to the Linux operating system, and then redefine it using the KMUTEXT structure when adapting to the Windows operating system. Alternatively, the code that redefines the mutex_t structure using the KMUTEXT structure is shown below.

[0115] typedef KMUTEX mutex_t;

[0116] #define mutex_init(mutex)\

[0117] do{

[0118] KeInitializeMutex(mutex, FALSE);\

[0119] }while(0)

[0120] / / Initialize the mutex

[0121] void mutex_lock(mutex*lock){

[0122] KeWaitForSingleObject(lock,Executive,KernelMode,FALSE,NULL);

[0123] }

[0124] / / Lock

[0125] void mutex_unlock(mutex*lock){

[0126] KeReleaseMutex(lock, FALSE);

[0127] }

[0128] / / Unlock

[0129] By redefining each of the third structures included in the second interface code one by one in the above manner, the kernel-mode interface code is obtained, thereby improving the efficiency of obtaining the kernel-mode interface code. Because the third structure is redefined using the fourth structure, and the third structure is used to define the kernel-mode interface, the fourth structure is compliant with the second operating system, making the kernel-mode interface compliant with the second operating system. Subsequently, when the second driver is running, it can directly call the encapsulated kernel-mode interface that complies with the second operating system.

[0130] From the above process of obtaining the interface code adapted to the Windows operating system based on the interface code adapted to the Linux operating system, it can be seen that developers do not need to understand the functional mechanism of the Windows operating system. They only need to use the structure of the Windows operating system to redefine the structure of the Linux operating system, and then they can develop the functional structure of the Windows operating system based on the functional interface of the Linux operating system.

[0131] That is to say, by obtaining the target interface code in a redefining manner, the operating object does not need to perceive the functional mechanism of the operating system, and can directly obtain the functional interface of the second operating system based on the functional interface of the first operating system, thereby speeding up the acquisition efficiency of the driver of the second operating system.

[0132] Step 204: Determine a second driver code based on the target interface code and the target function code.

[0133] In the embodiment of the present application, the target interface code and the target function code are combined so that the target function code is run based on the target interface code, and the second driving code is obtained based on the combined code.

[0134] Optionally, the target interface code includes a user-mode interface code, and the target function code includes a user-mode function code. The user-mode interface code and the user-mode function code can be combined so that the user-mode function code runs based on the user-mode interface code. Similarly, the target interface code includes a kernel-mode interface code, and the target function code includes a kernel-mode function code. The kernel-mode interface code and the kernel-mode function code can be combined so that the kernel-mode function code runs based on the kernel-mode interface code. The second driver code is obtained based on the combined code.

[0135] In an exemplary implementation, step 204 includes: obtaining a framework code, the framework code being used to define a function called when operating at least one of the second driver program or the hardware device; and determining a second driver code based on the framework code, the target interface code, and the target function code.

[0136] As mentioned above, the driver framework code varies greatly between different operating systems, resulting in a large amount of compatibility work and high compatibility difficulty. In addition, in general, the driver framework code accounts for a relatively low proportion of the driver code. Based on this, technicians can write framework code adapted to the second operating system, and the electronic device responds to the writing operation and obtains the framework code. The framework code is applicable to the second operating system.

[0137] Optionally, as shown in Table 1, the framework code is used to define functions called when operating the second driver. For example, if the second operating system is a Windows operating system, the framework code can define a DriverEntry function called when loading the second driver, an EvtDriverUnload function called when unloading the second driver, and the like.

[0138] Optionally, as shown in Table 1, the framework code is used to define functions called when operating a hardware device. For example, if the second operating system is a Windows operating system, the framework code may define an EvtDeviceD0Entry function called when waking up the hardware device.

[0139] By combining the framework code, the target interface code and the target function code, the target function code is run based on the target interface code and the framework code, and a second driver code is obtained based on the combined code.

[0140] Optionally, the target interface code includes kernel-mode interface code, and the target function code includes kernel-mode function code. The framework code, kernel-mode interface code, and kernel-mode function code may be combined so that the kernel-mode function code runs based on the framework code and kernel-mode interface code. In addition, the target interface code includes user-mode interface code, and the target function code includes user-mode function code. The user-mode interface code and user-mode function code may be combined so that the user-mode function code runs based on the user-mode interface code. The second driver code is obtained based on the combined code.

[0141] Step 205 : compile the second driver code to obtain a second driver program, where the second driver program is used to drive the hardware device to interact with the application program installed in the second operating system.

[0142] In an embodiment of the present application, the electronic device compiles a second driver code to obtain a second driver program adapted for the second operating system. The second driver program is a special program added to the second operating system that contains device information of the driven hardware device, and through this device information, enables the second operating system to communicate with the hardware device. In an embodiment of the present application, the second driver program is a software program that drives the hardware device and is used to drive the hardware device of the electronic device to interact with the second operating system of the electronic device and the application installed on the second operating system.

[0143] Optionally, the second driver provides an interface adapted for the second operating system. Through this interface, the application program can perform data input, data output, and control operations on the hardware device, thereby enabling interaction between the application program and the hardware device. For example, the hardware device is a codec chip, and the application program is video software. Through the interface provided by the second driver, the codec chip can encode or decode input signals from the video software to generate output signals, which are then accessible to the application program.

[0144] It is understood that the process of compiling the second driver code to obtain the second driver program is the process of converting the second driver code into the second driver program by performing lexical analysis and syntactic analysis on the second driver code. The second driver program is in a language that can be directly executed by computer hardware. The process of compiling the second driver code is described below.

[0145] In possible implementation A, the second driver code includes user-mode interface code and user-mode function code, and the second driver includes a user-mode driver. Step 205 includes: compiling the user-mode interface code to obtain a user-mode interface library, which is used to provide a user-mode interface for interaction with the second operating system; and compiling the user-mode function code based on the user-mode interface library to obtain a user-mode driver, which is used to exchange data with an application installed in the second operating system through the user-mode interface to implement the hardware device's user-mode function.

[0146] In an embodiment of the present application, the electronic device first compiles the user-mode interface code. The compilation process can be described as follows: first, the pre-compilation instructions in the user-mode interface code are pre-processed to obtain the pre-processed code. The pre-processing includes macro expansion, processing conditional compilation instructions, processing #include instructions, etc. Then, the pre-processed code is subjected to at least one of lexical analysis, syntax analysis, semantic analysis, or optimization, and the corresponding assembly code is generated. Thereafter, the assembly code is converted into executable code. The user-mode interface library includes executable code for providing a user-mode interface adapted to the second operating system.

[0147] Optionally, the user-mode interface library includes a static library and a dynamic library corresponding to the user-mode interface. In some cases, the static library is named libxxx.a, and this type of static library can be called a lib static library, and the dynamic library is named libxxx.so, and this type of dynamic library can be called a dll dynamic library. The difference between static libraries and dynamic libraries lies in the different times when the code is loaded. The code of the static library will be loaded into the program during the compilation process, so the size of the static library is relatively large, while the code of the dynamic library is only loaded when the program is running, and is only simply referenced during the compilation process, so the code size of the dynamic library is relatively small.

[0148] Generally speaking, static libraries are linked into the code when the program is compiled and are no longer needed when the program is running. Dynamic libraries are not linked into the code when the program is compiled, but are loaded when the program is running, so dynamic libraries are still needed when the program is running.

[0149] Based on this, the static library corresponding to the user state interface is used to compile the user state driver. The dynamic library corresponding to the user state interface is used when running the user state driver in the user state of the second operating system.

[0150] In an embodiment of the present application, the electronic device compiles the user-state function code based on the user-state interface library, specifically based on the static library corresponding to the user-state interface, to obtain a user-state driver. The compilation process can be described as follows: first, the pre-compiled instructions in the user-state function code are pre-processed to obtain the pre-processed code, and the pre-processing includes macro expansion, processing conditional compilation instructions, processing #include instructions, etc. Then, based on the static library corresponding to the user-state interface, the pre-processed code is subjected to at least one of lexical analysis, syntax analysis, semantic analysis or optimization, and the corresponding assembly code is generated. Afterwards, the assembly code is converted into executable code. Among them, the user-state driver includes the executable code, which is used to perform data interaction with the application installed in the second operating system through the user-state interface to realize the function of the hardware device in the user state.

[0151] It is understood that the user-mode driver includes corresponding static libraries and dynamic libraries. Optionally, based on the static library corresponding to the user-mode driver, the source code of the application adapted to the second operating system is compiled to obtain an installation package of the application. The installation package is an executable file used to install the application in the second operating system so that the application can run in the second operating system. During the operation of the application, the dynamic library corresponding to the user-mode driver can be called, so that the application can interact with the user-mode driver, thereby realizing the functions of the hardware device in user mode.

[0152] The following takes the adaptation of the user-mode driver to the Windows operating system as an example to explain the compilation process of the user-mode driver. Figure 3 As shown. First, the user-mode interface code adapted to the Windows operating system is compiled to obtain the Lib static library and DLL dynamic library corresponding to the user-mode interface. Next, based on the Lib static library corresponding to the user-mode interface, the user-mode function code adapted to the Windows operating system is compiled to obtain the Lib static library and DLL dynamic library corresponding to the user-mode driver. After that, based on the Lib static library corresponding to the user-mode driver, the source code adapted to the Windows operating system is compiled to obtain the application installation package.

[0153] It is understandable that the user-state driver code includes a user-state interface code and a user-state function code. Among them, the user-state function code adapted to the second operating system can directly reuse the user-state function code adapted to the first operating system, and the user-state interface code adapted to the second operating system can be obtained by redefining the structure of the user-state interface code adapted to the first operating system, so that the acquisition efficiency of the user-state driver code is high, thereby improving the acquisition efficiency of the user-state driver program. In addition, under normal circumstances, since the source code of applications adapted to different operating systems can be reused with each other, the solution based on the embodiment of the present application can improve the efficiency of obtaining the installation package of the application. In general, a lot of workload is reduced.

[0154] In possible implementation B, the second driver code includes kernel-state interface code and kernel-state function code, and the second driver includes a kernel-state driver. Step 205 includes compiling the kernel-state function code based on the kernel-state interface code to obtain a kernel-state driver. The kernel-state driver is used to communicate with the hardware device via a kernel-state interface provided by the kernel-state interface code to implement the hardware device's kernel-state function.

[0155] In the embodiment of the present application, different from the compilation process of the user mode driver, the kernel mode interface code cannot be compiled separately to generate the interface library. Therefore, when compiling the kernel mode driver, it is necessary to add the kernel mode interface code, compile the kernel mode function code based on the kernel mode interface code, and obtain the kernel mode driver. This compilation process can be described as follows: first, the pre-compiled instructions in the kernel mode interface code and the kernel mode function code are pre-processed to obtain the pre-processed code, and this pre-processing includes macro expansion, processing conditional compilation instructions, processing #include instructions, etc. Then, after the pre-processed code is subjected to at least one of lexical analysis, grammatical analysis, semantic analysis or optimization, corresponding assembly code is generated. Afterwards, the assembly code is converted into executable code. Wherein, the kernel mode driver includes this executable code, which is used to interact with the hardware device through the kernel mode interface and realize the function of the hardware device in the kernel mode.

[0156] The following takes the kernel-mode driver adaptation to the Windows operating system as an example to explain the compilation process of the kernel-mode driver. Figure 4 As shown in the figure, first, kernel-mode interface code adapted for the Windows operating system is obtained. Then, kernel-mode driver code adapted for the Windows operating system is obtained based on the kernel-mode interface code, reused kernel-mode function code, and written framework code. After that, the kernel-mode driver code is compiled to obtain a kernel-mode driver program.

[0157] It is understandable that the kernel-state driver code includes kernel-state interface code, kernel-state function code, and framework code. Specifically, the kernel-state function code adapted for the second operating system can directly reuse the kernel-state function code adapted for the first operating system, while the kernel-state interface code adapted for the second operating system can be obtained by redefining the structure of the kernel-state interface code adapted for the first operating system, which requires less work. Furthermore, the framework code accounts for a relatively small proportion of the driver code, and the workload of writing the driver code adapted for the second operating system is relatively small. These features make the acquisition efficiency of the kernel-state driver code high, thereby improving the acquisition efficiency of the kernel-state driver program.

[0158] It should be noted that the user state driver can interact with the kernel state driver. In some cases, the user state interface and the kernel state interface have a one-to-one correspondence. The data from the user state driver can be output through the user state interface and input into the kernel state driver through the corresponding kernel state interface. Similarly, the data from the kernel state driver can be output through the kernel state interface and input into the user state driver through the corresponding user state interface. In this way, the interaction between the user state driver and the kernel state driver is realized. In addition, the user state driver can interact with the application program, and the kernel state driver can interact with the hardware device. By the aforementioned three interactions, the application program and the hardware device are realized to interact.

[0159] In an embodiment of the present application, a user-mode driver can exchange data with an application and a kernel-mode driver, and a kernel-mode driver can exchange data with a hardware device and a user-mode driver. Based on this, on the one hand, the user-mode driver can obtain data from an application, pre-process the application data, and then transmit it to the kernel-mode driver. The kernel-mode driver can obtain pre-processed data, process the pre-processed data, and then transmit the obtained data to the hardware device. On the other hand, the kernel-mode driver can obtain data from a hardware device, process the hardware device data, and then transmit it to the user-mode driver. The user-mode driver can obtain processed data, post-process the processed data, and then transmit the obtained data to the application.

[0160] From the above content, it can be seen that the functions of the hardware device in user mode include at least one of the following: obtaining data from the application; pre-processing the data from the application; sending the pre-processed data to the kernel-mode driver; obtaining data from the kernel-mode driver; post-processing the data from the kernel-mode driver; and sending the post-processed data to the application.

[0161] The functions of the hardware device in kernel state include at least one of the following: obtaining data from the user-state driver; processing the data from the user-state driver; sending the processed data to the hardware device; obtaining data from the hardware device; processing the data from the hardware device; and sending the processed data to the user-state driver.

[0162] As mentioned above, the generation method of the first driver is similar to the generation method of the second driver. Based on this, it can be seen that the user-state driver in the first driver uses a user-state interface adapted to the first operating system, and the user-state driver in the second driver uses a user-state interface adapted to the second operating system, and the user-state driver in the first driver and the user-state driver in the second driver are both obtained based on the same user-state function code. Based on this, the first interface code and the user-state interface code are used to distinguish the first operating system and the second operating system, so that the user-state function code can shield the differences between the first operating system and the second operating system. Based on this, the user-state function codes adapted to different operating systems can be reused with each other, so that different operating systems can be compatible with the same user-state function code, thereby achieving compatibility of user-state drivers between the first operating system and the second operating system.

[0163] Similarly, the kernel-mode driver in the first driver uses a kernel-mode interface adapted for the first operating system, and the kernel-mode driver in the second driver uses a kernel-mode interface adapted for the second operating system, and both the kernel-mode driver in the first driver and the kernel-mode driver in the second driver are derived based on the same kernel-mode function code. Based on this, the second interface code and the kernel-mode interface code are used to distinguish between the first operating system and the second operating system, so that the kernel-mode function code can mask the differences between the first operating system and the second operating system. Based on this, kernel-mode function codes adapted for different operating systems can be reused, making different operating systems compatible with the same kernel-mode function code.

[0164] For example, in a Linux operating system, function code uses the Linux operating system interface, while in a Windows operating system, function code uses the Windows operating system interface. This allows operating systems to be distinguished at the interface code level, without having to distinguish them at the function code level. In other words, by distinguishing operating systems through interface codes, function code can directly call the corresponding operating system's interface.

[0165] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant region. For example, the first driver code, target function code, etc. involved in this application are all obtained with full authorization.

[0166] Based on the first driver code adapted for the first operating system, the above method extracts the target function code from the first driver code, thereby reusing the target function code and quickly determining the second driver code adapted for the second operating system based on the target function code and the target interface code adapted for the second operating system. Because the target function code accounts for a larger proportion and the target interface code accounts for a smaller proportion, reusing the target function code can significantly reduce the time to obtain the second driver code, thereby quickly obtaining a driver adapted for the second operating system based on the second driver code, improving the efficiency of driver acquisition.

[0167] The above describes the method for obtaining the driver mentioned in the embodiment of the present application from the perspective of method steps, and is described below in conjunction with the scenario. The method of the embodiment of the present application can be applied to any scenario where hardware devices need to be configured in different operating systems. For example, in the scenario of audio reading, a sound card is needed to achieve sound effects such as crying, laughing, talking, and wind. Generally, games are installed in multiple operating systems. In this case, the driver for the sound card that is adapted to multiple operating systems can be obtained according to the method of the embodiment of the present application. For another example, in scenarios such as games and videos, not only a sound card is needed to achieve sound effects, but also a graphics card is needed to achieve visual effects. In this case, the driver for the sound card that is adapted to multiple operating systems and the driver for the graphics card that is adapted to multiple operating systems can be obtained according to the method of the embodiment of the present application.

[0168] The following describes the implementation of an embodiment of the present application using a scenario where the hardware device is a codec chip, the first operating system is a Linux operating system, and the second operating system is a Windows operating system. That is, on the one hand, it is necessary to obtain a driver for a codec chip that is compatible with the Linux operating system, and on the other hand, it is necessary to obtain a driver for a codec chip that is compatible with the Windows operating system. For ease of description, the task of obtaining these two drivers is referred to as a project.

[0169] At the beginning of the project, considering limited human resources, only the driver of the codec chip adapted to the Linux operating system was implemented. As the codec chips were gradually put into production, it was identified that the codec chips had application scenarios requiring the Windows operating system, for example, the need to implement cloud desktop and cloud gaming scenarios on the Windows operating system. Since the project needed to test the codec chip on the Windows operating system to evaluate the usability of the codec, it was necessary to obtain the driver of the codec chip adapted to the Windows operating system. If the traditional acquisition method was used, technical personnel would need to learn the development of drivers adapted to the Windows operating system, or recruit technical personnel with experience in developing drivers adapted to the Windows operating system. This is equivalent to obtaining the driver adapted to the Windows operating system from scratch. The initial evaluation would require at least one year of time and five man-years of development human resources.

[0170] However, the driver of the codec chip adapted to the Windows operating system is obtained by the method of the embodiment of the present application. On the one hand, by comparing the differences between the KMDF (Kernel Mode Driver Framework) driver framework of the Windows operating system and the driver framework of the Linux operating system, a framework code adapted to the Windows operating system is written based on the differences. On the other hand, by comparing the differences between the functional mechanisms of the Windows operating system and the functional mechanisms of the Linux operating system, a structural redefinition is performed based on the differences to obtain an interface code adapted to the Windows operating system. By reusing the functional code adapted to the Linux operating system and combining the framework code and interface code adapted to the Windows operating system, a driver code adapted to the Windows operating system can be obtained, thereby obtaining a driver adapted to the Windows operating system.

[0171] Based on the method of the embodiment of the present application, only one or two technicians are needed to understand the driving mechanism of the Windows operating system, and there is no need to learn the development of the driver program for the Windows operating system. By reusing the function code and redefining the structure in the interface code, the development workload of the driver program for the Windows operating system is reduced, so that the development cost is reduced from the traditional 1-year time cycle and 5 man-years of human resources to a 4-month time cycle and 2 man-years of human resources, which reduces the workload by 60%. By significantly reducing the project development time, it is possible to quickly obtain the driver program for the codec chip that is adapted to the Windows operating system, meeting the project requirement of testing the codec chip on the Windows operating system.

[0172] Furthermore, the method based on the embodiment of the present application not only significantly reduces acquisition time and workload, but also reduces subsequent code maintenance time. The method of the embodiment of the present application can be applied to the development of drivers for other hardware devices, significantly reducing the workload and time required for driver adaptation to different operating systems.

[0173] In the embodiments of this application, drivers for the codec chip were obtained for the Linux and Windows operating systems. Furthermore, applications can be installed on the Linux and Windows operating systems, and the drivers enable interaction between the applications and the codec chip. The following example illustrates the interaction between the codec chip and a film and television application.

[0174] like Figure 5 As shown, Figure 5 : This is a schematic diagram of a software stack provided by an embodiment of the present application. In a general scenario, the software stack includes three parts: an application (such as a film and television application), a driver, and a hardware device (such as a codec chip). The driver includes two parts: a user-state driver and a kernel-state driver. The user-state driver runs in user state and is used to provide a user-state interface. On the one hand, it interacts with the application through the user-state interface, and on the other hand, it interacts with the kernel-state driver through the user-state interface, so that the application can interact with the kernel-state driver. The kernel-state driver runs in kernel state. In addition to interacting with the user-state driver, it can also interact directly with the hardware device and handle low-level operations such as interrupts and DMA. The kernel-state driver can provide a kernel-state interface, which is an access interface to the hardware device. Since the kernel-state interface corresponds to the user-state interface, the user-state driver can also obtain an access interface to the hardware device.

[0175] In the embodiments of the present application, based on general scenarios, user-mode drivers are divided into user-mode OS (Operating System) compatible programs and user-mode functional programs, and kernel-mode drivers are divided into kernel-mode OS compatible programs and kernel-mode functional programs. The user-mode OS compatible program is located between the user-mode functional program and the kernel-mode functional program, and is used to provide a user-mode interface. The kernel-mode OS compatible program is located between the kernel-mode functional program and the codec chip, and is used to provide a kernel-mode interface.

[0176] That is, the software stack in the embodiment of the present application includes a film and television application, a user-mode functional program, a user-mode OS-compatible program, a kernel-mode functional program, a kernel-mode OS-compatible program, and a codec chip. If the operating system is a Windows operating system, the user-mode OS-compatible program is used to provide a Windows user-mode interface, and the kernel-mode OS-compatible program is used to provide a Windows kernel-mode interface. If the operating system is a Linux operating system, the user-mode OS-compatible program is used to provide a Linux user-mode interface, and the kernel-mode OS-compatible program is used to provide a Linux kernel-mode interface.

[0177] In an optional scenario, for a codec chip, it is possible to give priority to developing a driver program adapted to the Linux operating system, and then developing a driver program adapted to the Windows operating system. Based on the method of the embodiment of the present application, developers only need to understand the driver framework and functional mechanism of the Linux operating system. By using the differences between the driver framework and functional mechanism of the Linux operating system and the Windows operating system, it is possible to quickly obtain a driver program adapted to the Windows operating system. Not only is the development cycle short, but since most of the code can be directly reused, the amount of code to be maintained is reduced, thereby improving maintainability. In addition, the method of the embodiment of the present application has good scalability and can be extended to other operating systems and hardware devices.

[0178] Figure 6 FIG. 1 is a schematic diagram of a structure of a device for obtaining a driver program provided in an embodiment of the present application. Figure 6 As shown, the device includes:

[0179] An acquisition module 601 is configured to acquire a first driver code of a hardware device, where the first driver code is used to generate a first driver program, and the first driver program is used to drive the hardware device to interact with an application program installed in a first operating system.

[0180] An extraction module 602 is configured to extract a target function code for implementing a function of a hardware device from the first driver code;

[0181] The acquisition module 601 is further configured to acquire a target interface code for providing an interface related to the second operating system;

[0182] A determination module 603 is configured to determine a second driver code based on the target interface code and the target function code;

[0183] The compiling module 604 is configured to compile the second driver code to obtain a second driver program, where the second driver program is configured to drive the hardware device to interact with the application program installed in the second operating system.

[0184] In a possible implementation, the target function code includes at least one of a user-mode function code or a kernel-mode function code;

[0185] Among them, the user-state function code is used to implement the function of the hardware device in the user state; the kernel-state function code is used to implement the function of the hardware device in the kernel state.

[0186] In one possible implementation, the target interface code includes at least one of a user-mode interface code or a kernel-mode interface code;

[0187] The user-mode interface code is used to provide a user-mode interface for interacting with the second operating system; and the kernel-mode interface code is used to provide a kernel-mode interface for interacting with the second operating system.

[0188] In one possible implementation, the target interface code includes a user-mode interface code;

[0189] Acquisition module 601 is used to extract the first interface code from the first driver code, where the first interface code includes a first structure that complies with the first operating system, and the first structure is used to define the user-mode interface; the first structure is redefined by a second structure that complies with the second operating system to obtain the user-mode interface code.

[0190] In one possible implementation, the target interface code includes kernel-mode interface code;

[0191] Acquisition module 601 is used to extract the second interface code from the first driver code, where the second interface code includes a third structure that complies with the first operating system, and the third structure is used to define the kernel-mode interface; the third structure is redefined by a fourth structure that complies with the second operating system to obtain the kernel-mode interface code.

[0192] In one possible implementation, the determination module 603 is used to obtain a framework code, which is used to define a function called when operating at least one of the second driver program or the hardware device; and determine the second driver code based on the framework code, the target interface code and the target function code.

[0193] In one possible implementation, the second driver code includes a user-mode interface code and a user-mode function code, and the second driver program includes a user-mode driver program;

[0194] Compilation module 604 is used to compile the user-state interface code to obtain a user-state interface library, which is used to provide a user-state interface for interacting with the second operating system; based on the user-state interface library, the user-state function code is compiled to obtain a user-state driver, which is used to interact with the application installed in the second operating system through the user-state interface to realize the function of the hardware device in the user state.

[0195] In one possible implementation, the second driver code includes a kernel-state interface code and a kernel-state function code, and the second driver program includes a kernel-state driver program;

[0196] Compilation module 604 is used to compile the kernel state function code based on the kernel state interface code to obtain a kernel state driver. The kernel state driver is used to communicate with the hardware device through the kernel state interface provided by the kernel state interface code to realize the function of the hardware device in the kernel state.

[0197] Based on the first driver code adapted for the first operating system, the above-mentioned device extracts the target function code from the first driver code, thereby reusing the target function code, thereby quickly determining the second driver code adapted for the second operating system through the target function code and the target interface code adapted for the second operating system. Because the target function code accounts for a larger proportion and the target interface code accounts for a smaller proportion, reusing the target function code can significantly reduce the time to obtain the second driver code, thereby quickly obtaining the driver adapted for the second operating system based on the second driver code, and improving the efficiency of driver acquisition.

[0198] It should be understood that the above Figure 6 The provided device is illustrated only by the division of the above-mentioned functional modules when implementing its functions. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the device and method embodiments provided in the above embodiments are based on the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0199] Figure 7 FIG2 shows a block diagram of a terminal device 700 provided by an exemplary embodiment of the present application. The terminal device 700 includes a processor 701 and a memory 702 .

[0200] The processor 701 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 701 may be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), or PLA (Programmable Logic Array). The processor 701 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 701 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 701 may also include an AI (Artificial Intelligence) processor, which is used to process computing operations related to machine learning.

[0201] The memory 702 may include one or more computer-readable storage media, which may be non-transitory. The memory 702 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices and flash memory storage devices. In some embodiments, the non-transitory computer-readable storage medium in the memory 702 is used to store at least one computer program, which is executed by the processor 701 to implement the driver acquisition method provided in the method embodiment of the present application.

[0202] In some embodiments, terminal device 700 may optionally include a peripheral device interface 703 and at least one peripheral device. The processor 701, memory 702, and peripheral device interface 703 may be connected via a bus or signal lines. Each peripheral device may be connected to peripheral device interface 703 via a bus, signal lines, or circuit boards. Specifically, the peripheral device may include at least one of a radio frequency circuit 704, a display screen 705, a camera assembly 706, an audio circuit 707, and a power supply 708.

[0203] The peripheral device interface 703 can be used to connect at least one I / O (Input / Output)-related peripheral device to the processor 701 and the memory 702. In some embodiments, the processor 701, the memory 702, and the peripheral device interface 703 are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor 701, the memory 702, and the peripheral device interface 703 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0204] The RF circuit 704 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 704 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 704 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals into electrical signals. Optionally, the RF circuit 704 includes an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, and the like. The RF circuit 704 can communicate with other terminals via at least one wireless communication protocol. Such wireless communication protocols include, but are not limited to, the World Wide Web, metropolitan area networks, intranets, various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks, and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 704 may also include circuitry related to Near Field Communication (NFC), which is not limited in this application.

[0205] Display screen 705 is used to display a user interface (UI). This UI may include graphics, text, icons, videos, or any combination thereof. When display screen 705 is a touchscreen display, it is also capable of collecting touch signals on or above the surface of display screen 705. These touch signals can be input as control signals to processor 701 for processing. Display screen 705 can also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard. In some embodiments, there can be one display screen 705, located on the front panel of terminal device 700. In other embodiments, there can be at least two display screens 705, located on different surfaces of terminal device 700 or in a foldable design. In still other embodiments, display screen 705 can be a flexible display, located on a curved or foldable surface of terminal device 700. Display screen 705 can also be configured as a non-rectangular, irregular shape, also known as a special-shaped screen. Display screen 705 can be made of materials such as LCD (Liquid Crystal Display) and OLED (Organic Light-Emitting Diode).

[0206] The camera assembly 706 is used to capture images or videos. Optionally, the camera assembly 706 includes a front camera and a rear camera. Typically, the front camera is arranged on the front panel of the terminal, and the rear camera is arranged on the back of the terminal. In some embodiments, there are at least two rear cameras, which are any one of a main camera, a depth of field camera, a wide-angle camera, and a telephoto camera, so as to realize the fusion of the main camera and the depth of field camera to realize the background blur function, the fusion of the main camera and the wide-angle camera to realize panoramic shooting and VR (Virtual Reality) shooting function or other fusion shooting functions. In some embodiments, the camera assembly 706 may also include a flash. The flash can be a monochrome temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm light flash and a cold light flash, which can be used for light compensation at different color temperatures.

[0207] The audio circuit 707 may include a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, and convert the sound waves into electrical signals and input them into the processor 701 for processing, or input them into the radio frequency circuit 704 to achieve voice communication. For the purpose of stereo acquisition or noise reduction, there can be multiple microphones, which are respectively arranged in different parts of the terminal device 700. The microphone can also be an array microphone or an omnidirectional acquisition microphone. The speaker is used to convert the electrical signals from the processor 701 or the radio frequency circuit 704 into sound waves. The speaker can be a traditional thin film speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can not only convert the electrical signals into sound waves audible to humans, but also convert the electrical signals into sound waves inaudible to humans for purposes such as ranging. In some embodiments, the audio circuit 707 may also include a headphone jack.

[0208] Power supply 708 is used to power various components in terminal device 700. Power supply 708 can be AC power, DC power, a disposable battery, or a rechargeable battery. When power supply 708 includes a rechargeable battery, the rechargeable battery can be a wired rechargeable battery or a wireless rechargeable battery. A wired rechargeable battery is charged via a wired line, while a wireless rechargeable battery is charged via a wireless coil. The rechargeable battery can also support fast charging technology.

[0209] In some embodiments, the terminal device 700 further includes one or more sensors 709 , including but not limited to: an acceleration sensor 711 , a gyroscope sensor 712 , a pressure sensor 713 , an optical sensor 714 , and a proximity sensor 715 .

[0210] The accelerometer 711 can detect the magnitude of acceleration along the three coordinate axes of the coordinate system established by the terminal device 700. For example, the accelerometer 711 can be used to detect the components of gravity acceleration along the three coordinate axes. The processor 701 can control the display screen 705 to display the user interface in a landscape or portrait view based on the gravity acceleration signal collected by the accelerometer 711. The accelerometer 711 can also be used to collect game or user motion data.

[0211] The gyroscope sensor 712 can detect the body orientation and rotation angle of the terminal device 700. The gyroscope sensor 712 can work with the acceleration sensor 711 to collect the user's 3D movements of the terminal device 700. Based on the data collected by the gyroscope sensor 712, the processor 701 can implement the following functions: motion sensing (such as changing the UI based on the user's tilt operation), image stabilization during shooting, game control, and inertial navigation.

[0212] The pressure sensor 713 can be set on the side frame of the terminal device 700 and / or the lower layer of the display screen 705. When the pressure sensor 713 is set on the side frame of the terminal device 700, it can detect the user's grip signal of the terminal device 700, and the processor 701 performs left and right hand recognition or shortcut operations based on the grip signal collected by the pressure sensor 713. When the pressure sensor 713 is set on the lower layer of the display screen 705, the processor 701 controls the operable controls on the UI interface based on the user's pressure operation on the display screen 705. The operable controls include at least one of a button control, a scroll bar control, an icon control, and a menu control.

[0213] Optical sensor 714 is used to detect ambient light intensity. In one embodiment, processor 701 can control the display brightness of display screen 705 based on the ambient light intensity detected by optical sensor 714. Specifically, when the ambient light intensity is high, the display brightness of display screen 705 is increased; when the ambient light intensity is low, the display brightness of display screen 705 is decreased. In another embodiment, processor 701 can also dynamically adjust the shooting parameters of camera assembly 706 based on the ambient light intensity detected by optical sensor 714.

[0214] The proximity sensor 715, also known as a distance sensor, is typically located on the front panel of the terminal device 700. The proximity sensor 715 is used to detect the distance between the user and the front of the terminal device 700. In one embodiment, when the proximity sensor 715 detects that the distance between the user and the front of the terminal device 700 is gradually decreasing, the processor 701 controls the display screen 705 to switch from the screen-on state to the screen-off state. When the proximity sensor 715 detects that the distance between the user and the front of the terminal device 700 is gradually increasing, the processor 701 controls the display screen 705 to switch from the screen-off state to the screen-on state.

[0215] Those skilled in the art will understand that Figure 7 The structure shown in the figure does not constitute a limitation on the terminal device 700, and the terminal device 700 may include more or fewer components than shown in the figure, or combine certain components, or adopt a different component arrangement.

[0216] Figure 8This is a schematic diagram of the structure of the server provided in an embodiment of the present application. The server 800 may vary significantly due to different configurations or performance, and may include one or more processors 801 and one or more memories 802, wherein the one or more memories 802 store at least one computer program, which is loaded and executed by the one or more processors 801 to implement the driver acquisition method provided in each of the above method embodiments. Exemplarily, the processor 801 is a CPU. Of course, the server 800 may also have components such as a wired or wireless network interface, a keyboard, and an input / output interface for input and output. The server 800 may also include other components for implementing device functions, which will not be described in detail here.

[0217] In an exemplary embodiment, a computer-readable storage medium is further provided. The storage medium stores at least one computer program. The at least one computer program is loaded and executed by a processor to enable an electronic device to implement any of the above-mentioned methods for obtaining a driver.

[0218] Optionally, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc (CD-ROM), a magnetic tape, a floppy disk, an optical data storage device, or the like.

[0219] In an exemplary embodiment, a computer program is further provided. The computer program is at least one and is loaded and executed by a processor to enable an electronic device to implement any of the above methods for obtaining a driver.

[0220] In an exemplary embodiment, a computer program product is further provided. The computer program product stores at least one computer program. The at least one computer program is loaded and executed by a processor to enable an electronic device to implement any of the above-mentioned methods for obtaining a driver.

[0221] It should be understood that the term "plurality" used herein refers to two or more. "And / or" describes a relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, or B exists alone. The character " / " generally indicates an "or" relationship between the associated objects.

[0222] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0223] The above description is merely an exemplary embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A method for obtaining a driver, characterized in that: The method comprises: Obtaining a first driver code for a hardware device, where the first driver code is used to generate a first driver program, and the first driver program is used to drive the hardware device to interact with an application program installed in a first operating system; Extracting a target function code for implementing a function of the hardware device from the first driver code; Acquire a target interface code for providing an interface related to the second operating system; Determining a second driving code based on the target interface code and the target function code; The second driver code is compiled to obtain a second driver program, where the second driver program is used to drive the hardware device to interact with an application program installed in the second operating system.

2. The method according to claim 1, characterized in that The target function code includes at least one of a user state function code or a kernel state function code; The user-state function code is used to implement the function of the hardware device in the user state; the kernel-state function code is used to implement the function of the hardware device in the kernel state.

3. The method according to claim 1, characterized in that The target interface code includes at least one of a user-mode interface code and a kernel-mode interface code; The user-mode interface code is used to provide a user-mode interface for interacting with the second operating system; and the kernel-mode interface code is used to provide a kernel-mode interface for interacting with the second operating system.

4. The method according to claim 3, characterized in that The target interface code includes a user-mode interface code; The obtaining of a target interface code for providing an interface related to the second operating system includes: Extracting a first interface code from the first driver code, where the first interface code includes a first structure that complies with the first operating system, and the first structure is used to define the user-mode interface; The user-mode interface code is obtained by redefining the first structure through a second structure that conforms to the second operating system.

5. The method according to claim 3, characterized in that The target interface code includes a kernel state interface code; The obtaining of a target interface code for providing an interface related to the second operating system includes: Extracting a second interface code from the first driver code, where the second interface code includes a third structure that complies with the first operating system, and the third structure is used to define a kernel-mode interface; The kernel-mode interface code is obtained by redefining the third structure through a fourth structure that complies with the second operating system.

6. The method according to claim 1, characterized in that The determining of the second driving code based on the target interface code and the target function code includes: Obtaining a framework code, where the framework code is used to define a function called when operating at least one of the second driver or the hardware device; A second driving code is determined based on the framework code, the target interface code and the target function code.

7. The method according to claim 1, characterized in that The second driver code includes a user-mode interface code and a user-mode function code, and the second driver program includes a user-mode driver program; and compiling the second driver code to obtain the second driver program includes: Compiling the user-mode interface code to obtain a user-mode interface library, wherein the user-mode interface library is used to provide a user-mode interface for interacting with the second operating system; The user-state function code is compiled based on the user-state interface library to obtain the user-state driver, which is used to interact with the application installed in the second operating system through the user-state interface to realize the function of the hardware device in the user state.

8. The method according to claim 1, characterized in that The second driver code includes a kernel-state interface code and a kernel-state function code, and the second driver program includes a kernel-state driver program; and compiling the second driver code to obtain the second driver program includes: The kernel-state function code is compiled based on the kernel-state interface code to obtain the kernel-state driver, which is used to communicate with the hardware device through the kernel-state interface provided by the kernel-state interface code to realize the function of the hardware device in the kernel state.

9. A device for obtaining a driver, characterized in that: The device comprises: an acquisition module, configured to acquire a first driver code of a hardware device, wherein the first driver code is used to generate a first driver program, and the first driver program is used to drive the hardware device to interact with an application program installed in a first operating system; an extraction module, configured to extract a target function code for implementing a function of the hardware device from the first driver code; The acquisition module is further configured to acquire a target interface code for providing an interface related to the second operating system; A determination module, configured to determine a second driving code based on the target interface code and the target function code; A compiling module is used to compile the second driver code to obtain a second driver program, where the second driver program is used to drive the hardware device to interact with an application program installed in the second operating system.

10. An electronic device, characterized in that: The electronic device includes a processor and a memory, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor, so that the electronic device implements the driver acquisition method according to any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that The computer-readable storage medium stores at least one computer program, and the at least one computer program is loaded and executed by the processor to enable the electronic device to implement the method for obtaining a driver according to any one of claims 1 to 8.

12. A computer program product, characterized in that The computer program product stores at least one computer program, and the at least one computer program is loaded and executed by a processor to enable the electronic device to implement the method for obtaining a driver according to any one of claims 1 to 8.

Images