Device control method and apparatus, and storage medium

Abstract

Provided in the present disclosure are a device control method and apparatus, and a storage medium. The method comprises: acquiring a target mirror image and a system call file of a second operating system, wherein the target mirror image comprises a target application program that runs on the basis of the second operating system, a first driver library file and a compatibility library file; deploying the target mirror image and the system call file in a first operating system; and running the target application program, such that the target application program calls a target first driver function in the first driver library file, determining a target system call function from the system call file by means of the compatibility library file on the basis of the target first driver function, and calling hardware of a device by means of the target system call function. In the embodiments of the present application, after a target application program is migrated to a first operating system, a hardware call function of a device is implemented by means of a system call file of a second operating system, so that the reliability of the target application program running on the first operating system can be improved.

Description

Device control method, device and storage medium TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and particularly relates to a device control method, device and storage medium. BACKGROUND

[0002] In an industrial scene, in order to obtain higher performance and more special peripheral devices to participate in industrial manufacturing, a business system is more developed by using C and C++ languages, so the business system needs to be compiled and deployed on a specific computer architecture and operating system.

[0003] With the development of computer software and hardware technologies, the computer architecture and operating system are upgraded and changed rapidly. In order to ensure the reliability of the business system and reduce the development cost, it is a more reasonable choice to smoothly migrate the original business system under the new architecture and the new operating system instead of developing a new business system.

[0004] For the migration of the business system, the original business system can be packaged as a Docker image, and then the Docker image is deployed to the new architecture and the new operating system, so that the original business system can run in the new architecture and the new operating system. However, if the original business system contains a hardware calling function, after the business system is migrated according to the above method, the business system needs to call a system call file of the new operating system, access a system kernel of the new operating system through the system call file of the new operating system, and realize the hardware calling function through a driver function in the system kernel. However, in this series of calling processes, there is a compatibility problem caused by cross-architecture, which leads to the failure to normally call the hardware. SUMMARY

[0005] In view of the above problems, the present application is proposed to provide a device control method, device and storage medium which can overcome the above problems or at least partially solve the above problems.

[0006] In a first aspect, the present application discloses a device control method, wherein a first operating system is deployed in the device, and the method comprises the following steps.

[0007] obtain a target image, a compiling file and a system call file of a second operating system; wherein the target image comprises a target application program, a first driver library file and a compatible library file based on the second operating system; the first driver library file comprises at least one first driver function, the first driver function is used to call a system call function through the compatible library file; the compatible library file comprises a mapping relationship between the first driver function and the system call function; the system call file comprises at least one system call function; the system call function is used to call hardware of the device; the compiling file is used to compile and link the target application program, the first driver library file and the compatible library file;

[0008] deploy the system call file in the first operating system, and compile the target application program, the first driver library file and the compatible library file in the target image according to the compiling file in the first operating system;

[0009] run the target application program in the target image on the first operating system, determine a target first driver function corresponding to the target application program, determine a 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.

[0010] In a second aspect, the embodiments of the present application disclose a device control apparatus, comprising a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to perform the steps of the device control method.

[0011] In a third aspect, the embodiments of the present application disclose a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program is executed by a processor to perform the steps of the device control method.

[0012] The embodiments of the present application have the following advantages:

[0013] When migrating a target application program on a second operating system to a first operating system, a target image, a compiling file and a system call file of the second operating system can be obtained first, wherein the target image comprises the target application program, a first driver library file and a compatible library file. Then, the system call file of the second operating system is deployed on the first operating system, and the target application program, the first driver library file and the compatible library file in the target image are compiled according to the compiling file on the first operating system, and the purpose of the compilation is to enable the target application program to successfully call the first driver library file and the compatible library file through the first driver library file when running.

