Device control method, device and storage medium

Abstract

A device control method, apparatus, and storage medium. The method includes: acquiring a target image and a system call file of a second operating system; wherein the target image includes a target application running on the second operating system, a first driver library file, and a compatibility library file; deploying the target image and the system call file in the first operating system; running the target application, causing the target application to call a target first driver function in the first driver library file, determining a target system call function from the system call file based on the target first driver function using the compatibility library file, and calling the device hardware through the target system call function.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a device control method, apparatus, and storage medium. Prior Technology

[0002] In industrial settings, to achieve higher performance and accommodate more specialized peripheral devices in industrial manufacturing, business systems are often developed using C and C++ languages. Therefore, these systems need to be compiled and deployed on specific computer architectures and operating systems.

[0003] With the development of computer hardware and software technology, computer architecture and operating systems are upgraded and changed rapidly. In order to ensure the reliability of business systems and reduce development costs, it is more reasonable to smoothly migrate the original business systems under the new architecture and operating system, rather than redeveloping new business systems.

[0004] For migrating business systems, the original system can be packaged into a Docker image and then deployed to the new architecture and operating system, allowing the original system to run on the new architecture and operating system. However, if the original system includes hardware access functionality, after migrating using the above method, the system needs to call the new operating system's system call files, access the new operating system's kernel through these files, and then use driver functions within the kernel to implement the hardware access functionality. This series of calls can lead to cross-architecture compatibility issues, preventing the system from accessing the hardware correctly. Summary of the Invention

[0005] In view of the above problems, embodiments of this application are proposed to provide a device control method, apparatus and storage medium that overcomes or at least partially solves the above problems.

[0006] In a first aspect, embodiments of this application disclose a device control method, wherein the device is equipped with a first operating system, and the method includes: The system obtains a target image, a compiled file, and a system call file for a second operating system. The target image includes a target application running on the second operating system, a first driver library file, and a compatibility library file. The first driver library file includes at least one first driver function, which is used to call system call functions through the compatibility library file. The compatibility library file includes a mapping relationship between the first driver function and the system call functions. The system call file includes at least one of the system call functions, which is used to call the hardware of the device. The compiled file is used to compile and link the target application, the first driver library file, and the compatibility library file. The system call file is deployed in the first operating system, and the target application, the first driver library file, and the compatible library file in the target image are compiled in the first operating system according to the compilation file; The target application in the target image is run on the first operating system to determine the target first driver function corresponding to the target application, the target system call function is determined according to the target first driver function and the mapping relationship, and the hardware of the device is invoked according to the target system call function.

[0007] Secondly, embodiments of this application disclose a device control apparatus, including: a processor and a memory, wherein the memory stores a computer program, and when the processor executes the computer program, it performs the steps of the device control method described above.

[0008] Thirdly, embodiments of this application disclose a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the device control method described above.

[0009] The embodiments of this application have the following advantages: When migrating a target application from a second operating system to a first operating system, the target image, compiled files, and system call files of the second operating system are first obtained. The target image includes the target application, a first driver library file, and compatible library files. Then, the system call files of the second operating system are deployed on the first operating system. On the first operating system, the target application, the first driver library file, and the compatible library files in the target image are compiled according to the compiled files. The purpose of this compilation is to ensure that the target application can successfully call the first driver library file at runtime and, through the first driver library file, call the compatible library files.

[0010] After the system call files are deployed and the target image is compiled, the target application in the target image can be run on the first operating system. This allows the target application to call the first driver library file, which in turn calls the compatible library file. The compatible library file then calls the system call files of the second operating system deployed on the first system. Finally, the second operating system's system call files access the first operating system's kernel, and the driver functions within the kernel implement hardware calls. Since the target application, the first driver library file, the compatible library file, and the system call files are all based on or written for the second operating system, there are no compatibility issues when these four components call each other. Furthermore, because the system kernel is more powerful and has better code compatibility with different operating systems, accessing the first operating system's kernel through the second operating system's system call files to implement hardware calls reduces compatibility issues and makes hardware calls smoother. Simple Explanation of the Diagram

[0011] Figure 1 is a schematic diagram of an application running according to an embodiment of this application; Figure 2 is a schematic diagram of application migration provided in an embodiment of this application; Figure 3 is a flowchart of the steps of a device control method provided in an embodiment of this application; Figure 4 is an architecture diagram provided in an embodiment of this application; Figure 5 is a flowchart of a device control method provided in an embodiment of this application; Figure 6 is a flowchart of another device control method provided in an embodiment of this application; Figure 7 is a schematic diagram of another application migration provided in an embodiment of this application; Figure 8 is a structural block diagram of a device control apparatus provided in an embodiment of this application. Implementation

[0012] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0013] Glossary:

[0014] Function: A collection of code snippets that perform a specific function; it is the main component of the code.

[0015] Function name: The name of the function, usually user-defined, and related to the specific functionality implemented by the function.

[0016] System call functions: A special type of function provided by the operating system. These functions provide an interface for accessing the operating system kernel, or in other words, accessing the operating system code.

[0017] System call file: A file containing a collection of system call functions.

[0018] System kernel: The underlying code that actually runs in the operating system. This code ensures the correct operation of the operating system and can only be accessed through system call functions.

[0019] Kernel driver functions are compiled code files that need to be installed into the operating system kernel for use, allowing direct interaction with hardware. Typically, kernel driver functions are responsible for communicating with hardware and managing hardware status. For example, kernel driver functions can read hardware data and control hardware on / off states. In this embodiment, the kernel driver functions mainly include a second driver function.

[0020] Library files are a collection of pre-written, reusable code files, which can be categorized into different library files based on their functions. In this embodiment, the library files mainly include a first driver library file and compatible library files.

[0021] Kernel Module: Also known as KO (Kernel Object) module, it is a code segment that can be dynamically loaded into the system kernel.

[0022] Kernel module file: also known as KO file, is a binary file compiled from the kernel module. In this embodiment, the kernel module file mainly includes a second driver module file. The second driver module file mainly includes second driver functions.

[0023] Docker is an open-source application container engine that allows developers to package their applications and dependencies into a portable container and then deploy the container to machines on other operating systems, enabling application migration.

[0024] Operating system system bit count: refers to the maximum length of data that the operating system can process, usually including 32 bits and 64 bits, such as 32-bit operating system and 64-bit operating system.

[0025] Taking the semiconductor manufacturing industry as an example, to maintain the stability of the production environment, many machines in the semiconductor manufacturing industry are still developed and run based on 32-bit hardware architecture and operating systems. However, 64-bit operating systems and hardware environments have now become mainstream. Therefore, many applications also need to be constantly updated and repeatedly run to keep up with the development of operating systems and hardware environments. Thus, 64-bit applications need continuous development. 64-bit applications are applications that can run directly on a 64-bit operating system.

[0026] Referring to Figure 1, a schematic diagram of an application program provided in an embodiment of this application is shown. The 64-bit host system is a 64-bit Linux system, and the 64-bit application is an application used to calculate the sum of temperatures of semiconductor devices. The 64-bit application contains a `Calculate()` function. When the 64-bit application runs, it first calls the `Open()` function in the 64-bit driver library file, which instructs the temperature sensor to be opened. The `Open()` function accesses the system kernel of the 64-bit operating system through the system call function `sys_open()` in the 64-bit system call file; then it calls the driver function `dr1.open()` in the kernel driver module file of the 64-bit operating system kernel. The `dr1.open()` function can directly operate the hardware device, truly realizing the function of opening the temperature sensor. Therefore, the call chain for applications to implement hardware access functionality in a Linux system is: 64-bit application - 64-bit driver library file - 64-bit system call file - 64-bit kernel driver module file - hardware. The kernel driver module file is also known as the second driver module file. In this example, everything from the application to the kernel driver module file runs on a 64-bit operating system.

[0027] To adapt to new operating systems, new 64-bit applications need to be continuously developed. Considering production and maintenance costs, older 32-bit applications also need to be maintained and used. One good solution for enabling older 32-bit applications to continue working on new operating systems is to use Docker technology to migrate them.