[0014] 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 first driver library file, the first driver library file calls the compatible library file, the compatible library file calls the system call file of the second operating system deployed on the first system, the system call file of the second operating system accesses the system kernel of the first operating system, and the hardware calling function is realized through the driver function in the system kernel. Since the target application, the first driver library file, the compatible library file and the system call file are all run or written based on the second operating system, there is no compatibility problem when the four are called. Since the system kernel has more powerful functions and better code compatibility for different operating systems, accessing the system kernel of the first operating system through the system call file of the second operating system to realize the hardware calling function can reduce compatibility problems and make the hardware calling more smooth. BRIEF DESCRIPTION OF DRAWINGS

[0015] Fig. 1 is a schematic diagram of an application program running provided by an embodiment of the present application;

[0016] Fig. 2 is a schematic diagram of application program migration provided by an embodiment of the present application;

[0017] Fig. 3 is a step flowchart of a device control method provided by an embodiment of the present application;

[0018] Fig. 4 is an architectural diagram provided by an embodiment of the present application;

[0019] Fig. 5 is a flowchart of a device control method provided by an embodiment of the present application;

[0020] Fig. 6 is a step flowchart of another device control method provided by an embodiment of the present application;

[0021] Fig. 7 is another schematic diagram of application program migration provided by an embodiment of the present application;

[0022] Fig. 8 is a structural block diagram of a device control apparatus provided by an embodiment of the present application. DETAILED DESCRIPTION

[0023] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the present application will be further described in detail below with reference to the drawings and specific embodiments.

[0024] Glossary:

[0025] Function: a collection of code segments that implement a certain function, which is the main component of the code.

[0026] Function name: the name of the function, which is usually customized and related to the function implemented by the specific function.

[0027] System call function: a special function provided by the operating system, which provides an interface to access the operating system kernel, or the operating system code.

[0028] System call file: a collection file of system call functions.

[0029] System kernel: the underlying code actually running in the operating system, which ensures the correct operation of the operating system, and the kernel code can only be accessed through system call functions.

[0030] Kernel driver function: a code compiled into a file that needs to be installed in the operating system kernel for use, which can directly interact with hardware. Usually, the kernel driver function can be responsible for communicating with hardware, managing hardware status, etc. For example, the kernel driver function can read hardware data and control the switch of hardware. In the embodiments of the present application, the kernel driver function mainly includes the second driver function.

[0031] Library file: a collection of code files that have been written and can be called repeatedly, which can be divided into different library files according to different functions. In the embodiments of the present application, the library file mainly includes the first driver library file and the compatible library file.

[0032] Kernel module: KO (Kernel Object) module, which is a code fragment that can be dynamically loaded into the system kernel.

[0033] Kernel module file: KO file, which is a binary file after the kernel module is compiled. In the embodiments of the present application, the kernel module file mainly includes the second driver module file. The second driver module file mainly includes the second driver function.

[0034] Docker: an open source application container engine that allows developers to package their applications and dependent packages into a portable container, and then publish the container to other operating system machines to realize the migration of the application.

[0035] System bit number of the operating system: refers to the maximum length of data that the operating system can process, usually including 32-bit and 64-bit, such as 32-bit operating system and 64-bit operating system.

[0036] Taking the semiconductor manufacturing industry as an example, in the semiconductor manufacturing industry, in order to maintain the stability of the production environment, many machines are still developed and run based on 32-bit hardware architecture and operating system, however, nowadays, 64-bit operating system and hardware environment have become mainstream, therefore, many application programs also need to be updated and iterated with the development of operating system and hardware environment. Therefore, 64-bit application programs need to be continuously developed. The 64-bit application program is an application program that can run directly on a 64-bit operating system.

[0037] Referring to FIG. 1, an application program running schematic diagram provided by an embodiment of the present application is shown. The 64-bit host system is a 64-bit Linux system, and the 64-bit application program is an application program for calculating the sum of semiconductor device temperatures. The Calculate() function is written in the 64-bit application program, when the 64-bit application program runs, the 64-bit application program will first call the Open() function in the 64-bit driver library file, which is used to indicate opening the temperature sensor; the Open() function accesses the system kernel of the 64-bit operating system through the system call function sys_open() function in the 64-bit system call file; then calls the driver function dr1.open() in the kernel driver module file in the 64-bit operating system kernel; the dr1.open() function can directly operate the hardware device, and truly realizes the function of opening the temperature sensor. Therefore, the calling chain of the application program in the Linux system to realize the hardware calling function is 64-bit application program-64-bit driver library file-64-bit system call file-64-bit kernel driver module file-hardware, and the kernel driver module file is also the second driver module file. In this example, from the application program to the kernel driver module file, they are all run based on the 64-bit operating system.