[0028] Docker is an open platform for developing, delivering, and running applications. It separates applications from infrastructure, enabling convenient and efficient deployment of 32-bit application runtime environments on 64-bit host machines, ensuring the stability of 32-bit applications running on 64-bit host machines. Specifically, 32-bit applications and operating systems can be packaged into a Docker image, and then this Docker image can be deployed to a 64-bit host machine. The 32-bit application runs directly within the Docker image, thus allowing for stable migration of 32-bit applications to 64-bit host machines without requiring modifications to the 32-bit application itself.

[0029] However, industrial applications, such as those in the semiconductor manufacturing industry, differ from ordinary applications. Ordinary applications, like internet applications, generally don't involve hardware control, making migration using Docker technology very convenient, and the migrated applications can run normally. In contrast, semiconductor manufacturing applications mostly need to interact with hardware through kernel driver functions, such as controlling the on / off state of temperature and humidity sensors, obtaining temperature and humidity data from these sensors, and controlling the process movements of robotic arms.

[0030] For applications in the semiconductor manufacturing industry, if Docker technology is used to migrate the applications directly, the migrated applications will have problems controlling the hardware properly.

[0031] Referring to Figure 2, a schematic diagram of application migration provided by an embodiment of this application is shown. A 32-bit application and a 32-bit driver library file are packaged to generate a 32-bit Docker image. The 32-bit Docker image is deployed on a 64-bit host system. When the 32-bit application runs, it first calls the 32-bit driver library file, which then calls the 64-bit system call file to control the hardware. However, the driver library file is written based on a 32-bit operating system and 32-bit hardware architecture, while the system call file is written based on a 64-bit operating system and 64-bit hardware architecture. Therefore, when the 32-bit driver library file calls the 64-bit system call file, it is a cross-architecture call process. In this cross-architecture call process, compatibility issues can easily arise, causing the 32-bit application to fail to implement hardware call functionality correctly in a 64-bit operating system.

[0032] In view of this problem, one of the core concepts of the embodiments of this application is to add 32-bit compatible library files to a 32-bit Docker image and deploy 32-bit system call files on a 64-bit host system. This allows the 32-bit application in the 32-bit Docker image to first call the 32-bit driver library file, then call the 32-bit compatible library file through the 32-bit driver library file, then call the 32-bit system call file through the 32-bit compatible library file, and finally access the system kernel of the 64-bit host system through the 32-bit system call file, thereby controlling the hardware through the system kernel.

[0033] Because there are significant differences between 32-bit and 64-bit system call files, calling a 64-bit system call file using a 32-bit driver library file, as shown in Figure 2, is more prone to call failures. However, the system kernel is more powerful and can effectively accommodate both 64-bit and 32-bit code. Therefore, this embodiment uses a 32-bit compatible library file to call a 32-bit system call file, and accesses the 64-bit host system kernel through the 32-bit system call file to control the hardware. This reduces compatibility issues and allows 32-bit applications to more smoothly implement hardware call functions on a 64-bit host. Furthermore, writing a compatible library file based on a 32-bit operating system and placing it in a Docker image avoids the library file's impact on the 64-bit host.

[0034] Referring to Figure 3, a flowchart of the steps of a device control method provided in an embodiment of this application is shown. The device is equipped with a first operating system, and the method may specifically include the following steps:

[0035] Step S101: Obtain the target image, the compiled file, and the system call file of the second operating system; wherein, the target image includes a target application running on the second operating system, a first driver library file, and a compatible library file; the first driver library file includes at least one first driver function, which is used to call system call functions through the compatible library file; the compatible library file includes a mapping relationship between the first driver function and the system call function; the system call file includes at least one system call function; the system call function is used to call the hardware of the device; the compiled file is used to compile and link the target application, the first driver library file, and the compatible library file.

[0036] The first operating system and the second operating system are two different operating systems, with the first operating system having a larger number of system bits than the second operating system. Specifically, the first operating system can be a 64-bit operating system, and the second operating system can be a 32-bit operating system.

[0037] The target image can be a Docker image that packages the target application, the first driver library file, and the compatible library files.

[0038] The target application can be a program with hardware access capabilities. Through the target application, it is possible to access the target hardware.

[0039] The first driver library file can be a library file used to drive the target hardware. The first driver library file cannot directly drive the target hardware; instead, it calls system call files, which in turn access the system kernel, and the kernel then drives the target hardware. The first driver library file can be provided by the hardware vendor of the target hardware. The first driver library file can include first driver functions for implementing basic functions such as initialization, opening, reading, and writing. Different first driver functions can call corresponding system call functions.

[0040] The compatibility library file can be a file written by the R&D personnel. The compatibility library file can include the mapping relationship between the first driver function and the system call function. So when the target application calls the target first driver function in the first driver library file, it can find the system call file of the second operating system through the compatibility library file, determine the target system call function corresponding to the target first driver function from the system call file of the second operating system, and call the target system call function.

[0041] Each host machine comes with its own system call file; specifically, a 32-bit host machine will have its own 32-bit system call file. Therefore, the system call file for the second operating system can be obtained from the host machine where the second operating system is deployed. The system call file is used to respond to calls from compatible library files and access the system kernel. The system call file contains system call functions. When a compatible library file calls a target system call function in the system call file, the target system call function accesses the system kernel and uses the system kernel to drive the target hardware.

[0042] The compilation file is used to specify the target application, the first driver library file, and the compatible library files for compilation and linking.

[0043] The target application, first driver library file, compatibility library file, and system call file in this application embodiment are all based on or written on a second operating system. This application can be used to migrate a target application running on a second operating system to a first operating system.

[0044] Step S102: Deploy system call files in the first operating system, and compile the target application, the first driver library file, and the compatible library file in the target image according to the compilation file in the first operating system.

[0045] Since the compatibility library file is a newly added library file, it is necessary to link and compile the target application, the first driver library file, and the compatibility library file in the target image through the compilation file so that the target application calls the first driver library file at runtime, and the first driver library file calls the compatibility library file.

[0046] Step S103: Run the target application in the target image on the first operating system to determine the target first driver function of the corresponding target application, determine the target system call function according to the target first driver function and the mapping relationship, and call the hardware of the device according to the target system call function.

[0047] Since the target image can be a Docker image, and a Docker image provides a suitable runtime environment for the target application, the target application can be packaged into a target image, its runtime environment deployed within that image, and then the target image deployed on the primary operating system. In this case, the target application will run normally within the target image on the primary operating system. For example, if the target application is a 32-bit Red Hat operating system, and the primary operating system is a 64-bit CentOS operating system, then the 32-bit Red Hat operating system and the target application can be packaged together into a Docker image. This Docker image can then be deployed on the 64-bit CentOS operating system, allowing the target application to run within the Docker image on the 64-bit CentOS operating system.

[0048] After the system call file is deployed and the target image is compiled, the target application in the target image can be run on the first operating system, so that the target application calls the target first driver function in the first driver library file; the target first driver function calls the compatible library file; the compatible library file determines the target system call function corresponding to the target first driver function from the system call file of the second operating system, and calls the target system call function; the target system call function accesses the system kernel of the first operating system and implements hardware call function through the system kernel.

[0049] In this embodiment, the target application running on the second operating system, the first driver library file written based on the second operating system, and the compatible library file are packaged into a target image. The target image is then deployed on the first operating system. The target application, the first driver library file, and the compatible library file in the target image are compiled according to pre-compiled compilation files, enabling the target application to run on the target image of the first operating system. During runtime, the target application can call the target first driver function in the first driver library file, and the target first driver function calls the compatible library file. Furthermore, the system call file of the second operating system is deployed on the first operating system. Thus, when the target first driver function calls the compatible library file, the compatible library file can find the system call file of the second operating system on the first operating system and determine the target system call function from the system call file of the second operating system. Finally, the target system call function accesses the system kernel of the first operating system, and the hardware call function is implemented through the system kernel.