[0038] In order to adapt to the new operating system, new 64-bit application programs need to be continuously developed, considering the production cost and maintenance cost, old 32-bit application programs also need to be continuously maintained and used. How to make the old 32-bit application program continue to be used on the new operating system, and migrate the old 32-bit application program to the new operating system through the Docker technology is a good solution.

[0039] Docker is an open platform for developing, delivering and running applications, which can separate applications from infrastructure, and can facilitate and efficiently deploy a running environment of 32-bit application on a 64-bit host computer, and ensure the stability of running 32-bit application on a 64-bit host computer. Specifically, a 32-bit application and an operating system can be packaged into a Docker image, and the Docker image is deployed on a 64-bit host computer for running, and the 32-bit application directly runs in the Docker image, so that the 32-bit application can be stably migrated to a 64-bit host computer for running without modifying the 32-bit application.

[0040] However, the application programs in the industrial scenarios such as the semiconductor manufacturing industry are different from the ordinary application programs. The ordinary application programs, such as the Internet application programs, basically do not involve the control operation on the hardware, so it is very convenient to migrate the application programs based on the Docker technology, and the migrated application programs can also normally run. However, the application programs in the semiconductor manufacturing industry mostly need to interact with the hardware through the kernel driver function, such as controlling the opening and closing of the temperature and humidity sensor, obtaining the temperature and humidity data of the temperature and humidity sensor, controlling the process action of the mechanical hand, etc.

[0041] For the application programs in the semiconductor manufacturing industry, if the Docker technology is directly used to migrate the application programs, the migrated application programs will have the problem of being unable to normally control the hardware.

[0042] Referring to FIG. 2, an application program migration schematic diagram provided by an embodiment of the present application is shown. A 32-bit application program and a 32-bit driver library file are packaged to generate a 32-bit Docker image. The 32-bit Docker image is deployed in a 64-bit host computer system. When the 32-bit application program runs, the 32-bit application program needs to first call the 32-bit driver library file, call the 64-bit system call file through the 32-bit driver library file, and then realize the control of the hardware through the 64-bit system call file. Among them, the driver library file is a file written based on the 32-bit operating system and the 32-bit hardware architecture, and the system call file is a file written based on the 64-bit operating system and the 64-bit hardware architecture, so when the 32-bit driver library file calls the 64-bit system call file, it is a cross-architecture calling process. In the cross-architecture calling process, compatibility problems are prone to occur, which causes the 32-bit application program to be unable to normally realize the hardware calling function in the 64-bit operating system.

[0043] In view of the problem, one of the core ideas of the embodiments of the present application is to add a 32-bit compatible library file in a 32-bit Docker image, and deploy a 32-bit system call file in a 64-bit host system, so that when a 32-bit application in the 32-bit Docker image runs, the 32-bit application first calls a 32-bit driver library file, calls a 32-bit compatible library file through the 32-bit driver library file, calls a 32-bit system call file through the 32-bit compatible library file, and then accesses a system kernel of the 64-bit host system through the 32-bit system call file to control hardware through the system kernel.

[0044] Because there is a big difference between the 32-bit system call file and the 64-bit system call file, the 32-bit driver library file in FIG. 2 is more likely to fail to call the 64-bit system call file. The system kernel is more powerful and can well compatible 64-bit code and 32-bit code, so the embodiments of the present application call the 32-bit system call file through the 32-bit compatible library file, access the system kernel of the 64-bit host system through the 32-bit system call file to control hardware through the system kernel, which can reduce compatibility problems and make the 32-bit application more smoothly realize the hardware calling function on the 64-bit host. In this process, the compatible library file is written based on the 32-bit operating system and placed in the Docker image, which can avoid the influence of the compatible library file on the 64-bit host.