[0050] In this embodiment, since the target application, the first driver library file, the compatibility library file, and the system call file are all based on or written for the second operating system, there are no compatibility issues when these four components call each other. When the system call file of the second operating system accesses the system kernel of the first operating system, because the system kernel is more powerful and has better code compatibility with different operating systems, the system call file of the second operating system can also successfully access the kernel of the first operating system, thereby implementing hardware call functionality through the system kernel of the first operating system. During the hardware call process of the target application, the target application (second operating system), the first driver library file (second operating system), the compatibility library file (second operating system), the system call file (second operating system), and the system kernel (first operating system) form a complete closed loop, and they can successfully call each other to collaboratively implement hardware calls.

[0051] Furthermore, in this embodiment, the compatible library files are packaged into the target image and then the target image is deployed on the first operating system, instead of directly deploying the compatible library files on the first operating system, which can reduce the impact of the compatible library files on the first operating system.

[0052] In one embodiment, the system kernel of the first operating system includes a second driver module file, which includes at least one second driver function for calling the hardware of the device. Step S103, which calls the hardware of the device according to the target system call function, may specifically include: accessing the system kernel through the target system call function and determining the target second driver function from the second driver module file in the system kernel; and calling the hardware of the device through the target second driver function.

[0053] The second driver module file is a KO file deployed in the system kernel of the first operating system, used to drive the hardware. The second driver module file includes at least one second driver function, which can directly drive the hardware. Therefore, when the compatible library file calls the target system call function, the target system call function can access the system kernel of the first operating system, find the target second driver function in the second driver module file within the system kernel, and then use the target second driver function to call the hardware.

[0054] Referring to Figure 4, an architecture diagram provided by an embodiment of this application is shown. A 32-bit Docker image and a 32-bit system call file are deployed on a 64-bit Linux system. The 32-bit Docker image includes a 32-bit application, a 32-bit driver library file, and a 32-bit compatible library file. Since the 32-bit Docker image provides a runtime environment for the 32-bit application, the 32-bit driver library file, and the 32-bit compatible library file to run 32-bit code, the 32-bit application can run within the 32-bit Docker image on the 64-bit Linux system. When the 32-bit application runs, it calls the 32-bit driver library file, which in turn calls the 32-bit compatible library file. The 32-bit compatible library file then calls the 32-bit system call file, which in turn calls the driver functions in the 64-bit Linux kernel to access hardware such as Hardware 1, Hardware 2, and Hardware 3.

[0055] Referring to Figure 5, a flowchart of a device control method provided in an embodiment of this application is shown. The 64-bit host system is a 64-bit Linux system, and the 32-bit application is an application used to calculate the sum of the temperatures of the temperature sensors. The 32-bit application contains a `Calculate()` function. When the 32-bit application runs, it first calls the `Open()` function in the 32-bit driver library file, which instructs the temperature sensor to be opened. The `Open()` function calls the system call function `sys_open()` in the 32-bit system call file to access the system kernel of the 64-bit operating system. Then, it calls the kernel driver function `dr1.open()` in the 64-bit operating system kernel. The `dr1.open()` function can directly operate the hardware device, truly realizing the function of opening the temperature sensor. The process of obtaining the temperature sensor's temperature and calculating the sum of the temperatures after opening the temperature sensor will not be described in detail here.

[0056] Referring to Figure 6, a flowchart of another device control method provided in this application embodiment is shown. The compatibility library file may further include a call chain detection program. The call chain is the call relationship of each node during the process of the target application calling the device hardware. The nodes include the target application, the first driver library file, the compatibility library file, the system call file, and the second driver module file. Therefore, before compiling the target application, the first driver library file, and the compatibility library file in the target image, the device control method may further include: Step S11: Detect the call chain using a call chain detection program. Step S12: Obtain call chain detection information; the call chain detection information includes information indicating that the call chain is running normally or information indicating that the call chain is running incorrectly.

[0057] The call chain detection program can check whether each node can correctly call according to the set call chain when the target application runs. If the call chain detection information indicates that the call chain is running normally, the target application, the first driver library file, and the compatible library files in the target image can be compiled and then the target application can be run. If the call chain detection information indicates that the call chain is running incorrectly, the code in the erroneous part can be manually modified. The call chain detection program can ensure that the call chain is error-free when the target application runs.

[0058] In one embodiment, the first driver function has a function name, and the compatible library file includes a third driver function with the same function name as the first driver function. The information indicating a call chain execution error includes information indicating a first driver function execution error in the first driver library file. The device control method further includes: when the information indicating a call chain execution error is information indicating a first driver function execution error in the first driver library file, determining a target third driver function with the same function name as the first driver function that reported the error from the compatible library file, and replacing the first driver function that reported the error in the first driver library file with the target third driver function.

[0059] The compatibility library file can store a third driver function, which has the same name as the first driver function. The first and third driver functions with the same name have the same functionality, but the specific code implementing that functionality differs. The third driver function can be a driver function written by the developers.

[0060] When the error message indicating a call chain execution error is the error message indicating that the first driver function A in the first driver library file is running, the compatible library file can identify the target third driver function with the same function name as the first driver function A, and replace the first driver function A in the first driver library file with the target third driver function. Thus, after the replacement, if the target application calls the first driver function A, the compatible library file can determine the target system call file based on the first driver function A and correctly call the target system call file.

[0061] In one embodiment, compiling the target application, the first driver library file, and the compatible library file in the target image according to the compilation file includes: when the call chain detection information indicates that the call chain is running normally, compiling the target application, the first driver library file, and the compatible library file in the target image according to the compilation file. After the call chain detection is completed and the call chain detection information indicates that the call chain is running normally, compiling the target application, the first driver library file, and the compatible library file in the target image is performed again.

[0062] In one embodiment, the target image further includes a second operating system; running the target application includes running the target application within the second operating system in the target image. The second operating system required for the target application to run can also be packaged into the target image so that the target application can run normally within the target image.

[0063] In one embodiment, the device control method further includes: obtaining a third-party component from a third-party platform; the third-party component is a component invoked by the target application during runtime; and packaging the third-party component into the target image. The target application may also need to invoke the third-party component during runtime; in this case, the third-party component can also be packaged into the target image.

[0064] Referring to Figure 7, another application migration schematic diagram provided in this application embodiment is shown. The application is a 32-bit cleaning application deployed on a 32-bit operating system in the semiconductor manufacturing industry. The 32-bit cleaning application needs to be migrated to a 64-bit operating system. The migration process specifically includes the following steps: Step S201: Package the 32-bit cleaning application and its runtime environment into a Docker image. A Docker image is generated by packaging a 32-bit operating system and a 32-bit cleaning application using Docker commands. Step S202: Add the third-party components to the Docker image.

[0065] If the Docker image generated by the Docker command is missing components required for the 32-bit clean application to run, such as third-party components (e.g., third-party libraries, third-party web intermediary software), these third-party components can be pulled from the third-party platform using the Docker Pull method and added to the Docker image.

[0066] Step S203: Add the 32-bit first driver library file to the Docker image.

[0067] The first driver library file of the 32-bit cleaning application can be obtained and added to the Docker image. The first driver library file is used within the Docker image and called by the 32-bit cleaning application; therefore, the first driver library file is a 32-bit first driver library file.

[0068] Step S204: Add the 32-bit compatible library file to the Docker image.

[0069] The 32-bit compatible library file mainly includes functions such as interface redirection, call chain detection, and general interface rewriting.

[0070] Interface redirection refers to the process where, when a 32-bit cleaning application calls a target first driver function in a 32-bit first driver library file, the compatible library file can automatically locate the 32-bit system call file in the 64-bit operating system and find the target system call function corresponding to the target first driver function from the 32-bit system call file.

[0071] Call chain inspection refers to checking the call chain from the 32-bit clean application to the 32-bit first driver library file, 32-bit compatible library file, 32-bit system call file, and finally the 64-bit kernel driver module file using pre-compilation methods. Only when the call relationships between nodes in the call chain are correct can the code from different nodes cooperate and run correctly. After the inspection is complete, call chain inspection information can be obtained. This information includes either information indicating that the call chain is running normally or information indicating that the call chain is running incorrectly. Information indicating that the call chain is running incorrectly can specifically include node error messages.