[0045] Referring to FIG. 3, a step flowchart of a device control method provided by the embodiments of the present application is shown, and the device is deployed with a first operating system. The method can specifically include the following steps:

[0046] Step S101, obtaining a target image, a compilation file and a system call file of a second operating system; wherein the target image includes a target application running based 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, and the first driver function 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 hardware of the device; and the compilation file is used to compile and link the target application, the first driver library file and the compatible library file.

[0047] The first operating system and the second operating system are two different operating systems, and the system bit number of the first operating system is greater than the system bit number of 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.

[0048] The target image can be a Docker image packaged with the target application program, the first driver library file, and the compatible library file.

[0049] The target application program can be a program with a hardware calling function. The target hardware can be called through the target application program.

[0050] The first driver library file can be a library file for implementing driving of the target hardware. The first driver library file cannot directly drive the target hardware, but drives the target hardware through a system call file, accesses a system kernel through the system call file, and then drives the target hardware through the system kernel. The first driver library file can be provided by a hardware supplier of the target hardware. The first driver library file can include a first driver function for implementing initialization, opening, reading and writing, and the like. The first driver functions of different functions can call system call functions of corresponding functions, respectively.

[0051] The compatible library file can be a file written by a developer. The compatible library file can include a mapping relationship between the first driver function and the system call function. When the target application program calls a target first driver function in the first driver library file, the compatible library file can be used to find a system call file of a second operating system, determine a 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.

[0052] Each host computer can have a system call file, i.e., a 32-bit host computer can have a 32-bit system call file. Therefore, the system call file of the second operating system can be obtained from a host computer on which the second operating system is deployed. The system call file is used to access a system kernel in response to a call of the compatible library file. The system call file includes a system call function. When the compatible library file calls a target system call function in the system call file, the target system call function accesses the system kernel, and drives the target hardware through the system kernel.

[0053] The compiling file is used to specify the target application program, the first driver library file, and the compatible library file for compiling and linking.

[0054] The target application program, the first driver library file, the compatible library file, and the system call file in the embodiments of the present application are all based on the second operating system and are run or written. The application scenario of the present application can be a scenario of migrating a target application program running on the second operating system to the first operating system.

[0055] In step S102, a system call file is deployed in the first operating system, and a target application program, a first driver library file, and a compatible library file in a target image are compiled according to a compiling file in the first operating system.

[0056] Since the compatible library file is a newly added library file, the target application in the target image, the first driving library file and the compatible library file need to be linked and compiled by the compiling file, so that the target application calls the first driving library file at runtime, and the first driving library file calls the compatible library file.

[0057] In step S103, the target application in the target image is run on the first operating system to determine the target first driving function corresponding to the target application, the target system call function is determined according to the target first driving function and the mapping relationship, and the hardware of the device is called according to the target system call function.

[0058] Since the target image can be a Docker image, the Docker image can provide a running environment suitable for the target application. Therefore, the target application is packaged into the target image, the running environment of the target application is deployed in the target image, and finally the target image is deployed on the first operating system, so that the target application can run normally in the target image on the first operating system. For example, the target application is an application running on a 32-bit Redhat operating system, and the first operating system is a 64-bit CentOS operating system. The 32-bit Redhat operating system and the target application can be packaged into a Docker image together, and the Docker image is deployed on the 64-bit CentOS operating system, so that the target application can run in the Docker image on the 64-bit CentOS operating system.

[0059] 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 driving function in the first driving library file; the target first driving function calls the compatible library file; the compatible library file determines the target system call function corresponding to the target first driving function from the system call file of the second operating system, and calls the target system call function; and the target system call function accesses the system kernel of the first operating system to realize the hardware calling function through the system kernel.