[0072] Generic interface rewriting refers to modifying or replacing a first-level call chain error message with a third-level call chain function from a compatible library if the error message indicates an error in the first call chain. The function name is the same, but the code can be different. Therefore, if the vendor-provided first-level call chain function is faulty, a third-level call chain function from a compatible library can be used as a replacement.

[0073] Step S205: Add a 32-bit system call file to the 64-bit host system kernel.

[0074] Step S206: Generate the compiled file.

[0075] The compilation file is used to specify which code is compiled together with the application code, mainly specifying the required library files to be compiled and linked together with the application code.

[0076] Step S207: Generate a 32-bit executable file in the Docker image.

[0077] Step S208: Run the 32-bit executable file.

[0078] 32-bit executables access the 64-bit host machine's system kernel through 32-bit system call functions, call kernel driver functions, and control the hardware.

[0079] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0080] Referring to Figure 8, a structural block diagram of a device control apparatus according to an embodiment of this application is shown. The apparatus includes: a processor and a memory, wherein the memory stores a computer program, and when the processor executes the computer program, it performs:

[0081] The system obtains a target image, a compiled file, and a system call file for a second operating system. The target image includes a target application running on the second operating system, a first driver library file, and a compatible library file. The first driver library file includes at least one first driver function, which is used to call system call functions through the compatible library file. The compatible library file includes a mapping relationship between the first driver function and the system call functions. The system call file includes at least one system call function, which is used to invoke the device's hardware. The compiled file is used to compile and link the target application, the first driver library file, and the compatible library file.

[0082] Deploy system call files in the first operating system, and compile the target application, first driver library file, and compatible library file in the target image according to the compilation file in the first operating system; The target application in the target image is run on the first operating system to determine the target first driver function corresponding to the target application. The target system call function is determined based on the target first driver function and the mapping relationship. The hardware of the device is invoked based on the target system call function.

[0083] In some embodiments, the first operating system includes a system kernel, the system kernel includes a second driver module file, the second driver module file includes at least one second driver function, the second driver function is used to call the hardware of the device; when the processor executes a computer program, it performs the following: accessing the system kernel through a target system call function, and determining a target second driver function from the second driver module file in the system kernel; and calling the hardware of the device through the target second driver function.

[0084] In some embodiments, the compatibility library file further includes a call chain detection program. The call chain is the call relationship of each node in the process of the target application calling the hardware of the device. The nodes include the target application, the first driver library file, the compatibility library file, the system call file, and the second driver module file. When the processor executes the computer program, it performs the following: before compiling the target application, the first driver library file, and the compatibility library file in the target image, it detects the call chain through the call chain detection program; it obtains call chain detection information; the call chain detection information includes information indicating that the call chain is running normally or information indicating that the call chain is running incorrectly.

[0085] In some embodiments, the first driver function has a function name, and the compatible library file includes a third driver function with the same function name as the first driver function. The information indicating a call chain execution error includes information indicating a first driver function execution error in the first driver library file. When the processor executes the computer program, it performs the following: when the information indicating a call chain execution error is information indicating a first driver function execution error in the first driver library file, it determines a target third driver function with the same function name as the first driver function that reported the error from the compatible library file, and replaces the first driver function that reported the error in the first driver library file with the target third driver function.

[0086] In some embodiments, when the processor executes a computer program, it performs the following: when the call chain detection information indicates that the call chain is running normally, it compiles the target application, the first driver library file, and the compatible library file in the target image according to the compilation file.

[0087] In some embodiments, the target image further includes a second operating system; when the processor executes a computer program, it executes: run the target application in the second operating system in the target image.

[0088] In some embodiments, when the processor executes a computer program, it performs the following: obtaining a third-party component from a third-party platform; the third-party component is a component called by the target application at runtime; and packaging the third-party component into the target image.

[0089] In some embodiments, the first operating system is a 64-bit operating system; the second operating system is a 32-bit operating system.

[0090] As the device embodiment is basically similar to the method embodiment, the description is relatively simple. For relevant details, please refer to the description of the method embodiment.