[0060] The embodiment of the present application packs the target application program running on the second operating system, the first drive library file written based on the second operating system and the compatible library file into the target image, deploys the target image on the first operating system, and compiles the target application program, the first drive library file and the compatible library file in the target image according to the precompiled compiling file, so that the target application program can run in the target image of the first operating system, and the target application program can call the target first drive function in the first drive library file when running, and the target first drive function calls the compatible library file. Further, the system call file of the second operating system is also deployed on the first operating system, so that when the target first drive 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 system kernel realizes the hardware calling function.

[0061] In the embodiment of the present application, the target application program, the first drive library file, the compatible library file and the system call file are all based on the second operating system, so when they call each other, there is no compatibility problem. When the system call file of the second operating system accesses the system kernel of the first operating system, the system kernel has more powerful functions and better compatibility with the code of different operating systems, so the system call file of the second operating system can also access the kernel of the first operating system to realize the hardware calling function through the system kernel of the first operating system. In the process of hardware calling of the target application program, the target application program (second operating system), the first drive library file (second operating system), the compatible library file (second operating system), the system call file (second operating system) and the system kernel (first operating system) realize a complete closed loop, and can call each other to cooperatively call the hardware.

[0062] In addition, the embodiment of the present application packs the compatible library file into the target image, and then deploys the target image on the first operating system, instead of directly deploying the compatible library file on the first operating system, which can reduce the influence of the compatible library file on the first operating system.

[0063] In one embodiment, the system kernel of the first operating system includes a second drive module file, the second drive module file includes at least one second drive function, and the second drive function is used to call the hardware of the device; the step of calling the hardware of the device according to the target system call function in step S103 can specifically include: accessing the system kernel through the target system call function, and determining a target second drive function from the second drive module file in the system kernel; and calling the hardware of the device through the target second drive function.

[0064] The second drive module file is a KO file deployed in the system kernel of the first operating system and used to drive the hardware. The second drive module file includes at least one second drive function, which can directly drive the hardware. Therefore, when the target system call function is called by the compatible library file, the target system call function can access the system kernel of the first operating system, find the target second drive function from the second drive module file in the system kernel of the first operating system, and then realize the call to the hardware through the target second drive function.

[0065] Referring to FIG. 4, an architecture diagram provided by an embodiment of the present application is shown. A 32-bit Docker image and a 32-bit system call file are deployed in a 64-bit Linux system, wherein the 32-bit Docker image includes a 32-bit application program, a 32-bit drive library file, and a 32-bit compatible library file. Since the 32-bit Docker image can provide a 32-bit code running environment for the 32-bit application program, the 32-bit drive library file, and the 32-bit compatible library file, the 32-bit application program can run in the 32-bit Docker image in the 64-bit Linux system. When the 32-bit application program runs, the 32-bit application program calls the 32-bit drive library file, the 32-bit drive library file calls the 32-bit compatible library file, the 32-bit compatible library file calls the 32-bit system call file, and the 32-bit system call file calls a drive function in the 64-bit Linux kernel to realize the call to the hardware 1, the hardware 2, the hardware 3, and the like.

[0066] Referring to FIG. 5, a flowchart of a device control method provided by an embodiment of the present application is shown. The 64-bit host system is a 64-bit Linux system, and the 32-bit application program is an application program used to calculate the sum of temperatures of temperature sensors. The Calculate() function is written in the 32-bit application program. When the 32-bit application program runs, the 32-bit application program first calls the Open() function in the 32-bit drive library file, which is used to indicate the opening of the temperature sensor. The Open() function calls the system call function sys_open() function in the 32-bit system call file to access the system kernel of the 64-bit operating system, and then calls the kernel drive function dr1.open() in the 64-bit operating system kernel. The dr1.open() function can directly operate the hardware device and truly realize the function of opening the temperature sensor. The process of obtaining the temperature of the temperature sensor and calculating the sum of the temperatures of the temperature sensors is not described in detail here.

[0067] Referring to FIG. 6, a flowchart of steps of another device control method provided by an embodiment of the present application is shown. The compatible library file can further include a call chain detection program. The call chain is the calling relationship of each node in the process of the target application program calling the hardware of the device. The nodes include the target application program, the first driver library file, the compatible library file, the system call file, and the second driver module file. Before the target application program, the first driver library file, and the compatible library file in the target image are compiled, the device control method can further include:

[0068] In step S11, the call chain is detected by the call chain detection program.

[0069] In step S12, call chain detection information is obtained. 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.

[0070] The call chain detection program can detect whether each node can correctly call according to the set call chain when the target application program is running. If the call chain detection information is the information indicating that the call chain is running normally, the target application program, the first driver library file, and the compatible library file in the target image can be compiled, and then the target application program is formally run. If the call chain detection information is the information indicating that the call chain is running incorrectly, the code of the error part can be manually modified. By the call chain detection program, it can be ensured that the call chain is correct when the target application program is formally run.

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

[0072] The compatible library file can store a third driver function having the same function name as the first driver function. The first driver function and the third driver function having the same function name have the same function, but the specific codes for implementing the function are different. The third driver function can be a driver function written by a developer.

[0073] When the information indicating that the call chain runs an error is the information indicating that the first driver function A in the first driver library file runs an error, the compatible library file can determine a 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, so that after the replacement, if the target application program calls the first driver function A, the compatible library file can determine the target system call file according to the first driver function A, and correctly call the target system call file.

[0074] In an embodiment, the compiling the target application program, the first driver library file and the compatible library file in the target image according to the compiling file comprises: when the call chain detection information is information indicating that the call chain runs normally, compiling the target application program, the first driver library file and the compatible library file in the target image according to the compiling file. The target application program, the first driver library file and the compatible library file in the target image are compiled again after the call chain detection is completed and the call chain detection information is information indicating that the call chain runs normally.

[0075] In an embodiment, the target image further comprises a second operating system; and the running the target application program comprises: running the target application program in the second operating system in the target image. The second operating system required by the target application program can also be packaged into the target image, so that the target application program can run normally in the target image.

[0076] In an embodiment, the device control method further comprises: obtaining a third-party component from a third-party platform; the third-party component is a component called by the target application program when running; and packaging the third-party component into the target image. The target application program can also need to call the third-party component when running, and for this case, the third-party component can also be packaged into the target image.

[0077] Referring to FIG. 7, another application program migration schematic diagram provided by an embodiment of the present application is shown. The application program is a 32-bit cleaning application program deployed on a 32-bit operating system in a semiconductor manufacturing industry, and the 32-bit cleaning application program needs to be migrated to a 64-bit operating system. The migration process specifically comprises the following steps:

[0078] Step S201: packaging the 32-bit cleaning application program and its running environment into a Docker image.

[0079] The 32-bit operating system and the 32-bit cleaning application program are packaged to generate a Docker image through a Docker command.

[0080] Step S202: adding a third-party component into the Docker image.

[0081] If the components required for running the 32-bit cleaning application are missing in the Docker image generated by the Docker command, such as third-party components including third-party provided databases, third-party provided WEB middleware, etc., then for these third-party components, the Docker Pull method can be used to pull from the third-party platform and add to the Docker image.

[0082] Step S203, add the 32-bit first driver library file to the Docker image.

[0083] 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 in the Docker image and is called by the 32-bit cleaning application, so the first driver library file is a 32-bit first driver library file.

[0084] Step S204, add the 32-bit compatible library file to the Docker image.

[0085] The 32-bit compatible library file mainly includes the functions of interface redirection, call chain detection, and general interface rewriting.

[0086] Interface redirection refers to when the 32-bit cleaning application calls the target first driver function in the 32-bit first driver library file, the compatible library file can automatically find 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.