[0091] This application also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described device control method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0092] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0093] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk memory, CD-ROM, optical memory, etc.) containing computer-usable program code.

[0094] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0095] These computer program instructions may also be stored in computer-readable memory that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0096] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device to cause a series of operational steps to be performed on the computer or other programmable terminal device to produce computer-implemented processing, thereby providing steps for implementing the functions specified in one or more flowcharts and / or one or more blocks of a block diagram.

[0097] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0098] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes the element.

[0099] The above provides a detailed description of a device control method, apparatus, and storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

[0100] S11, S12, S101, S102, S103, S201, S202, S203, S204, S205, S206, S207, S208: Steps

Claims

1. A device control method, wherein, The device is deployed with a first operating system. The method includes: acquiring a target image, a compiled file, and a system call file of a second operating system; wherein the target image includes a target application running on the second operating system, a first driver library file, and a compatible library file; the first driver library file includes at least one first driver function, which is used to call a system call function through the compatible library file; the compatible library file includes a mapping relationship between the first driver function and the system call function; the system call file includes at least one system call function; the system call function is used to call the hardware of the device; the compiled file is used to compile and link the target application, the first driver library file, and the compatible library file; deploying the system call file in the first operating system, and compiling the target application, the first driver library file, and the compatible library file in the target image according to the compiled file in the first operating system to determine the calling relationship of each node, and causing the target application to call the first driver library file at runtime, and the first driver library file calling the compatible library file; The target application in the target image is run on the first operating system to determine the target first driver function corresponding to the target application. The target system call function is determined by the compatible library file based on the target first driver function and the mapping relationship. The system kernel of the first operating system is accessed according to the target system call function to call the hardware of the device.

2. The device control method as described in claim 1, wherein, The system kernel includes a second driver module file, which includes at least one second driver function for calling the hardware of the device; The method of accessing the system kernel of the first operating system to invoke the hardware of the device according to the target system call function includes: determining the target second driver function from the second driver module file in the system kernel; The device's hardware is invoked through the target's second driver function.

3. The device control method as described in claim 2, wherein, The compatibility library file also includes a call chain detection program. The call chain is the call relationship of each node during the process of the target application calling the hardware of the device. The node includes the target application, the first driver library file, the compatibility library file, the system call file, and the second driver module file. The method further includes: detecting the call chain using the call chain detection program before compiling the target application, the first driver library file, and the compatibility library file in the target image; obtaining the call chain detection information; the call chain detection information includes information indicating that the call chain is running normally or information indicating that the call chain is running incorrectly.

4. The device control method as described in claim 3, wherein, The first driver function has a function name, and the compatible library file includes a third driver function with the same function name as the first driver function. The information indicating the call chain execution error includes information indicating the first driver function in the first driver library file is running incorrectly. The method further includes: when the information indicating the call chain execution error is information indicating the first driver function in the first driver library file is running incorrectly, determining a target third driver function with the same function name as the first driver function that reported the error from the compatible library file, and replacing the first driver function that reported the error in the first driver library file with the target third driver function.

5. The device control method as described in claim 3, wherein, The compiler compiles the target application, the first driver library file, and the compatible library file in the target image according to the compiler file, including: when the call chain detection information is information indicating that the call chain is running normally, the compiler compiles the target application, the first driver library file, and the compatible library file in the target image according to the compiler file.

6. The device control method as described in claim 1, wherein, The target image also includes the second operating system; Running the target application includes: running the target application in the second operating system within the target image.

7. The device control method as described in claim 1, wherein, The method further includes: obtaining a third-party component from a third-party platform; the third-party component being a component invoked at runtime by the target application; and packaging the third-party component into the target image.

8. The device control method as described in claim 1, wherein, The first operating system is a 64-bit operating system; the second operating system is a 32-bit operating system.

9. A device for controlling an equipment, wherein, include: A processor and memory, the memory storing a computer program, wherein when the processor executes the computer program, it performs the steps of the device control method described in any one of claims 1-8.

10. A computer-readable storage medium, wherein, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the device control method as described in any one of claims 1-8.

Images