[0087] Call chain detection refers to checking the call chain from the 32-bit cleaning application-32-bit first driver library file-32-bit compatible library file-32-bit system call file-64-bit kernel driver module file through a pre-compiled method. The call relationship of each node in the call chain is correct, and the codes of different nodes can cooperate and run correctly. After detection, call chain detection information can be obtained, including information indicating that the call chain runs normally or information indicating that the call chain runs incorrectly. The information indicating that the call chain runs incorrectly can specifically include node running error information.

[0088] General interface rewriting refers to if the information indicating that the call chain runs incorrectly is the first driver function running error information, then the first driver function with errors can be modified or replaced into a third driver function in the compatible library with the same function name as the first driver function with errors. The function names are the same, but the specific codes can be different, so if the first driver function provided by the supplier has a problem, the third driver function in the compatible library file can be used for replacement.

[0089] Step S205, adding a 32-bit system call file in a 64-bit host system kernel.

[0090] Step S206, generating a compilation file.

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

[0092] Step S207, generating a 32-bit executable file in the Docker image.

[0093] Step S208, running the 32-bit executable file.

[0094] The 32-bit executable file accesses the system kernel of the 64-bit host through the 32-bit system call function, calls the kernel driver function, and controls the hardware.

[0095] It should be noted that, for the method embodiments, in order to simply describe, they are all described as a series of action combinations, but those skilled in the art should know that the embodiments of the present application are not limited to the order of the described actions, because according to the embodiments of the present application, certain steps can be performed in other order or at the same time. Secondly, those skilled in the art should know that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present application.

[0096] Referring to FIG. 8, a structural block diagram of a device control apparatus provided by an embodiment of the present application is shown, which comprises a processor and a memory, the memory storing a computer program, and the processor executing the computer program to perform:

[0097] obtaining a target image, a compilation file and a system call file of a second operating system; wherein the target image comprises a target application program running based on the second operating system, a first driver library file and a compatible library file; the first driver library file comprises at least one first driver function, and the first driver function is used to call a system call function through the compatible library file; the compatible library file comprises a mapping relationship between the first driver function and the system call function; the system call file comprises at least one system call function; the system call function is used to call the hardware of the device; and the compilation file is used to compile and link the target application program, the first driver library file and the compatible library file;

[0098] deploying the system call file in the first operating system, and compiling the target application program, the first driver library file and the compatible library file in the target image according to the compilation file in the first operating system;

[0099] running the target application in the target image on the first operating system to determine a target first driver function corresponding to the target application, determining a target system call function according to the target first driver function and the mapping relationship, and calling the hardware of the device according to the target system call function.

[0100] 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, and the second driver function is used to call the hardware of the device; when the processor executes the computer program, the following is performed: accessing the system kernel through the 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.

[0101] In some embodiments, the compatible library file further includes a call chain detection program, the call chain is a call relationship of each node in a process in which the target application calls the hardware of the device, and the nodes include the target application, the first driver library file, the compatible library file, the system call file, and the second driver module file; when the processor executes the computer program, the following is performed: detecting the call chain through the call chain detection program before compiling the target application, the first driver library file, and the compatible library file in the target image; obtaining call chain detection information; and the call chain detection information includes information indicating that the call chain is running normally or information indicating that the call chain is running abnormally.

[0102] In some embodiments, the first driver function has a function name, the compatible library file includes a third driver function having the same function name as the first driver function, and the information indicating that the call chain is running abnormally includes information indicating that the first driver function in the first driver library file is running abnormally; when the processor executes the computer program, the following is performed: when the information indicating that the call chain is running abnormally is the information indicating that the first driver function in the first driver library file is running abnormally, determining a target third driver function having the same function name as the erroneous first driver function from the compatible library file, and replacing the erroneous first driver function in the first driver library file with the target third driver function.

[0103] In some embodiments, when the processor executes the computer program, the following is performed: when the call chain detection information is the information indicating that the call chain is running normally, the target application, the first driver library file, and the compatible library file in the target image are compiled according to the compiled file.

[0104] In some embodiments, the target image further includes a second operating system; when the processor executes the computer program, the following is performed: running the target application in the second operating system in the target image.

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

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

[0107] For the device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts refer to the part of the description of the method embodiments.

[0108] The computer readable storage medium of the embodiments of the present application stores the computer program, the computer program is executed by the processor to realize the processes of the device control method embodiments, and the same technical effects can be achieved. To avoid repetition, it will not be repeated here.

[0109] Each embodiment in the specification is described in a progressive manner, and each embodiment focuses on the difference from other embodiments. The same and similar parts of each embodiment can be referred to each other.

[0110] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, device, or computer program product. Therefore, the embodiments of the present application can be in the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the embodiments of the present application can be in the form of a computer program product implemented on one or more computer usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer usable program code.

[0111] The embodiments of the present application are described with reference to flowcharts and / or block diagrams according to the method, terminal device (system), and computer program product of the embodiments of the present application. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of the flows and / or blocks in the flowchart and / or block diagram can be realized by computer program instructions. These computer program instructions can be provided to a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device produce a device for implementing the functions specified in one or more flows in the flowchart and / or one or more blocks in the block diagram.

[0112] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart or flowsheets and / or block or blocks of the block diagrams.

[0113] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart or flowsheets and / or block or blocks of the block diagrams.

[0114] Although preferred embodiments of the application have been described, those skilled in the art will recognize that additional modifications and changes can be made thereto without departing from the scope of the present application. Accordingly, the appended claims are intended to cover all such modifications and changes as fall within the scope of the application.

[0115] Finally, it should be noted that, in this document, the terms "first", "second", and the like, merely denote different categories, and do not necessarily imply a sequence or order or priority in time. Also, the terms "comprises", "comprising", or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but can include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises... a" does not, without more constraints, exclude the presence of additional identical elements in the process, method, article, or apparatus that comprises the element. The terms "exemplary" and "for example" are used herein to mean "an example of."

[0116] The above provides a device control method, apparatus and storage medium, the principle and implementation manner of the application are described by applying specific examples, the above embodiment is only used to help understand the method and core idea of the application; meanwhile, for those skilled in the art, according to the idea of the application, the specific implementation manner and application range can be changed, and the above description should not be understood as limiting the application.

Claims

1. A device control method, characterized in that, 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. The system call functions are used to invoke 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. Deploy the system call file in the first operating system, and compile the target application, the first driver library file, and the compatibility 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 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.

2. The equipment control method according to claim 1, characterized in that, 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; The step of invoking the device's hardware according to the target system call function includes: The target system call function is used to access the system kernel, and the target second driver function is determined from the second driver module file in the system kernel. The hardware of the device is invoked through the target second driver function.

3. The equipment control method according to claim 2, characterized in that, The compatibility library file also 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 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: Before compiling the target application, the first driver library file, and the compatibility library file in the target image, the call chain is detected by the call chain detection program; Obtain 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 equipment control method according to claim 3, characterized in that, The first driver function has a function name, the compatibility 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 an error in the first driver function in the first driver library file, and the method further includes: When the information indicating an error in the call chain is an error message indicating an error in the first driver function in the first driver library file, a target third driver function with the same function name as the first driver function that reported the error is determined from the compatibility library file, and the target third driver function replaces the first driver function that reported the error in the first driver library file.

5. The equipment control method according to claim 3, characterized in that, The step of compiling the target application, the first driver library file, and the compatibility 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, the target application, the first driver library file, and the compatibility library file in the target image are compiled according to the compilation file.

6. The equipment control method according to claim 1, characterized in that, The target image also includes the second operating system; Running the target application includes: The target application is run in the second operating system within the target image.

7. The equipment control method according to claim 1, characterized in that, The method further includes: Obtain third-party components from a third-party platform; the third-party components are components invoked by the target application at runtime. The third-party components are packaged into the target image.

8. The equipment control method according to claim 1, characterized in that, The first operating system is a 64-bit operating system; the second operating system is a 32-bit operating system.

9. A device control apparatus, characterized in that, include: 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 according to any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the steps of the device control method as described in any one of claims 1-8.

Images