Cross-operating system calling method and device, and electronic device

Abstract

The present disclosure provides a cross-operating system calling method and device and electronic equipment, wherein the method comprises: receiving, by a heterogeneous computing engine, a calling instruction sent by a first subject with a first operating system; after selecting a corresponding cross-operating system calling mode, sending the calling instruction to a second subject with a second operating system according to the selected cross-operating system calling mode. Thus, after the heterogeneous computing engine determines the cross-operating system calling mode suitable for the first subject and the second subject, the selected cross-operating system calling mode is used to realize cross-operating system resource calling.

Description

Technical Field

[0001] This disclosure relates to the field of operating system technology, and in particular to a cross-operating system calling method, apparatus and electronic device. Background Technology

[0002] The diversity of operating systems in devices presents significant obstacles to interaction between them, as cross-operating system communication is required. For example, if electronic device A has both Android and Linux operating systems, then the Android and Linux operating systems cannot directly access each other's underlying hardware devices.

[0003] Therefore, there is an urgent need for a cross-operating system calling method to enable resource calls between different operating systems. Summary of the Invention

[0004] This disclosure provides a method, apparatus, electronic device, and storage medium for cross-operating system resource access, to at least solve the problem of cross-operating system resource access in related technologies. The technical solution of this disclosure is as follows:

[0005] According to a first aspect of the present disclosure, a cross-operating system invocation method is provided, comprising: receiving an invocation instruction sent by a first entity having a first operating system; selecting a corresponding cross-operating system invocation mode; and sending the invocation instruction to a second entity having a second operating system according to the selected cross-operating system invocation mode.

[0006] In one embodiment of this disclosure, selecting the corresponding cross-operating system invocation method includes: selecting the corresponding cross-operating system invocation method according to the type of the second operating system.

[0007] In one embodiment of this disclosure, selecting the corresponding cross-operating system invocation method further includes: selecting the corresponding cross-operating system invocation method according to the hardware resources corresponding to the invocation instruction.

[0008] In one embodiment of this disclosure, sending the invocation instruction to a second entity having a second operating system according to the selected cross-operating system invocation method includes: receiving an invocation instruction from an application in a first operating system, wherein the first invocation instruction corresponds to a first interface for the first operating system; obtaining a second interface of the second operating system corresponding to the first interface; and sending the invocation instruction to the second entity through the second interface.

[0009] In one embodiment of this disclosure, after sending the calling instruction to the second subject through the second interface, the method further includes: obtaining the target file corresponding to the second interface; modifying the process address in the target file to change the process address to the return address of the heterogeneous computing engine; executing the modified target file, and generating a first return result from the second return result of the target file received at the return address and sending it to the application in the first operating system.

[0010] In one embodiment of this disclosure, obtaining the target file corresponding to the second interface includes: determining the dynamic shared library corresponding to the second interface; and obtaining the target file corresponding to the dynamic shared library.

[0011] In one embodiment of this disclosure, obtaining the second interface corresponding to the first interface for the second operating system includes: obtaining the first process address corresponding to the first call instruction, wherein the first process address is used to receive the first return result corresponding to the first call instruction in the first operating system; generating a second call instruction according to the first call instruction, and obtaining the second interface of the second call instruction according to the first interface; obtaining the second process address corresponding to the second call instruction, and establishing a correspondence between the first process address and the second process address, wherein the second process address is used to receive the second return result corresponding to the second call instruction in the second operating system.

[0012] In one embodiment of this disclosure, modifying the process address in the target file includes: loading the target file into memory; obtaining the Global Offset List (GOT) corresponding to the target file; obtaining the process address in memory based on the GOT; and modifying the process address in memory to the second process address.

[0013] In one embodiment of this disclosure, the first operating system has a first system library, and the second operating system has a second system library. The method further includes: obtaining the address of the second system library in memory according to the GOT; and modifying the address of the second system library to the address of the first system library.

[0014] In one embodiment of this disclosure, the step of executing the modified target file and generating a first return result from the second return result of the target file received at the return address and sending it to the application in the first operating system includes: executing the modified target file to generate the second return result; determining the corresponding first process address according to the correspondence between the first process address and the second process address; generating the first return result according to the first process address and the content of the second return result, and feeding it back to the first process address.

[0015] In one embodiment of this disclosure, sending the invocation instruction to a second entity having a second operating system according to the selected cross-operating system invocation method includes: if the type of the first operating system is the same as the type of the second operating system, then a first connection bridge is established between the first entity and the second entity, and the first entity sends the invocation instruction to the second entity through the first connection bridge; the first connection bridge is used for resource invocation between the first entity and the second entity having the same operating system type; if the type of the first operating system is different from the type of the second operating system, then a second connection bridge is established between the first entity and the second entity, and the first entity sends the invocation instruction to the second entity through the second connection bridge; the second connection bridge is used for resource invocation between the first entity and the second entity having different operating system types.

[0016] In one embodiment of this disclosure, there are multiple second entities, and the method further includes: sending resource reporting messages to multiple second entities; receiving resource information sent by the multiple second entities; and sending the resource information sent by the multiple second entities to the first entity, so that the first entity generates a resource call list based on the resource information of the multiple second entities for the first entity to call.

[0017] In one embodiment of this disclosure, there are multiple second entities, and the method further includes: receiving a resource call request from the first entity, wherein the resource call request contains a resource address of a target resource; determining a second entity carrying the target resource based on the resource address of the target resource; and, based on the second operating system type of the second entity of the target resource, calling the first connection bridge or the second connection bridge to send the resource call request to the second entity of the target resource, so as to call the resources of the second entity of the target resource.

[0018] In one embodiment of this disclosure, establishing a first connection bridge between the first subject and the second subject includes: establishing shared memory between the first subject and the second subject, and establishing the first connection bridge through the shared memory.

[0019] In one embodiment of this disclosure, establishing a first connection bridge between the first subject and the second slave device further includes: establishing a hardware component mapping table between the first subject and the second subject, wherein the hardware component mapping table contains mapping relationships between hardware components in the first subject and the second subject; and establishing the first connection bridge through the hardware component mapping table.

[0020] In one embodiment of this disclosure, after establishing a first connection bridge between the first subject and the second subject, the method further includes: entering a second operating system of the second subject through the first connection bridge, detecting multiple hardware components of the second subject; determining that there are hardware components in the second subject that have failed detection, and then determining a target hardware component mapped to the hardware component that failed detection through the mapping relationship of the hardware components in the hardware component mapping table, until all the multiple hardware components of the second subject pass the detection.

[0021] In one embodiment of this disclosure, the resource information includes the resource address of the resource in the second subject, and the establishment of a second connection bridge between the first subject and the second subject includes: establishing a routing adaptation table based on the resource address of the resource in the second subject, wherein the routing adaptation table is used to establish the second connection bridge.

[0022] In one embodiment of this disclosure, the step of invoking the second connection bridge to send the resource request to the second subject of the target resource based on the second operating system type of the second subject of the target resource includes: if the second operating system type of the second subject of the target resource is inconsistent with the first operating system type of the first subject, then obtaining the resource address of the target resource from the resource request; looking up the routing adaptation table based on the resource address of the target resource to obtain the corresponding routing path from the routing adaptation table; and sending the resource request to the corresponding second subject of the target resource based on the routing path.

[0023] In one embodiment of this disclosure, establishing a second connection bridge between the first entity and the second entity includes: obtaining the I / O interface of each resource in the second entity, and generating a corresponding virtual I / O interface for each resource's I / O interface; establishing a mapping relationship between the first entity and the virtual I / O interface; and establishing the second connection bridge through the mapping relationship.

[0024] In one embodiment of this disclosure, establishing a second connection bridge between the first subject and the second subject includes: establishing a memory mapping relationship between the first subject and the second subject; and establishing the second connection bridge according to the memory mapping relationship.

[0025] In one embodiment of this disclosure, sending the invocation instruction to a second entity having a second operating system according to the selected cross-operating system invocation method includes:

[0026] Obtain the invocation instruction sent by the first entity through the first process;

[0027] Obtain the second process within the second entity and establish a cross-process communication channel between the first process and the second process;

[0028] The invocation instruction is sent to the second process through the inter-process communication channel so that the second process can invoke the service corresponding to the invocation instruction; wherein, the service is obtained by encapsulating the hardware information in the second entity.

[0029] In one embodiment of this disclosure, after sending the call instruction to the second process through the inter-process communication channel, the method further includes:

[0030] The second process obtains the call result corresponding to the service and sends the call result to the first process through the cross-process communication channel.

[0031] In one embodiment of this disclosure, the method further includes: obtaining hardware information of multiple hardware components in the second entity; and generating multiple services corresponding to the multiple hardware components based on the hardware information.

[0032] In one embodiment of this disclosure, establishing an inter-process communication channel between the first process and the second process includes: establishing a client corresponding to the first process in the first entity; and establishing a server corresponding to the second process in the second entity, wherein the inter-process communication channel is established through the client and the server.

[0033] In one embodiment of this disclosure, sending the call instruction to the second process through the inter-process communication channel includes: converting the call instruction into a first inter-process communication instruction; and sending the first inter-process communication instruction to the server through the client, so that the server converts the first inter-process communication instruction into a call instruction suitable for the second operating system and sends it to the second process.

[0034] In one embodiment of this disclosure, sending the call result to the first process through the inter-process communication channel includes: converting the call result into a second inter-process communication instruction; and sending the second inter-process communication instruction to the client through the server, so that the client converts the second inter-process communication instruction into a call result suitable for the first operating system and sends it to the first process.

[0035] According to a second aspect of the present disclosure, a cross-operating system invocation device is provided, comprising:

[0036] A receiving module is used to receive a calling instruction sent by a first entity having a first operating system;

[0037] The module selection option allows you to choose the corresponding cross-operating system calling method.

[0038] The sending module is used to send the calling instruction to a second entity having a second operating system according to the selected cross-operating system calling method.

[0039] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable invocation instructions; wherein the processor is configured to execute the invocation instructions to implement the cross-operating system invocation method as described in the first aspect.

[0040] According to a fourth aspect of the present disclosure, a non-transitory computer-readable storage medium is provided, which, when a calling instruction in the storage medium is executed by a processor of an electronic device, enables the electronic device to perform the cross-operating system calling method as described in the first aspect.

[0041] According to a fifth aspect of the present disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the cross-operating system invocation method proposed in the first aspect of the present disclosure.

[0042] The cross-operating system invocation method, apparatus, and electronic device provided in this disclosure receive an invocation instruction sent by a first entity having a first operating system through a heterogeneous computing engine. After selecting a corresponding cross-operating system invocation method, the invocation instruction is sent to a second entity having a second operating system according to the selected cross-operating system invocation method. Thus, after determining the cross-operating system invocation method applicable to the first and second entities, the heterogeneous computing engine realizes cross-operating system resource invocation using the selected cross-operating system invocation method.

[0043] Additional aspects and advantages of this disclosure will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this disclosure. Attached Figure Description

[0044] The above and / or additional aspects and advantages of this disclosure will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, in which:

[0045] Figure 1 A flowchart illustrating a cross-operating system invocation method provided in this embodiment of the disclosure;

[0046] Figure 2 This is a diagram of the cross-operating system calling structure according to an embodiment of the present disclosure;

[0047] Figure 3 A flowchart illustrating another cross-operating system invocation method provided in this embodiment of the disclosure;

[0048] Figure 4 A flowchart illustrating another cross-operating system invocation method provided in this embodiment of the disclosure;

[0049] Figure 5 A flowchart illustrating a target file modification method provided in this embodiment of the disclosure;

[0050] Figure 6 A flowchart illustrating another cross-operating system invocation method provided in this embodiment of the disclosure;

[0051] Figure 7 A flowchart illustrating another cross-operating system invocation method provided in this embodiment of the disclosure;

[0052] Figure 8 A flowchart illustrating yet another cross-operating system invocation method provided in this disclosure embodiment;

[0053] Figure 9 A flowchart illustrating yet another cross-operating system invocation method provided in this disclosure embodiment;

[0054] Figure 10 A flowchart illustrating yet another cross-operating system invocation method provided in this disclosure embodiment;

[0055] Figure 11 A flowchart illustrating yet another cross-operating system invocation method provided in this disclosure embodiment;

[0056] Figure 12 A flowchart illustrating yet another cross-operating system invocation method provided in this disclosure embodiment;

[0057] Figure 13 A flowchart illustrating yet another cross-operating system invocation method provided in this disclosure embodiment;

[0058] Figure 14A flowchart illustrating yet another cross-operating system invocation method provided in this disclosure embodiment;

[0059] Figure 15 This is a flowchart illustrating yet another cross-operating system invocation method provided in an embodiment of this disclosure;

[0060] Figure 16 This is a flowchart illustrating yet another cross-operating system invocation method provided in an embodiment of this disclosure;

[0061] Figure 17 An interactive schematic diagram of a cross-operating system invocation method provided in an embodiment of this disclosure;

[0062] Figure 18 A schematic diagram of a cross-operating system calling device provided in an embodiment of this disclosure;

[0063] Figure 19 This is a block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0064] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this disclosure as detailed in the appended claims.

[0065] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the present disclosure. The singular forms “a” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0066] It should be understood that although the terms first, second, third, etc., may be used to describe various information in embodiments of this disclosure, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of embodiments of this disclosure, and similarly, second information may also be referred to as first information. Depending on the context, the words “if” and “suppose” as used herein may be interpreted as “when”, “when”, or “in response to a determination”.

[0067] Embodiments of this disclosure are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this disclosure, and should not be construed as limiting this disclosure.

[0068] In embodiments of this disclosure, a heterogeneous computing engine is proposed. This heterogeneous computing engine can be located in a first entity or a second entity, and this disclosure does not limit the specific embodiment. In one embodiment of this disclosure, the heterogeneous computing engine can be located in the first entity. The heterogeneous computing engine has a first interface and a second interface. The first interface conforms to the specifications of the operating system of the first entity and can be called by the first entity. The second interface conforms to the specifications of the operating system of the second entity and can be called by the second entity. Simultaneously, the second interface can also call hardware or software resources within the second entity. Of course, in other embodiments of this disclosure, the heterogeneous computing engine can also be located in the second entity.

[0069] As an example, this cross-operating system invocation system may include a first entity, a second entity, and a heterogeneous computing engine. The heterogeneous computing engine acts as a communication intermediary between the first and second entities, enabling mutual resource invocation between them. The heterogeneous computing engine obtains the invocation instruction sent by the first entity through a first process, obtains the second process within the second entity, and establishes a cross-process communication channel between the first and second processes. It then sends the invocation instruction to the second process through this cross-process communication channel, allowing the second process to invoke the service corresponding to the invocation instruction. The second process obtains the invocation result and sends it back to the first process through the cross-process communication channel. In subsequent embodiments, the solution of this application will be described in detail with reference to specific examples.

[0070] Figure 1 This is a flowchart illustrating a cross-operating system invocation method provided in an embodiment of this disclosure. In one embodiment, this method can be applied to a heterogeneous computing engine. Of course, in other embodiments of this disclosure, this method can also be used in other engines, as long as it enables resource invocation between the first entity and the second entity.

[0071] As an example, Figure 2This is a structural diagram of a cross-operating system invocation system according to an embodiment of the present disclosure. The cross-operating system invocation system 200 may include a first entity 210, a second entity 220, and a heterogeneous computing engine 230. The heterogeneous computing engine 230 acts as a communication intermediary between the first entity 210 and the second entity 220, enabling mutual resource invocation between them. For example, if the first entity 210 operates on an iOS operating system and the second entity 220 operates on a Linux operating system, the heterogeneous computing engine 230 can obtain the invocation command sent by the first entity 210, convert the command into an invocation command recognizable by the Linux operating system, and send the converted command to the second entity 220. Upon receiving the command, the second entity 220 sends the target resource to the heterogeneous computing engine 230. The heterogeneous computing engine 230 converts the received target resource into a resource recognizable by the iOS operating system and sends it to the first entity 210, thereby enabling resource invocation between the first entity 210 and the second entity 220, which operate on different systems.

[0072] In one possible embodiment of this application, the first entity 210 and the second entity 220 can be system modules, driver modules, kernels, APPs, devices, etc., and the scope is not limited.

[0073] like Figure 1 As shown, the method includes the following steps:

[0074] Step 101: Receive a call instruction sent by a first entity with a first operating system.

[0075] The first entity can be an APP or driver set up for controlling smart home appliances. In this embodiment, the first entity is not limited.

[0076] An operating system (OS) is the system software in a computer system responsible for supporting the runtime environment of applications and the user's operating environment. It is also the core and foundation of the computer system. An operating system is a collection of programs that control and manage computer hardware and software resources, organize computer workflows, and facilitate user operation. Its responsibilities often include direct monitoring of hardware, management of various computing resources (such as memory and processor time), and providing application-oriented services such as job management. Operating system types include Android, iOS, Linux, Unix, macOS, and Windows, among others.

[0077] In this embodiment of the disclosure, when a first entity with a first operating system calls the hardware resources and / or software resources of a second entity, a call instruction can be sent, and the heterogeneous computing engine can receive the call instruction sent by the first entity. The call instruction is used to call at least one of the hardware resources or software resources of the second entity.

[0078] Step 102: Select the corresponding cross-operating system calling method.

[0079] Among them, the cross-operating system call method can be to obtain the first interface corresponding to the first operating system and the second interface corresponding to the second operating system, as well as the target file corresponding to the second interface, modify the process address in the target file; execute the modified target file and return the first return result to the application in the first operating system; it can also be to establish a connection bridge between the first subject and the second subject, and realize resource calls between the first subject and the second subject through the connection bridge; it can also be to establish a cross-process communication channel between the first subject and the second subject, and realize resource calls between the first process of the first subject and the second process of the second subject through the cross-process communication channel, and so on.

[0080] As one possible implementation of this disclosure, the heterogeneous computing engine can select the corresponding cross-operating system invocation method based on the type of the second operating system. That is, when the first entity and the second entity correspond to different types of operating systems, the cross-operating system invocation method selected by the heterogeneous computing engine will also be different.

[0081] For example, the first operating system of the first entity is the iOS operating system, and the second operating system of the second entity is the Android operating system. The heterogeneous computing engine can choose to establish a cross-operating system call method by establishing a connection bridge between the first entity and the second entity, or it can choose to establish a cross-process communication channel between the first entity and the second entity, and realize the cross-operating system call method of resource call between the first process of the first entity and the second process of the second entity through the cross-process communication channel.

[0082] For example, if the first operating system of the first entity is an iOS operating system and the second operating system of the second entity is a Windows operating system, the heterogeneous computing engine can obtain the first interface corresponding to the first operating system and the second interface corresponding to the second operating system, as well as the target file corresponding to the second interface, modify the process address in the target file, execute the modified target file, and return the first return result to the application in the first operating system to realize cross-operating system calls.

[0083] As another possible implementation of this disclosure, the heterogeneous computing engine can also select the corresponding cross-operating system calling method according to the hardware resources corresponding to the calling instruction.

[0084] For example, when the first and second entities call resources, the called hardware resources have high performance requirements, such as calling image resources. In order to improve the efficiency of resource calling, the heterogeneous computing engine can choose a cross-operating system calling method that establishes a connection bridge between the first and second entities.

[0085] Step 103: Send the call instruction to the second entity with the second operating system according to the selected cross-operating system call method.

[0086] In this embodiment of the disclosure, after the heterogeneous computing engine selects the cross-operating system calling method, it can send the calling instruction to the second entity with the second operating system according to the selected cross-operating system calling method in order to obtain the calling result.

[0087] It should be noted that in the above embodiments, the heterogeneous computing engine can be independent of the first operating system and the second operating system, or it can be placed in the first operating system or the second operating system. This disclosure does not limit this aspect.

[0088] The cross-operating system invocation method of this application embodiment involves a heterogeneous computing engine receiving an invocation instruction from a first entity with a first operating system, selecting a corresponding cross-operating system invocation method, and further, sending the invocation instruction to a second entity with a second operating system according to the selected cross-operating system invocation method. Thus, after determining the appropriate cross-operating system invocation method for the first and second entities, the heterogeneous computing engine uses this method to implement cross-operating system resource invocation.

[0089] It should be noted that the above-mentioned possible implementations can be executed individually or in combination, and this disclosure does not limit them.

[0090] In one possible embodiment of this disclosure, the heterogeneous computing engine can obtain a first interface corresponding to the first operating system and a second interface corresponding to the second operating system, as well as a target file corresponding to the second interface, modify the process address in the target file; execute the modified target file, and return a first return result to the application in the first operating system. The following describes the process in conjunction with... Figure 3 A detailed introduction will be provided. Figure 3 This is a flowchart illustrating another cross-operating system invocation method provided by an embodiment of this disclosure. In one embodiment of this disclosure, the method can be applied to a heterogeneous computing engine. Of course, in other embodiments of this disclosure, the method can also be used for other engines.

[0091] like Figure 3 As shown, this cross-operating system invocation method may also include the following steps:

[0092] Step 301: Receive a first call instruction from an application in the first operating system, wherein the first call instruction corresponds to a first interface for the first operating system.

[0093] In one embodiment of this disclosure, the heterogeneous computing engine resides between the first operating system and the second operating system. Therefore, the heterogeneous computing engine needs to communicate with both the first and second operating systems simultaneously. In another embodiment of this disclosure, the heterogeneous computing engine can communicate with applications within both the first and second operating systems. Furthermore, the heterogeneous computing engine can also access resources within both operating systems, such as hardware or software resources.

[0094] In one embodiment of this disclosure, the example of an app in a first operating system calling hardware resources in a second operating system is described. Of course, in other embodiments of this disclosure, an app in a second operating system can also call hardware resources in a first operating system. In the embodiments of this disclosure, the heterogeneous computing engine has a first interface and a second interface. The first interface is used for calls by an app in the first operating system; that is, the first interface is visible in the first operating system, and the app in the first operating system can call the first interface. The second interface can be used to communicate with underlying hardware resources in the second operating system. In one embodiment of this disclosure, the second interface can correspond to a type of hardware resource. In this embodiment, the first interface conforms to the requirements of the first operating system, the second interface conforms to the requirements of the second operating system, and the first and second interfaces correspond to a type of hardware resource. In the embodiments of this disclosure, the heterogeneous computing engine has multiple first interfaces and multiple second interfaces, each corresponding to a variety of hardware or software resources. It should be noted that in the embodiments of this disclosure, not only can cross-system calls for hardware resources be realized, but cross-system calls for software resources can also be realized, for example, an app on an iOS system can call some software within an app on an Android system.

[0095] In one embodiment of this disclosure, the heterogeneous computing engine can obtain various hardware resources in a second operating system through registration. For example, the heterogeneous computing engine sends registration requests to various hardware resources in the second operating system, requesting each hardware resource to register with it, thereby learning the capabilities of each hardware resource, such as whether it supports a sound card and the performance of the sound card. After learning the capabilities of the various hardware resources, the heterogeneous computing engine establishes multiple second interfaces for each hardware resource, wherein all of the multiple second interfaces support the second operating system. Among the established multiple second interfaces, multiple first interfaces are established for each of the multiple second interfaces, wherein all of the multiple first interfaces support the first operating system and can be invoked by an application within the first operating system.

[0096] In other embodiments of this disclosure, the heterogeneous computing engine may also register its hardware resources with multiple apps in the first operating system. In this embodiment, the heterogeneous computing engine registers the hardware resources of the second operating system to the heterogeneous computing engine as its own hardware resources with multiple apps in the first operating system, so that the apps in the first operating system can directly call the hardware resources of the second operating system through the heterogeneous computing engine.

[0097] For example, video apps on mobile devices can directly call apps used to control smart TVs to play videos through this heterogeneous computing engine, or music apps can directly call apps used to control smart speakers to play music through this heterogeneous computing engine. In this case, the operating systems of the video apps on mobile devices and the apps used to control smart TVs are different, and the operating systems of the music apps on mobile devices and the apps used to control smart speakers are different.

[0098] Step 302: Obtain the second interface of the second operating system corresponding to the first interface.

[0099] In one embodiment of this disclosure, the heterogeneous computing engine can pre-establish an association between a first interface and a second interface. When the first interface is invoked, the corresponding second interface can be determined based on this association. For example, in an embodiment of this disclosure, both the first and second interfaces correspond to the display function of a smart TV. When an app in the first operating system needs to call hardware or software resources for display, it can call the hardware or software resources provided by the first interface in the first operating system. When the first interface is invoked, the heterogeneous computing engine invokes the second interface corresponding to the first interface, and then calls the hardware or software resources used for display in the second operating system through the second interface.

[0100] Step 303: Send the first invocation instruction to the second entity through the second interface.

[0101] In this embodiment of the disclosure, after obtaining the second interface for the second operating system corresponding to the first interface, the first call instruction can be sent to the second subject through the second interface.

[0102] Step 304: Obtain the target file corresponding to the second interface.

[0103] In one embodiment of this disclosure, the dynamic shared library corresponding to the second interface is first obtained, and then the target file corresponding to the dynamic shared library is obtained.

[0104] In embodiments of this disclosure, dynamic shared libraries may include base libraries and driver libraries. In embodiments of this disclosure, base libraries may include libc.so, libz.so, libpthread.so, etc. In other embodiments of this disclosure, driver libraries may include libGLES_xxx.so, gralloc_xx.so, audio_xx.so, etc. The base libraries are the essential libraries required for the normal startup of the operating system and for loading programs. For example, libc.so is required by Linux OS. Driver libraries are provided by hardware manufacturers to OEMs, providing libraries for specific functions (such as display drivers, sound drivers, etc.).

[0105] Step 305: Modify the process address in the target file to change the process address to the return address of the heterogeneous computing engine.

[0106] In one embodiment of this disclosure, the process address in the target file is modified so that the process address of the target file is changed to the return address of the heterogeneous computing engine, so that after the target file is executed, the execution result of the target file is fed back to the return address of the heterogeneous computing engine.

[0107] In one embodiment of this disclosure, the second operating system can be a Linux system, the target file is an ELF (Executable Linkable Format) file, and the first operating system can be an Android, iOS, Windows system, etc.

[0108] Step 306: Execute the modified target file, and generate a first return result from the second return result of the target file received at the return address, and send it to the application in the first operating system.

[0109] In one embodiment of this disclosure, since the process address of the target file has been modified to the return address of the heterogeneous computing engine, the modified target file will send the execution result back to the heterogeneous computing engine after execution. The heterogeneous computing engine will then send the execution result as the first return result back to the application in the first operating system, thereby realizing cross-operating system resource calls.

[0110] It should be noted that the above-mentioned possible implementations can be executed individually or in combination, and this disclosure does not limit them.

[0111] Figure 4 This is a flowchart illustrating another cross-operating system invocation method provided by an embodiment of this disclosure. In one embodiment of this disclosure, the method can be applied to a heterogeneous computing engine. Of course, in other embodiments of this disclosure, the method can also be used for other engines, as long as it enables invocation between the first operating system and the second operating system. Figure 4 As shown, the method includes the following steps:

[0112] Step 401: Receive the first call instruction of the application in the first operating system, wherein the first call instruction corresponds to the first interface for the first operating system.

[0113] In this embodiment, the implementation process of step 401 can be referred to the implementation process of step 301 in the above embodiment, and will not be repeated here.

[0114] Step 402: Obtain the first process address corresponding to the first call instruction, wherein the first process address is used to receive the first return result corresponding to the first call instruction in the first operating system.

[0115] In one embodiment of this disclosure, in the first operating system, each call instruction corresponds to a process address, so that when the call instruction generates a return result, the return result can be returned to the process address corresponding to the call instruction. In this embodiment, the first call instruction corresponds to a first process address, which is used to receive the first return result generated when the first call instruction is executed in the first operating system.

[0116] Step 403: Generate a second calling instruction based on the first calling instruction, and obtain the second interface of the second calling instruction based on the first interface.

[0117] In the embodiments of this disclosure, since the first interface and the second interface have the same hardware resources, the heterogeneous computing engine can know the hardware resources that the APP in the first operating system wants to call after it learns the first call instruction. Therefore, in the second operating system, it generates the corresponding second call instruction according to the first call instruction and obtains the corresponding second interface.

[0118] In one embodiment of this disclosure, the heterogeneous computing engine can pre-establish an association between a first interface and a second interface. When the first interface is invoked, the corresponding second interface can be determined based on this association. When an app in the first operating system needs to access hardware resources for display, it can access the hardware resources provided by the first interface in the first operating system. When the first interface is invoked, the heterogeneous computing engine invokes the second interface corresponding to the first interface, and then uses the second interface to access the hardware resources in the second operating system used for display.

[0119] Step 404: Obtain the second process address corresponding to the second call instruction, and establish the correspondence between the first process address and the second process address. The second process address is used to receive the second return result corresponding to the second call instruction in the second operating system.

[0120] In an embodiment of this disclosure, the second process address is the return result of receiving the second call instruction in the second operating system. Therefore, in one embodiment of this disclosure, it is necessary to establish a correspondence between the first process address and the second process address in the heterogeneous computing engine. The first process address is applicable to the first operating system, and the second process address is applicable to the second operating system. In this way, after receiving the second return result of the second process address, the heterogeneous computing engine can continue to return the corresponding return result to the APP in the first operating system through the first process address corresponding to the second process address.

[0121] Step 405: Obtain the target file corresponding to the second interface.

[0122] Step 406: Modify the process address in the target file to change the process address to the return address of the heterogeneous computing engine.

[0123] Step 407: Execute the modified target file, and generate a first return result from the second return result of the target file received at the return address, and send it to the application in the first operating system.

[0124] In this embodiment, the implementation process of steps 405 to 407 can be referred to the implementation process of steps 302 to 304 in the above embodiment, and will not be repeated here.

[0125] The cross-operating engine invocation method of this disclosure involves a heterogeneous computing engine receiving a second return result generated after executing a modified target file, and then determining the corresponding first process address based on the correspondence between the first process address and the second process address. The heterogeneous computing engine generates a first return result based on the first process address and the content of the second return result, and feeds it back to the first process address. The APP in the first operating system can then obtain the first return result from the first process address, thereby realizing cross-operating system resource invocation.

[0126] It should be noted that the above-mentioned possible implementations can be executed individually or in combination, and this disclosure does not limit them.

[0127] In one embodiment of this disclosure, the heterogeneous computing engine can modify the target file in the following manner. (The following is a continuation of the previous paragraph.) Figure 5 A detailed introduction will be provided. Figure 5 This is a flowchart illustrating a method for modifying a target file provided in an embodiment of this disclosure. Figure 5 As shown, the method may include the following steps:

[0128] Step 501: Load the target file into memory.

[0129] In one embodiment of this disclosure, the target file can be loaded into memory using memory mapping.

[0130] Step 502: Obtain the GOT (Global Offset Table) corresponding to the target file.

[0131] In one embodiment of this disclosure, the GOT is located within the object file. In other embodiments of this disclosure, the second operating system can be a Linux system, the object file is an ELF (Executable Linkable Format) file, and the GOT is located within the ELF file. The GOT records the memory locations of various function symbols within the ELF file.

[0132] Step 503: Obtain the process address in memory based on GOT, and modify the process address in memory to the second process address.

[0133] In this embodiment, since the GOT records the positions of each function symbol, the process address in memory can be found based on the GOT, and the process address in memory can be modified to the second process address, thereby ensuring that after the target file is executed, the result can be fed back to the second process address of the heterogeneous computing engine.

[0134] In one embodiment of this disclosure, since the first operating system and the second operating system may have different system libraries, there may be a problem of system library asynchrony. That is, the first system library of the first operating system and the second system library of the second operating system may be different, which will lead to system library incompatibility. Therefore, in one embodiment of this disclosure, it is also necessary to synchronize the system libraries. Specifically, the heterogeneous computing engine obtains the address of the second system library in memory according to GOT and modifies the address of the second system library to the address of the first system library, thereby satisfying the system library synchronization problem between the two operating systems.

[0135] Through the embodiments of this disclosure, cross-operating system resource calls can be realized. In this embodiment, a heterogeneous computing engine is set up between a first operating system and a second operating system. This heterogeneous computing engine obtains a first invocation instruction from an APP (application) on the first operating system, and obtains a corresponding second interface of the second operating system based on a first interface in the first invocation instruction. It also modifies the process address of the target file so that the execution result of the target file can be fed back to the heterogeneous computing engine, which then forwards it to the APP on the first operating system, thereby realizing cross-operating system resource calls. That is, an APP on the first operating system can call hardware or software resources in the second operating system. For example, an APP on an iOS operating system can directly call resources from APPs on Android or Linux operating systems.

[0136] It should be noted that the above-mentioned possible implementations can be executed individually or in combination, and this disclosure does not limit them.

[0137] In one possible embodiment of this disclosure, a heterogeneous computing engine can establish a connection bridge between a first subject and a second subject to realize resource calls between the first subject and the second subject based on the connection bridge. The following describes... Figure 6 A detailed introduction will be provided. Figure 6 This is a flowchart illustrating another cross-operating system invocation method provided by an embodiment of this disclosure. In one embodiment of this disclosure, the method can be applied to a heterogeneous computing engine. Of course, in other embodiments of this disclosure, the method can also be used for other engines.

[0138] like Figure 6 As shown, this cross-operating system invocation method may also include the following steps:

[0139] Step 601: Receive a call instruction sent by a first entity having a first operating system.

[0140] Step 602: Select the corresponding cross-operating system calling method according to the type of the second operating system.

[0141] Step 603: If the type of the first operating system is the same as the type of the second operating system, a first connection bridge is established between the first subject and the second subject, and the first subject sends the call instruction to the second subject through the first connection bridge.

[0142] The first connection bridge is used for resource access between a first entity and a second entity with the same operating system type, enabling cross-process communication between the two entities. That is, resources can be directly transferred between the first operating system of the first entity and the second operating system of the second entity without requiring resource conversion.

[0143] In this embodiment of the disclosure, after obtaining the first operating system type of the first subject and the second operating system type of the second subject, and determining that the first operating system type and the second operating system type are consistent, a first connection bridge is established between the first subject and the second subject, so that the first subject can send the calling instruction to the second subject through the first connection bridge.

[0144] For example, suppose the first entity is an app set on a mobile terminal, and the second entity is an app that controls a smart speaker. The first entity's operating system is iOS, and the second entity's operating system is also iOS. Then, a first connection bridge is established between the first entity and the second entity so that the first entity and the second entity can call resources through the first connection bridge.

[0145] Step 604: If the type of the first operating system is inconsistent with the type of the second operating system, a second connection bridge is established between the first entity and the second entity, and the first entity sends the calling instruction to the second entity through the second connection bridge.

[0146] The second connection bridge is used for resource calls between a first entity and a second entity with different operating system types. It can convert resources according to the first operating system type of the first entity and the second operating system type of the second entity to realize cross-operating system calls.

[0147] In this embodiment of the disclosure, after obtaining the first operating system type of the first subject and the second operating system type of the second subject, and determining that the first operating system type and the second operating system type are inconsistent, a second connection bridge is established between the first subject and the second subject, so that the first subject can send the calling instruction to the second subject through the second connection bridge.

[0148] For example, suppose the first entity is an app set up on a mobile terminal, and the second entity is an app used to control a smart speaker. The first entity is an iOS operating system, and the second entity is an Android operating system. Then, a second connection bridge is established between the first entity and the second entity so that the first entity and the second entity can call resources through the second connection bridge.

[0149] The cross-operating system invocation method of this disclosure obtains the first operating system type of the first subject and the second operating system type of the second subject through a heterogeneous computing engine. If the first operating system type and the second operating system type are consistent, a first connection bridge is established between the first subject and the second subject; otherwise, a second connection bridge is established between the first subject and the second subject. Thus, when it is determined that the operating system types of the first subject and the second subject are inconsistent, a second connection bridge capable of enabling resource invocation between devices with different operating systems is established between the first subject and the second subject, thereby achieving cross-operating system invocation through the second connection bridge.

[0150] It should be noted that the above-mentioned possible implementations can be executed individually or in combination, and this disclosure does not limit them.

[0151] In one possible embodiment of this disclosure, there can be multiple second entities. The heterogeneous computing engine can send the hardware and / or software resources of multiple second entities to the first entity, so that the first entity can directly call the resources of the second entities. The following is in conjunction with... Figure 7 A detailed introduction will be provided. Figure 7 This is a flowchart illustrating another cross-operating system invocation method provided by an embodiment of this disclosure. In one embodiment of this disclosure, the method can be applied to a heterogeneous computing engine. Of course, in other embodiments of this disclosure, the method can also be used in other engines, as long as it enables invocation between the first entity and the second entity.

[0152] like Figure 7 As shown, this cross-operating system invocation method may also include the following steps:

[0153] Step 701: Send resource reporting messages to multiple second entities.

[0154] Among them, the resource reporting message refers to the message sent by the heterogeneous computing engine to multiple second entities to obtain hardware resource information and / or software resource information of multiple second entities.

[0155] In this embodiment of the disclosure, in order to store the resource information of multiple second entities in the first entity, the heterogeneous computing engine can send resource reporting messages to multiple second entities, so that after receiving the resource reporting messages, the multiple second entities send the corresponding resource information to the heterogeneous computing engine.

[0156] It should be noted that, in the embodiments of this disclosure, the first entity and multiple second entities can not only achieve cross-operating system calls for hardware resources, but also cross-operating system calls for software resources. For example, an iOS operating system APP can call some software in an Android system APP.

[0157] Step 702: Receive resource information sent by multiple second entities.

[0158] In this embodiment of the disclosure, after the heterogeneous computing engine sends resource reporting messages to multiple second entities, the multiple second entities, upon receiving the resource reporting messages, send the corresponding resource information to the heterogeneous computing engine, so that the heterogeneous computing engine receives the resource information sent by the multiple second entities.

[0159] It should be noted that the resource information received by the heterogeneous computing engine from multiple second entities can be hardware resource information, software resource information, or a combination of both.

[0160] For example, a heterogeneous computing engine can receive the capabilities of various hardware resources sent by multiple second entities, such as whether a sound card is supported and the performance of the sound card, etc.

[0161] Step 703: Send the resource information sent by the multiple second entities to the first entity, so that the first entity can generate a resource call list based on the resource information of the multiple second entities for the first entity to call.

[0162] In this embodiment of the disclosure, after the heterogeneous computing engine receives resource information sent by multiple second entities, it can send the resource information sent by the multiple second entities to the first entity, so that after the first entity receives the resource information from the multiple second entities, it can generate a resource call list based on the resource information from the multiple second entities for the first entity to call.

[0163] In this embodiment of the disclosure, after the first entity receives resource information from multiple second entities, the resource call list generated based on the resource information of the multiple second entities may include hardware resource information and / or software resource information of the multiple second entities.

[0164] The cross-operating system invocation method of this disclosure sends resource reporting messages to multiple second entities through a heterogeneous computing engine. After receiving resource information sent by multiple second entities, it sends the resource information sent by the multiple second entities to a first entity, so that the first entity generates a resource invocation list based on the resource information of the multiple second entities for invocation. Therefore, after the first entity generates the resource invocation list based on the resource information sent by multiple second entities, it can directly invoke resources from the resource invocation list when invoking the resources of the second entities, thus not only realizing cross-operating system resource invocation but also improving the efficiency of resource invocation.

[0165] It should be noted that the above-mentioned possible implementations can be executed individually or in combination, and this disclosure does not limit them.

[0166] As one possible embodiment of this disclosure, when the first entity calls the resources of the second entity, the heterogeneous computing engine can also determine whether to use the first connection bridge or the second connection bridge based on the operating system type of the second entity to be called, and send the resource call request sent by the first entity to the second entity to realize the resource call of the second entity. The following is in conjunction with... Figure 8 A detailed introduction will be provided. Figure 8 This is a flowchart illustrating another cross-operating system invocation method provided in an embodiment of the present disclosure.

[0167] like Figure 8 As shown, this cross-operating system invocation method may also include the following steps:

[0168] Step 801: Receive a resource call request from the first entity, wherein the resource call request contains the resource address of the target resource.

[0169] In this embodiment of the disclosure, when the first subject calls the resources of the second subject, the first subject may send a resource call request carrying the resource address of the target resource to the heterogeneous computing engine, so that the heterogeneous computing engine receives the resource call request from the first subject.

[0170] Optionally, the resource address of the target resource can be the routing address of the target resource.

[0171] It should be noted that the operating system type of the first entity can be the same as or different from the operating system types of multiple second entities; no restrictions are imposed here.

[0172] Step 802: Determine the second entity carrying the target resource based on the resource address of the target resource.

[0173] In this embodiment of the disclosure, after the heterogeneous computing engine receives a resource call request with the resource address of the target resource sent by the first subject, it can determine the second subject carrying the target resource based on the resource address of the target resource.

[0174] Step 803: Based on the second operating system type of the second principal of the target resource, call the first connection bridge or the second connection bridge to send the resource call request to the second principal of the target resource, so as to call the resources of the second principal of the target resource.

[0175] In this embodiment of the disclosure, after the heterogeneous computing engine determines the second entity carrying the target resource based on the resource address of the target resource, it can obtain the second operating system type of the second entity of the target resource. Based on the second operating system type of the second entity of the target resource, it can call the first connection bridge or the second connection bridge to send the resource call request to the second entity of the target resource so as to call the resources of the second entity of the target resource.

[0176] In one possible embodiment of this disclosure, after the heterogeneous computing engine obtains the second operating system type of the second subject of the target resource, and determines that the first operating system type of the first subject and the second operating system type of the second subject of the target resource are consistent, it calls the first connection bridge to send the resource call request to the second subject of the target resource in order to call the resources of the second subject of the target resource.

[0177] For example, assuming the first entity's operating system is iOS, and the second entity of the target resource also has an iOS operating system, the heterogeneous computing engine calls the first connection bridge to send the resource request to the second entity of the target resource.

[0178] In another possible embodiment of this disclosure, after the heterogeneous computing engine obtains the second operating system type of the second principal of the target resource, if it determines that the first operating system type of the first principal and the second operating system type of the second principal of the target resource are inconsistent, it invokes the second connection bridge to send a resource invocation request to the second principal of the target resource to invoke the resources of the second principal of the target resource. Thus, when it is determined that the operating system types of the first principal and the second principal are inconsistent, the resource invocation request is sent to the second principal of the target resource through the second connection bridge established between the first principal and the second principal, thereby realizing cross-operating system resource invocation.

[0179] For example, assuming the first entity's operating system is iOS and the second entity's operating system is Windows, the heterogeneous computing engine calls the second connection bridge to send the resource request to the second entity of the target resource in order to invoke the resources of the second entity of the target resource.

[0180] The cross-operating system invocation method of this disclosure involves a heterogeneous computing engine receiving a resource invocation request from a first entity. The engine determines a second entity carrying the target resource based on the resource address of the target resource carried in the request. Then, based on the second operating system type of the second entity carrying the target resource, it invokes a first or second connection bridge to send the resource invocation request to the second entity carrying the target resource, thereby invoking the resource of the second entity carrying the target resource. Thus, after determining the second entity carrying the resource from the first entity, the engine determines whether to use a first or second connection bridge to send the resource invocation request to the second entity carrying the target resource, based on the operating system types of the first and second entities, thereby achieving cross-operating system resource invocation.

[0181] It should be noted that the above-mentioned possible implementations can be executed individually or in combination, and this disclosure does not limit them.

[0182] This disclosure presents an alternative method for cross-operating system invocation. Figure 9 This is a flowchart illustrating another cross-operating system invocation method provided by an embodiment of the present disclosure. This cross-operating system invocation method can be executed independently, or it can be executed in conjunction with any embodiment of the present disclosure or possible implementations within those embodiments, or it can be executed in conjunction with any technical solution in the related art.

[0183] like Figure 9 As shown, this cross-operating system invocation method may include the following steps:

[0184] Step 901: Obtain the first operating system type of the first subject.

[0185] Step 902: Obtain the second operating system type of the second subject.

[0186] The second subject can be one or more, and there is no limitation here.

[0187] Steps 901 to 902 can be implemented in any of the embodiments of this disclosure. This disclosure does not limit the implementation of these steps and will not elaborate further.

[0188] Step 903: If the first operating system type is consistent with the second operating system type, establish shared memory between the first principal and the second principal, and establish a first connection bridge through the shared memory.

[0189] In this embodiment of the disclosure, after the heterogeneous computing engine obtains the first operating system type of the first entity and the second operating system type of the second entity, when it determines that the first operating system type and the second operating system type are consistent, a storage area can be allocated in the heterogeneous computing engine to establish shared memory between the first entity and the second entity, so as to establish a first connection bridge through the shared memory.

[0190] For example, a heterogeneous computing engine can store resource information of the first entity and the second entity in shared memory, so that when resource scheduling is performed between the first entity and the second entity, the resource information can be obtained from the shared memory.

[0191] It should be noted that the shared memory may store hardware resources and / or software resources of the first entity and multiple second entities, but this is not limited in the embodiments disclosed herein.

[0192] Therefore, when the first operating system type of the first entity and the second operating system type of the second entity are consistent, a shared memory is established between the first entity and the second entity to establish a first connection bridge through the shared memory, thereby realizing resource scheduling between the first entity and the second entity through the shared memory and improving the efficiency of resource call.

[0193] It should be noted that the above-mentioned possible implementations can be executed individually or in combination, and this disclosure does not limit them.

[0194] This disclosure presents an alternative method for cross-operating system invocation. Figure 10 This is a flowchart illustrating another cross-operating system invocation method provided by an embodiment of the present disclosure. This cross-operating system invocation method can be executed independently, or it can be executed in conjunction with any embodiment of the present disclosure or possible implementations within those embodiments, or it can be executed in conjunction with any technical solution in the related art.

[0195] like Figure 10 As shown, this cross-operating system invocation method may include the following steps:

[0196] Step 1001: Obtain the first operating system type of the first subject.

[0197] Step 1002: Obtain the second operating system type of the second subject.

[0198] The second subject can be one or more, and there is no limitation here.

[0199] Steps 1001 to 1002 can be implemented in any of the embodiments of this disclosure. This disclosure does not limit the implementation of these steps and will not elaborate further.

[0200] Step 1003: If the first operating system type is consistent with the second operating system type, establish a hardware component mapping table between the first entity and the second entity, and establish a first connection bridge through the hardware component mapping table.

[0201] The hardware component mapping table contains the mapping relationships between the hardware components in the first and second entities.

[0202] In this embodiment of the disclosure, when the first operating system of the first entity and the second operating system of the second entity are of the same type but have different underlying hardware, the ability to dynamically select and connect to hardware support can be extended by establishing a first connection bridge through a hardware component mapping table. For example, the first operating system and the second operating system are both Linux operating systems, but under different GPU (Graphics Processing Unit) architectures, the hardware service backup of the first operating system in the hardware component mapping table can replace the hardware service of the second operating system, thereby providing a method for dynamically and automatically mapping the supported component library.

[0203] In this embodiment of the disclosure, after establishing a first connection bridge between the first subject and the second subject, the heterogeneous computing engine enters the second operating system of the second subject through the first connection bridge, detects multiple hardware components of the second subject, determines that there are hardware components in the second subject that have failed detection, and then determines the target hardware component mapped to the hardware component that failed detection through the mapping relationship of hardware components in the hardware component mapping table, until all multiple hardware components of the second subject have passed the detection.

[0204] In this embodiment of the disclosure, after the heterogeneous computing engine enters the first operating system of the first entity, it completes the hardware startup initialization of the first entity. The first operating system begins to load various services that use the hardware of the first entity and prepares to enter the second operating system of the second entity. When it is determined that the first operating system of the first entity and the second operating system of the second entity are of the same type, the second operating system of the second entity can be entered through the connection bridge.

[0205] In this embodiment of the disclosure, when the second operating system of the second subject is started for the first time, the first connection bridge loads and runs a service to detect the various hardware components of the second subject. Through the hardware detection process, it checks whether the functions of the various hardware components of the second subject can work normally in the second operating system.

[0206] If the functions of each hardware component of the second entity can be normal in the second operating system, the docking of the first connection bridge can be completed and the second operating system can be entered.

[0207] If any hardware component fails the hardware detection, a hardware component mapping table is recommended to the second operating system for backup and mapping operations using the hardware component entries in the table. If another hardware component fails the detection, and the hardware component mapping table has multiple mapping entries supporting that hardware component, each mapping entry is tried sequentially until the hardware component passes the detection. If there are still failed hardware components, the first connection bridge startup strategy algorithm traverses the services of the linked (or backup image) first and second operating systems for that hardware component until the hardware component is correctly supported by the second operating system and passes the hardware detection, completing dynamic adaptation. It is then marked as automatically adapting the first connection bridge, so that when the second operating system restarts, it directly enters the second operating system through the first connection bridge. This process can provide a user interface to actively trigger re-detection; after the second operating system boots normally, the updated hardware component mapping table can be updated to the operating system provider via the server, with user permission.

[0208] Therefore, when the first operating system type of the first entity and the second operating system type of the second entity are consistent, a hardware component mapping table is established between the first entity and the second entity. A first connection bridge is established through the hardware component mapping table, so that when the first operating system and the second operating system are of the same type but the underlying hardware is different, the ability to dynamically select and connect to hardware support can be extended.

[0209] It should be noted that the above-mentioned possible implementations can be executed individually or in combination, and this disclosure does not limit them.

[0210] This disclosure presents an alternative method for cross-operating system invocation. Figure 11 This is a flowchart illustrating another cross-operating system invocation method provided by an embodiment of the present disclosure. This cross-operating system invocation method can be executed independently, or it can be executed in conjunction with any embodiment of the present disclosure or possible implementations within those embodiments, or it can be executed in conjunction with any technical solution in the related art.

[0211] like Figure 11 As shown, this cross-operating system invocation method may include the following steps:

[0212] Step 1101: Obtain the first operating system type of the first subject.

[0213] Step 1102: Obtain the second operating system type of the second subject.

[0214] The second subject can be one or more, and there is no limitation here.

[0215] Steps 1101 to 1102 can be implemented in any of the embodiments of this disclosure. This disclosure does not limit the implementation of these steps and will not elaborate further.

[0216] Step 1103: If the first operating system type is inconsistent with the second operating system type, establish a routing adaptation table based on the resource address of the resource in the second entity.

[0217] The routing adaptation table is used to establish the second connection bridge, meaning the second connection bridge can be established through the routing adaptation table.

[0218] In this embodiment, after the heterogeneous computing engine sends resource reporting information to multiple second entities, it receives resource information from the multiple second entities, including the resource addresses of resources within each second entity. When the heterogeneous computing engine determines that the first operating system type of the first entity and the second operating system type of the second entity are inconsistent, it establishes a routing adaptation table based on the resource addresses of resources within the multiple second entities, and establishes a second connection bridge between the first entity and the second entity according to the routing adaptation table.

[0219] In this embodiment of the disclosure, the routing adaptation table may store the correspondence between the resource addresses of each target resource and the routing paths corresponding to each target resource. For example, when the hardware of the target resources of multiple second entities belongs to different manufacturers, the resource addresses of each hardware resource are not the same, and the routing path corresponding to the resource address of each hardware resource can be determined from the routing adaptation table.

[0220] Therefore, by establishing a routing adaptation table, during cross-operating system calls, the appropriate routing path is selected based on the upper-layer business logic to perform different module function business processing, and ultimately control different types of hardware and / or software.

[0221] It should be noted that the above-mentioned possible implementations can be executed individually or in combination, and this disclosure does not limit them.

[0222] This disclosure presents an alternative method for cross-operating system invocation. Figure 12 This is a flowchart illustrating another cross-operating system invocation method provided by an embodiment of the present disclosure. This cross-operating system invocation method can be executed independently, or it can be executed in conjunction with any embodiment of the present disclosure or possible implementations within those embodiments, or it can be executed in conjunction with any technical solution in the related art.

[0223] like Figure 12 As shown, this cross-operating system invocation method may also include the following steps:

[0224] Step 1201: Receive a resource call request from the first entity, wherein the resource call request contains the resource address of the target resource.

[0225] Step 1202: Determine the second entity carrying the target resource based on the resource address of the target resource.

[0226] Steps 1201 to 1202 can be implemented in any of the embodiments of this disclosure. This disclosure does not limit the implementation of these steps and will not elaborate further.

[0227] Step 1203: If the second operating system type of the second subject of the target resource is inconsistent with the first operating system type of the first subject, then obtain the resource address of the target resource from the resource call request.

[0228] The resource address of the target resource can be the IP address of the route of the second entity carrying the target resource.

[0229] In this embodiment of the disclosure, after the heterogeneous computing engine determines the second entity carrying the target resource based on the resource address of the target resource, and obtains the second operating system type of the second entity, if it determines that the second operating system type of the second entity of the target resource is inconsistent with the first operating system type of the first entity, then it obtains the resource address of the target resource from the resource call request. For example, the resource address of the target resource is the IP address of the router of the smart speaker.

[0230] Step 1204: Look up the routing adaptation table based on the resource address of the target resource to obtain the corresponding routing path from the routing adaptation table.

[0231] The routing adaptation table stores the correspondence between the resource address of the target resource and the routing path.

[0232] In this embodiment of the disclosure, after the heterogeneous computing engine obtains the resource address of the target resource from the resource call request, it can look up the routing adaptation table according to the resource address of the target resource, so as to obtain the routing path corresponding to the resource address of the target resource based on the relationship between the resource address of the target resource and the routing path stored in the routing adaptation table.

[0233] Step 1205: Send the resource call request to the second entity of the corresponding target resource according to the routing path.

[0234] In this embodiment of the disclosure, after the heterogeneous computing engine determines the routing path corresponding to the resource address of the target resource, it sends the resource call request to the second entity of the corresponding target resource according to the routing path.

[0235] It is understandable that when the first entity makes cross-operating system resource calls with different second entities, the adapted routing paths will also be different when the second entities are different.

[0236] Therefore, by looking up the routing adaptation table based on the resource address of the target resource, and sending the resource call request to the corresponding target resource's second entity according to the routing path determined in the routing adaptation table, the system can select the appropriate routing path and perform different module function business processing during cross-operating system calls, thereby controlling different types of hardware and / or software.

[0237] It should be noted that the above-mentioned possible implementations can be executed individually or in combination, and this disclosure does not limit them.

[0238] This disclosure presents an alternative method for cross-operating system invocation. Figure 13 This is a flowchart illustrating another cross-operating system invocation method provided by an embodiment of the present disclosure. This cross-operating system invocation method can be executed independently, or it can be executed in conjunction with any embodiment of the present disclosure or possible implementations within those embodiments, or it can be executed in conjunction with any technical solution in the related art.

[0239] like Figure 13 As shown, this cross-operating system invocation method may include the following steps:

[0240] Step 1301: Obtain the first operating system type of the first subject.

[0241] Step 1302: Obtain the second operating system type of the second subject.

[0242] The second subject can be one or more, and there is no limitation here.

[0243] Steps 1301 to 1302 can be implemented in any of the embodiments of this disclosure. This disclosure does not limit the implementation of these steps and will not elaborate further.

[0244] Step 1303: If the first operating system type is inconsistent with the second operating system type, obtain the IO interface of each resource in the second entity, and generate a corresponding virtual IO interface for each resource's IO interface.

[0245] In this embodiment of the disclosure, after the heterogeneous computing engine obtains the IO (Input / Output) interface of each resource in the second entity, it can generate a corresponding virtual IO interface for each resource's IO interface.

[0246] The I / O interface is used to input different commands and parameters through the CPU (Central Processing Unit) of the second main body, and to control the related I / O circuits and simple peripherals to perform corresponding operations. For example, I / O interface chips such as timers / counters, interrupt controllers, DMA controllers, and parallel interfaces can be obtained from the second main body.

[0247] Step 1304: Establish the mapping relationship between the first subject and the virtual IO interface.

[0248] In this embodiment of the disclosure, after generating a corresponding virtual IO interface for the IO interface of each resource in the second subject, a mapping relationship between the first subject and the virtual IO interface can be established.

[0249] Step 1305: Establish the second connection bridge through the mapping relationship.

[0250] In this embodiment of the disclosure, after establishing the mapping relationship between the first subject and the virtual IO interface, a second connection bridge can be established through the mapping relationship to realize cross-system resource calls between the first subject and the second subject through the second connection bridge.

[0251] As an example, assuming that a corresponding virtual I / O interface is generated for the timer's I / O interface of the second entity, a mapping relationship can be established between the first entity and the timer's virtual I / O interface, and a second connection bridge can be established based on this mapping relationship. Therefore, when the first operating system type of the first entity and the second operating system type of the second entity are inconsistent, cross-operating system resource calls between the first and second entities can be realized through the second connection bridge established by the mapping relationship between the first entity and the virtual I / O interface.

[0252] It should be noted that the above-mentioned possible implementations can be executed individually or in combination, and this disclosure does not limit them.

[0253] This disclosure presents an alternative method for cross-operating system invocation. Figure 14 This is a flowchart illustrating another cross-operating system invocation method provided by an embodiment of the present disclosure. This cross-operating system invocation method can be executed independently, or it can be executed in conjunction with any embodiment of the present disclosure or possible implementations within those embodiments, or it can be executed in conjunction with any technical solution in the related art.

[0254] like Figure 14 As shown, this cross-operating system invocation method may include the following steps:

[0255] Step 1401: Obtain the first operating system type of the first subject.

[0256] Step 1402: Obtain the second operating system type of the second subject.

[0257] The second subject can be one or more, and there is no limitation here.

[0258] Steps 1401 to 1402 can be implemented in any of the embodiments of this disclosure. This disclosure does not limit the implementation of these steps and will not elaborate further.

[0259] Step 1403: If the first operating system type is inconsistent with the second operating system type, establish a memory mapping relationship between the first principal and the second principal.

[0260] In this embodiment of the disclosure, when the heterogeneous computing engine determines that the first operating system type of the first subject is inconsistent with the second operating system type of the second subject, a memory mapping relationship can be established between the first subject and the second subject.

[0261] Optionally, the heterogeneous computing engine can dynamically determine a certain area of ​​memory, provide a memory access base address, establish a memory mapping relationship between a first entity and the memory access base address, and establish a memory mapping relationship between a second entity and the memory access base address, thereby establishing a memory mapping relationship between the first entity and the second entity.

[0262] Step 1404: Establish a second connection bridge based on the memory mapping relationship.

[0263] In this embodiment of the disclosure, after determining the memory mapping relationship between the first subject and the second subject, a second connection bridge can be established based on the memory mapping relationship to realize cross-operating system resource calls between the first subject and the second subject.

[0264] Therefore, when the first operating system type and the second operating system type are determined to be inconsistent, a memory mapping relationship is established between the first principal and the second principal. A second connection bridge is established based on the memory mapping relationship, thereby realizing memory sharing between the first principal and the second principal, so as to realize cross-operating system resource calls between the first principal and the second principal.

[0265] It should be noted that the above-mentioned possible implementations can be executed individually or in combination, and this disclosure does not limit them.

[0266] In one possible embodiment of this disclosure, the heterogeneous computing engine can establish a cross-process communication channel between the first and second entities to realize resource calls between the first and second entities. The following describes a method in conjunction with... Figure 15 A detailed introduction will be provided. Figure 15This is a flowchart illustrating another cross-operating system invocation method provided in an embodiment of this disclosure. In one embodiment of this disclosure, the method can be applied to a heterogeneous computing engine. Of course, in other embodiments of this disclosure, the method can also be used for other engines.

[0267] like Figure 15 As shown, this cross-operating system invocation method may also include the following steps:

[0268] Step 1501: Obtain the invocation instruction sent by the first subject with the first operating system through the first process.

[0269] A process is a program's execution activity on a certain set of data in a computer. It is the basic unit for system resource allocation and scheduling and the foundation of the operating system structure.

[0270] In this embodiment of the disclosure, when a first entity with a first operating system calls the hardware resources and / or software resources of a second entity, a calling instruction can be sent to the second entity through a first process, and the heterogeneous computing engine can obtain the calling instruction sent by the first entity. The calling instruction is used to call at least one of the hardware resources or software resources of the second entity.

[0271] Step 1502: Obtain the second process in the second entity with the second operating system, and establish a cross-process communication channel between the first process and the second process.

[0272] In one embodiment of this disclosure, the second subject may be an APP of a second operating system different from the first operating system, and this embodiment of the disclosure does not limit this.

[0273] In this embodiment of the disclosure, the heterogeneous computing engine can obtain the second process in the second subject to establish a cross-process communication channel between the first process and the second process based on the first process of the first subject and the second process of the second subject.

[0274] The inter-process communication channel is used for data transmission between the first process of the first subject and the second process of the second subject.

[0275] In this embodiment, when a first entity sends a call instruction through a first process to call a resource in a second entity, the second process in the second entity calls the service corresponding to the call instruction to complete the resource call. The heterogeneous computing engine stores or can obtain the mapping relationship between the first and second processes in a specific way, so that after the first entity sends a call instruction through the first process, the heterogeneous computing engine can obtain the second process in the second entity corresponding to the first process, thereby establishing a cross-process communication channel between the first and second processes.

[0276] It should be explained that in the embodiments of this disclosure, the first subject has a first operating system, the second subject has a second operating system, and the first operating system and the second operating system are different.

[0277] In this embodiment, the first operating system of the first entity and the second operating system of the second entity can be any operating system type. For example, the first operating system of the first entity can be any one of Android, iOS, Linux, Unix, macOS, and Windows. The second operating system of the second entity can be any operating system different from the first operating system of the first entity. Of course, the first operating system of the first entity and the second operating system of the second entity can also be any other operating system, which is not limited here.

[0278] For example, suppose the first entity is an APP set on a mobile terminal, and the second entity is an APP used to control a smart speaker. The first operating system of the APP set on the mobile terminal is the iOS operating system, and the second operating system of the APP used to control the smart speaker is the Android operating system. It is possible to obtain the first process of the first entity and the second process of the second entity that send the calling instructions. Then, a cross-process communication channel between the first process and the second process can be established so that the first entity and the second entity can make cross-operating system resource calls through the cross-process communication channel.

[0279] Step 1503: Send the call instruction to the second process through the inter-process communication channel so that the second process can call the service corresponding to the call instruction.

[0280] The service is obtained by encapsulating the hardware information in the second entity. For example, assuming the call instruction is to turn on the camera, the hardware information of the camera is encapsulated to obtain the service corresponding to the call instruction.

[0281] In this embodiment of the disclosure, after the heterogeneous computing engine obtains the call instruction sent by the first subject through the first process, it can send the call instruction to the second process through the cross-process communication channel established between the first process and the second process, so that the second process can obtain the service corresponding to the call instruction after receiving the call instruction sent by the cross-process communication channel.

[0282] In one possible implementation of this disclosure, the first entity can also obtain the hardware information of the second entity through an inter-process communication channel. In one possible scenario, after the heterogeneous computing engine obtains the hardware information of multiple hardware components within the second entity, it generates multiple services corresponding to those hardware components based on the hardware information. Thus, after generating the services corresponding to each hardware component using the hardware information, the second process can call the service corresponding to the call instruction to obtain the call results for each service. This not only enables cross-operating system service calls but also improves the efficiency of resource allocation.

[0283] It should be explained that the hardware information of the second entity obtained by the first entity through the inter-process communication channel includes not only the hardware information of the second entity itself, but also information that the hardware can acquire or that is acquired by running the hardware. For example, when acquiring the camera information of the second entity, not only the hardware information of the camera itself, such as the camera's pixel information, can be acquired, but also the information of the objects that the camera can capture, such as the image information captured by the camera.

[0284] Step 1504: Obtain the call result corresponding to the service through the second process, and send the call result to the first process through the cross-process communication channel.

[0285] In this embodiment of the disclosure, after the second process in the second subject obtains the service corresponding to the received call instruction, it can obtain the call result corresponding to the service and send the call result to the heterogeneous computing engine, so that the heterogeneous computing engine can send the call result to the first process of the first subject through the cross-process communication channel.

[0286] For example, suppose the first entity is an APP set on a mobile terminal, and the second entity is an APP used to control a smart speaker. The first entity sends a call instruction to the second process of the second entity through an inter-process communication channel to obtain the memory storage capacity of the second entity. After obtaining the memory storage capacity of the second entity, the second process of the second entity sends the memory storage capacity of the second entity to the first process of the first entity through the inter-process communication channel.

[0287] The cross-operating system invocation method of this disclosure obtains the invocation instruction sent by a first entity with a first operating system through a first process via a heterogeneous computing engine, obtains the second process of a second entity with a second operating system, and establishes a cross-process communication channel between the first and second processes. The invocation instruction is sent to the second process through the cross-process communication channel to invoke the service corresponding to the invocation instruction. The second process obtains the invocation result corresponding to the service and sends the invocation result back to the first process through the cross-process communication channel. Thus, data transmission between the first and second processes is realized through the established cross-process communication channel, thereby achieving cross-operating system invocation.

[0288] It should be noted that the above-mentioned possible implementations can be executed individually or in combination, and this disclosure does not limit them.

[0289] In one possible embodiment of this disclosure, when establishing an inter-process communication channel between the first process and the second process, an inter-process communication channel can be established between a client established in the first entity and a server established in the second entity, so as to realize cross-operating system service calls based on the inter-process communication channel. The following is in conjunction with... Figure 16 A detailed introduction will be provided. Figure 16 This is a flowchart illustrating yet another cross-operating system invocation method provided in an embodiment of this disclosure. In one embodiment of this disclosure, the method can be applied to a heterogeneous computing engine. Of course, in other embodiments of this disclosure, the method can also be used for other engines.

[0290] like Figure 16 As shown, this cross-operating system invocation method may also include the following steps:

[0291] Step 1601: Obtain the invocation instruction sent by the first entity with the first operating system through the first process.

[0292] Step 1602: Obtain the second process in the second entity that has a second operating system.

[0293] In this embodiment of the disclosure, the implementation process of steps 1601 to 1602 can refer to the implementation process of steps 1501 to 1502 in the above embodiments, or can be implemented in any of the embodiments of this disclosure. This embodiment of the disclosure does not limit this, nor will it be described in detail.

[0294] Step 1603: Create a client corresponding to the first process within the first entity.

[0295] Step 1604: Establish a server corresponding to the second process within the second entity.

[0296] In this embodiment of the disclosure, a client corresponding to the first process can be established in the first entity, and a server corresponding to the second process can be established in the second entity.

[0297] It should be explained that the execution order of steps 1603 and 1604 is not limited in this embodiment. Step 1603 can be executed first and then step 1604, or step 1604 can be executed first and then step 1603, or steps 1603 and 1604 can be executed simultaneously.

[0298] Step 1605: Establish a cross-process communication channel between the client and the server.

[0299] In this embodiment of the disclosure, after the heterogeneous computing engine establishes a client and a server, it can establish a cross-process communication channel through the client and the server to realize resource calls and information transmission between the first subject and the second subject based on the cross-process communication channel.

[0300] Step 1606: Convert the call instruction into a first inter-process communication instruction.

[0301] Step 1607: The client sends the first inter-process communication instruction to the server, so that the server converts the first inter-process communication instruction into a call instruction suitable for the second operating system and sends it to the second process.

[0302] In this embodiment, after the heterogeneous computing engine receives the invocation instruction sent by the first entity through the first process, it can convert the invocation instruction into a first inter-process communication instruction. Then, by establishing a client corresponding to the first process within the first entity, the first inter-process communication instruction is sent to the server. Upon receiving the first inter-process communication instruction, the server in the second entity can convert it into an invocation instruction suitable for the second operating system and send it to the second process.

[0303] It is understandable that the first operating system of the first entity and the second operating system of the second entity are not the same. After receiving the first inter-process communication instruction, the server converts the first inter-process communication instruction into a call instruction suitable for the second operating system, and sends the call instruction suitable for the second operating system to the second process. In this way, data transmission between the first entity and the second entity with different operating systems is realized through the client and the server.

[0304] Step 1608: Obtain the call result through the second process.

[0305] In this embodiment of the disclosure, after the second process of the second subject receives the call instruction applicable to the second operating system sent by the server, it can obtain the call result according to the call instruction applicable to the second operating system, and then send the call result to the heterogeneous computing engine.

[0306] Step 1609: Convert the call result into a second inter-process communication instruction.

[0307] In this embodiment of the disclosure, after the heterogeneous computing engine obtains the call result sent by the second process, it can convert the call result into a second cross-process communication instruction.

[0308] Step 1610: The server sends the second inter-process communication instruction to the client, so that the client converts the second inter-process communication instruction into a call result suitable for the first operating system and sends it to the first process.

[0309] In this embodiment, after the heterogeneous computing engine obtains the call result sent by the second process, it can convert the call result into a second inter-process communication instruction, and then send the second inter-process communication instruction to the client through the server. After receiving the second inter-process communication instruction, the client can convert the second inter-process communication instruction into a call result suitable for the first operating system and send it to the first process.

[0310] Therefore, a cross-process communication channel is established between the client established in the first entity and the server established in the second entity, so as to realize the communication between the first process and the second process based on the cross-process communication channel, thereby realizing cross-operating system service calls between the first entity and the second entity.

[0311] Figure 17 This is a schematic diagram illustrating the interaction of a cross-operating system invocation method provided in an embodiment of this disclosure. For example... Figure 17 As shown, this cross-operating system invocation method may include the following steps:

[0312] Step 1701: The first entity with the first operating system sends a call instruction through the first process.

[0313] Step 1702: Create a client corresponding to the first process within the first entity.

[0314] Step 1703: Establish a server corresponding to the second process in the second entity with the second operating system.

[0315] Step 1704: Convert the call instruction into a first inter-process communication instruction.

[0316] Step 1705: The client sends the first cross-process communication instruction to the server.

[0317] Step 1706: The server converts the first inter-process communication instruction into a call instruction suitable for the second operating system and sends it to the second process.

[0318] Step 1707: Obtain the call result through the second process.

[0319] Step 1708: Convert the call result into a second inter-process communication instruction.

[0320] Step 1709: The server sends the second inter-process communication instruction to the client.

[0321] Step 1710: The client converts the second inter-process communication instruction into a call result suitable for the first operating system and sends it to the first process.

[0322] The above Figures 1 to 17 Corresponding to the cross-operating system calling method provided in the embodiments, this disclosure also provides a cross-operating system calling device. Since the cross-operating system calling device provided in the embodiments of this disclosure is similar to the one described above... Figures 1 to 17 The cross-operating system calling method provided in the embodiments corresponds to the implementation method of the cross-operating system calling method, and therefore the implementation method of the cross-operating system calling method is also applicable to the cross-operating system calling device provided in the embodiments of this disclosure, and will not be described in detail in the embodiments of this disclosure.

[0323] Figure 18 This is a schematic diagram of a cross-operating system calling device provided in an embodiment of the present disclosure.

[0324] like Figure 18 As shown, the cross-operating system calling device 1800 may include: a receiving module 1810, a selection module 1820, and a sending module 1830.

[0325] The receiving module 1810 is used to receive a calling instruction sent by a first entity having a first operating system;

[0326] Select module 1820 to select the corresponding cross-operating system calling method;

[0327] The sending module 1830 is used to send a call instruction to a second entity having a second operating system according to the selected cross-operating system call method.

[0328] In this embodiment of the disclosure, the selection module 1820 can also be used to: select the corresponding cross-operating system calling method according to the type of the second operating system.

[0329] In this embodiment of the disclosure, the selection module 1820 can also be used to: select the corresponding cross-operating system calling method according to the hardware resources corresponding to the calling instruction.

[0330] In this embodiment of the disclosure, the sending module 1830 may further include:

[0331] The first receiving unit is configured to receive a first calling instruction from an application in the first operating system, wherein the first calling instruction corresponds to a first interface for the first operating system.

[0332] The first acquisition unit is used to acquire the second interface of the second operating system corresponding to the first interface.

[0333] The first sending unit sends the call instruction to the second subject through the second interface.

[0334] In this embodiment of the disclosure, the sending module 1830 may further include:

[0335] The second acquisition unit is used to acquire the target file corresponding to the second interface;

[0336] The modification unit is used to modify the process address in the target file to change the process address to the return address of the heterogeneous computing engine;

[0337] The return unit is used to execute the modified target file, and generate a first return result from the second return result of the target file received at the return address and send it to the application in the first operating system.

[0338] In this embodiment of the disclosure, the second acquisition unit can also be used to: determine the dynamic shared library corresponding to the second interface; and acquire the target file corresponding to the dynamic shared library.

[0339] In this embodiment of the disclosure, the first acquisition unit may further be used to: acquire the first process address corresponding to the first call instruction, wherein the first process address is used to receive the first return result corresponding to the first call instruction in the first operating system; generate a second call instruction according to the first call instruction, and acquire the second interface of the second call instruction according to the first interface; acquire the second process address corresponding to the second call instruction, and establish a correspondence between the first process address and the second process address, wherein the second process address is used to receive the second return result corresponding to the second call instruction in the second operating system.

[0340] In this embodiment of the disclosure, the modification unit can also be used to: load the target file into memory; obtain the global offset list (GOT) corresponding to the target file; obtain the process address in memory according to the GOT, and modify the process address in memory to a second process address.

[0341] In this embodiment of the disclosure, the first operating system has a first system library, the second operating system has a second system library, and the modification unit can also be used to: obtain the address of the second system library in memory according to the GOT; and modify the address of the second system library to the address of the first system library.

[0342] In this embodiment of the disclosure, the return unit can also be used to: execute the modified target file to generate a second return result; determine the corresponding first process address according to the correspondence between the first process address and the second process address; generate a first return result according to the content of the first process address and the second return result, and feed it back to the first process address.

[0343] In this embodiment of the disclosure, the sending module 1830 may further include:

[0344] The first establishment unit is used to establish a first connection bridge between the first entity and the second entity if the type of the first operating system is the same as the type of the second operating system. The first entity sends a call instruction to the second entity through the first connection bridge. The first connection bridge is used for resource calls between the first entity and the second entity, which have the same operating system type.

[0345] The second establishment unit is used to establish a second connection bridge between the first entity and the second entity if the type of the first operating system is inconsistent with the type of the second operating system. The first entity sends the calling instruction to the second entity through the second connection bridge. The second connection bridge is used for resource calling between the first entity and the second entity with different operating system types.

[0346] In this embodiment of the disclosure, there are multiple second entities, and the sending module 1830 may further include:

[0347] The second sending unit is used to send resource reporting messages to multiple second entities.

[0348] The second receiving unit is used to receive resource information sent by multiple second entities.

[0349] The third sending unit is used to send resource information sent by multiple second entities to the first entity, so that the first entity can generate a resource call list based on the resource information of multiple second entities for the first entity to call.

[0350] In this embodiment of the disclosure, there are multiple second entities, and the sending module 1830 may further include:

[0351] The third receiving unit is used to receive the resource call request from the first subject, wherein the resource call request contains the resource address of the target resource.

[0352] The determining unit is used to determine the second entity carrying the target resource based on the resource address of the target resource.

[0353] The calling unit is used to call the first connection bridge or the second connection bridge to send the resource calling request to the second subject of the target resource according to the second operating system type of the second subject of the target resource, so as to call the resource of the second subject of the target resource.

[0354] In this embodiment of the disclosure, the first establishment unit can also be used to: establish shared memory between the first subject and the second subject, and establish a first connection bridge through the shared memory.

[0355] In this embodiment of the disclosure, the resource information includes the resource address of the resource in the second subject. The second establishment unit can also be used to: establish a routing adaptation table based on the resource address of the resource in the second subject, wherein the routing adaptation table is used to establish a second connection bridge.

[0356] In this embodiment of the disclosure, the calling unit can also be used to: if the second operating system type of the second subject of the target resource is inconsistent with the first operating system type of the first subject, obtain the resource address of the target resource from the resource calling request; look up the routing adaptation table according to the resource address of the target resource to obtain the corresponding routing path from the routing adaptation table; and send the resource calling request to the corresponding second subject of the target resource according to the routing path.

[0357] In this embodiment of the disclosure, the second establishment unit can also be used to: obtain the IO interface of each resource in the second subject, and generate a corresponding virtual IO interface for each resource's IO interface; establish a mapping relationship between the first subject and the virtual IO interface; and establish a second connection bridge through the mapping relationship.

[0358] In this embodiment of the disclosure, the second establishment unit can also be used to: establish a memory mapping relationship between the first subject and the second subject; and establish a second connection bridge based on the memory mapping relationship.

[0359] In this embodiment of the disclosure, the sending module 1830 may further include:

[0360] The third acquisition unit can be used to acquire the calling instructions sent by the first subject through the first process.

[0361] The third establishment unit can be used to obtain the second process in the second subject and establish a cross-process communication channel between the first process and the second process.

[0362] The fourth sending unit can be used to send the call instruction to the second process through the inter-process communication channel, so that the second process can call the service corresponding to the call instruction; wherein, the service is obtained by encapsulating the hardware information in the second entity.

[0363] The fifth sending unit can be used to obtain the call result corresponding to the service through the second process and send the call result to the first process through the cross-process communication channel.

[0364] In this embodiment of the disclosure, the sending module 1830 may further include:

[0365] The third acquisition unit is used to acquire hardware information of multiple hardware components in the second entity.

[0366] The generation unit is used to generate multiple services corresponding to multiple hardware components based on hardware information.

[0367] In this embodiment of the disclosure, the third establishment unit can also be used to: establish a client corresponding to the first process in the first subject; establish a server corresponding to the second process in the second subject; and establish a cross-process communication channel through the client and the server.

[0368] In this embodiment of the disclosure, the fourth sending unit can also be used to: convert the calling instruction into a first inter-process communication instruction; send the first inter-process communication instruction to the server through the client, so that the server converts the first inter-process communication instruction into a calling instruction suitable for the second operating system and sends it to the second process.

[0369] In this embodiment of the disclosure, the fifth sending unit can also be used to: convert the call result into a second inter-process communication instruction; send the second inter-process communication instruction to the client through the server, so that the client converts the second inter-process communication instruction into a call result suitable for the first operating system and sends it to the first process.

[0370] The cross-operating system invocation device of this disclosure receives an invocation command sent by a first entity having a first operating system through a heterogeneous computing engine. After selecting a corresponding cross-operating system invocation method, it sends the invocation command to a second entity having a second operating system according to the selected cross-operating system invocation method. Thus, after the heterogeneous computing engine determines the cross-operating system invocation method applicable to the first and second entities, it uses that cross-operating system invocation method to realize cross-operating system resource invocation.

[0371] It should be noted that the above-mentioned possible implementations can be executed individually or in combination, and this disclosure does not limit them.

[0372] To implement the above embodiments, this disclosure also proposes an electronic device.

[0373] The electronic device provided in this disclosure includes a processor; a memory for storing processor-executable invocation instructions; wherein the processor is configured to execute the invocation instructions to implement the cross-operating system invocation method described in any of the above embodiments.

[0374] To implement the above embodiments, this disclosure also proposes a non-transitory computer-readable storage medium.

[0375] The non-transitory computer-readable storage medium provided in this disclosure enables the electronic device to execute the cross-operating system invocation method described in any of the above embodiments when the invocation instructions in the storage medium are executed by the processor of the electronic device.

[0376] To implement the above embodiments, this disclosure also proposes a computer program product, including a computer program that, when executed by a processor, implements the cross-operating system invocation method proposed in the above embodiments.

[0377] Figure 19 This is a block diagram of an electronic device provided in an embodiment of the present disclosure. For example, the electronic device 1900 may be a mobile phone, a computer, a digital broadcast user equipment, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0378] Reference Figure 19 The electronic device 1900 may include at least one of the following components: a processing component 1902, a memory 1904, a power supply component 1906, a multimedia component 1908, an audio component 1910, an input / output (I / O) interface 1912, a sensor component 1914, and a communication component 1916.

[0379] Processing component 1902 typically controls the overall operation of electronic device 1900, such as operations associated with display, telephone calls, data communication, camera operation, and recording operations. Processing component 1902 may include at least one processor 1920 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 1902 may include at least one module to facilitate interaction between processing component 1902 and other components. For example, processing component 1902 may include a multimedia module to facilitate interaction between multimedia component 1908 and processing component 1902.

[0380] Memory 1904 is configured to store various types of data to support the operation of electronic device 1900. Examples of this data include instructions for any application or method operating on electronic device 1900, contact data, phone book data, messages, pictures, videos, etc. Memory 1904 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0381] Power supply component 1905 provides power to various components of electronic device 1900. Power supply component 1906 may include a power management system, at least one power supply, and other components associated with generating, managing, and distributing power to electronic device 1900.

[0382] Multimedia component 1908 includes a screen that provides an output interface between the electronic device 1900 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes at least one touch sensor to sense touch, swipe, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or swipe action but also detect the wake-up time and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 1908 includes a front-facing camera and / or a rear-facing camera. When the electronic device 1900 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0383] Audio component 1910 is configured to output and / or input audio signals. For example, audio component 1910 includes a microphone (MIC) configured to receive external audio signals when electronic device 1900 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 1904 or transmitted via communication component 1916. In some embodiments, audio component 1910 also includes a speaker for outputting audio signals.

[0384] I / O interface 1912 provides an interface between processing component 1902 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0385] Sensor assembly 1914 includes at least one sensor for providing state assessment of various aspects of electronic device 1900. For example, sensor assembly 1914 can detect the on / off state of electronic device 1900, the relative positioning of components such as the display and keypad of electronic device 1900, changes in position of electronic device 1900 or a component of electronic device 1900, the presence or absence of user contact with electronic device 1900, orientation or acceleration / deceleration of electronic device 1900, and temperature changes of electronic device 1900. Sensor assembly 1914 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 1914 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 1914 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0386] Communication component 1916 is configured to facilitate wired or wireless communication between electronic device 1900 and other devices. Electronic device 1900 can access wireless networks based on communication standards, such as WiFi, 2G, or 3G, or combinations thereof. In one exemplary embodiment, communication component 1916 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 1916 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0387] In an exemplary embodiment, the electronic device 1900 may be implemented by at least one application-specific integrated circuit (ASIC), digital signal processor (DSP), digital signal processing device (DSPD), programmable logic device (PLD), field-programmable gate array (FPGA), controller, microcontroller, microprocessor, or other electronic component for executing the cross-operating system invocation method of any embodiment.

[0388] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 1904 including instructions, which can be executed by a processor 1920 of an electronic device 1900 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0389] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0390] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A cross-operating system calling method, characterized in that, The method is executed by a heterogeneous computing engine, and the method includes: Receive a calling instruction sent by a first entity having a first operating system, the calling instruction being used to call at least one of the hardware resources or software resources of a second entity having a second operating system; The corresponding cross-operating system calling method is selected according to the type of the second operating system or the hardware resources corresponding to the calling instruction. The cross-operating system calling method includes at least one of the following: establishing a connection bridge between the first subject and the second subject, and establishing a cross-process communication channel between the first subject and the second subject. The call instruction is sent to a second entity with a second operating system according to the selected cross-operating system call method.

2. The method as described in claim 1, characterized in that, The selection of the corresponding cross-operating system invocation method includes: Select the corresponding cross-operating system calling method based on the type of the second operating system.

3. The method as described in claim 1, characterized in that, The selection of the corresponding cross-operating system calling method also includes: The corresponding cross-operating system calling method is selected based on the hardware resources corresponding to the calling instruction.

4. The method according to any one of claims 1-3, characterized in that, Sending the invocation instruction to a second entity with a second operating system according to the selected cross-operating system invocation method includes: Receive a first invocation instruction from an application in a first operating system, wherein the first invocation instruction corresponds to a first interface for the first operating system; Obtain the second interface of the second operating system corresponding to the first interface; The first invocation instruction is sent to the second entity through the second interface.

5. The method as described in claim 4, characterized in that, After sending the first invocation instruction to the second entity through the second interface, the method further includes: Obtain the target file corresponding to the second interface; The process address in the target file is modified to be the return address of the heterogeneous computing engine; The modified target file is executed, and the second return result of the target file received at the return address is used to generate a first return result, which is then sent to the application in the first operating system.

6. The method as described in claim 5, characterized in that, The step of obtaining the target file corresponding to the second interface includes: Identify the dynamic shared library corresponding to the second interface; Obtain the target file corresponding to the dynamic shared library.

7. The method as described in claim 6, characterized in that, The step of obtaining the second interface for the second operating system corresponding to the first interface includes: Obtain the first process address corresponding to the first call instruction, wherein the first process address is used to receive the first return result corresponding to the first call instruction in the first operating system; Generate a second call instruction based on the first call instruction, and obtain the second interface of the second call instruction based on the first interface; Obtain the second process address corresponding to the second call instruction, and establish a correspondence between the first process address and the second process address, wherein the second process address is used to receive the second return result corresponding to the second call instruction in the second operating system.

8. The method as described in claim 7, characterized in that, Modifying the process address in the target file includes: Load the target file into memory; Obtain the Global Offset List (GOT) corresponding to the target file; The process address in memory is obtained according to the GOT, and the process address in memory is modified to the second process address.

9. The method as described in claim 8, characterized in that, The first operating system has a first system library, the second operating system has a second system library, and the method further includes: The address of the second system library in memory is obtained based on the GOT; Change the address of the second system library to the address of the first system library.

10. The method as described in claim 8, characterized in that, The process of executing the modified target file, generating a first return result from the second return result of the target file received at the return address, and sending it to the application in the first operating system includes: Execute the modified target file to generate the second return result; Based on the correspondence between the first process address and the second process address, determine the corresponding first process address; The first return result is generated based on the first process address and the content of the second return result, and then fed back to the first process address.

11. The method according to any one of claims 1-3, characterized in that, Sending the invocation instruction to a second entity with a second operating system according to the selected cross-operating system invocation method includes: If the type of the first operating system is the same as the type of the second operating system, a first connection bridge is established between the first entity and the second entity, and the first entity sends the invocation instruction to the second entity through the first connection bridge; the first connection bridge is used for resource invocation between the first entity and the second entity with the same operating system type; If the type of the first operating system is inconsistent with the type of the second operating system, a second connection bridge is established between the first entity and the second entity, and the first entity sends the invocation instruction to the second entity through the second connection bridge; the second connection bridge is used for resource invocation between the first entity and the second entity with different operating system types.

12. The method as described in claim 11, characterized in that, The second subject can be multiple, and the method further includes: Send resource reporting messages to multiple secondary entities; Receive resource information sent by the plurality of second entities; The resource information sent by the plurality of second entities is sent to the first entity, so that the first entity generates a resource call list based on the resource information of the plurality of second entities, for the first entity to call.

13. The method as described in claim 11, characterized in that, The second subject can be multiple, and the method further includes: Receive a resource request from the first entity, wherein the resource request contains the resource address of the target resource; The second entity carrying the target resource is determined based on the resource address of the target resource; Based on the type of the second operating system of the second subject of the target resource, the first connection bridge or the second connection bridge is invoked to send the resource invocation request to the second subject of the target resource, so as to invoke the resources of the second subject of the target resource.

14. The method as described in claim 11, characterized in that, Establishing a first connection bridge between the first body and the second body includes: Establish shared memory between the first entity and the second entity, and establish the first connection bridge through the shared memory.

15. The method as described in claim 11, characterized in that, The establishment of the first connecting bridge between the first body and the second body further includes: Establish a hardware component mapping table between the first entity and the second entity, wherein the hardware component mapping table contains the mapping relationship between the hardware components in the first entity and the second entity; The first connection bridge is established using the hardware component mapping table.

16. The method as described in claim 15, characterized in that, After establishing the first connecting bridge between the first body and the second body, the method further includes: Access to the second operating system of the second entity via the first connection bridge, and detection of multiple hardware components of the second entity; If it is determined that there is a hardware component in the second entity that failed the detection, then the target hardware component mapped to the hardware component that failed the detection is determined through the mapping relationship of the hardware components in the hardware component mapping table, until all the multiple hardware components of the second entity pass the detection.

17. The method as described in claim 12, characterized in that, The resource information includes the resource address of the resource in the second entity, and the establishment of a second connection bridge between the first entity and the second entity includes: A routing adaptation table is established based on the resource addresses of the resources in the second entity, wherein the routing adaptation table is used to establish the second connection bridge.

18. The method as described in claim 13, characterized in that, The step of invoking the second connection bridge to send the resource request to the second entity of the target resource based on the type of the second operating system of the second entity of the target resource includes: If the type of the second operating system of the second entity of the target resource is inconsistent with the type of the first operating system of the first entity, then the resource address of the target resource is obtained from the resource call request; The routing adaptation table is looked up based on the resource address of the target resource in order to obtain the corresponding routing path from the routing adaptation table; The resource request is sent to the second entity corresponding to the target resource according to the routing path.

19. The method as described in claim 12 or 13, characterized in that, The establishment of a second connecting bridge between the first body and the second body includes: Obtain the IO interface of each resource in the second entity, and generate a corresponding virtual IO interface for each resource's IO interface; Establish a mapping relationship between the first entity and the virtual I / O interface; The second connection bridge is established through the mapping relationship.

20. The method as described in claim 17, characterized in that, The establishment of a second connecting bridge between the first body and the second body includes: Establish a memory mapping relationship between the first entity and the second entity; The second connection bridge is established based on the memory mapping relationship.

21. The method according to any one of claims 1-3, characterized in that, Sending the invocation instruction to a second entity with a second operating system according to the selected cross-operating system invocation method includes: Obtain the invocation instruction sent by the first entity through the first process; Obtain the second process within the second entity and establish a cross-process communication channel between the first process and the second process; The invocation instruction is sent to the second process through the inter-process communication channel so that the second process can invoke the service corresponding to the invocation instruction; wherein, the service is obtained by encapsulating the hardware information in the second entity.

22. The method as described in claim 21, characterized in that, After sending the call instruction to the second process through the inter-process communication channel, the method further includes: The second process obtains the call result corresponding to the service and sends the call result to the first process through the cross-process communication channel.

23. The method as described in claim 21, characterized in that, The method further includes: Obtain hardware information of multiple hardware components within the second entity; Based on the hardware information, multiple services corresponding to the multiple hardware components are generated.

24. The method as described in claim 22, characterized in that, The establishment of the cross-process communication channel between the first process and the second process includes: Establish a client corresponding to the first process within the first entity; Establish a server corresponding to the second process within the second entity; The cross-process communication channel is established through the client and the server.

25. The method as described in claim 24, characterized in that, Sending the call instruction to the second process through the inter-process communication channel includes: Convert the invocation instruction into a first inter-process communication instruction; The client sends the first inter-process communication instruction to the server, so that the server converts the first inter-process communication instruction into a call instruction suitable for the second operating system and sends it to the second process.

26. The method as described in claim 25, characterized in that, Sending the call result to the first process through the cross-process communication channel includes: The call result is converted into a second inter-process communication instruction; The server sends the second inter-process communication instruction to the client, so that the client converts the second inter-process communication instruction into a call result suitable for the first operating system and sends it to the first process.

27. An apparatus for cross-operating system calls via a heterogeneous computing engine, characterized in that, The device includes: A receiving module is configured to receive a calling instruction sent by a first entity having a first operating system, the calling instruction being used to call at least one of the hardware resources or software resources of a second entity having a second operating system. The selection module is used to select a corresponding cross-operating system calling method based on the type of the second operating system or the hardware resources corresponding to the calling instruction. The cross-operating system calling method includes at least one of the following: establishing a connection bridge between the first subject and the second subject, and establishing a cross-process communication channel between the first subject and the second subject. The sending module is used to send the calling instruction to the second entity having a second operating system according to the selected cross-operating system calling method.

28. The apparatus as claimed in claim 27, characterized in that, The selection module is also used for: Select the corresponding cross-operating system calling method based on the type of the second operating system.

29. The apparatus as claimed in claim 27, characterized in that, The selection module is also used for: The corresponding cross-operating system calling method is selected based on the hardware resources corresponding to the calling instruction.

30. The apparatus according to any one of claims 27-29, characterized in that, The sending module further includes: The first receiving unit is configured to receive a first calling instruction from an application in the first operating system, wherein the first calling instruction corresponds to a first interface for the first operating system; The first acquisition unit is used to acquire the second interface of the second operating system corresponding to the first interface; The first sending unit is used to send the first calling instruction to the second subject through the second interface.

31. The apparatus as claimed in claim 30, characterized in that, The sending module further includes: The second acquisition unit is used to acquire the target file corresponding to the second interface; The modification unit is used to modify the process address in the target file to change the process address to the return address of the heterogeneous computing engine; The return unit is used to execute the modified target file, generate a first return result from the second return result of the target file received at the return address, and send it to the application in the first operating system.

32. The apparatus as claimed in claim 31, characterized in that, The second acquisition unit is further configured to: Identify the dynamic shared library corresponding to the second interface; Obtain the target file corresponding to the dynamic shared library.

33. The apparatus as claimed in claim 31, characterized in that, The first acquisition unit is further configured to: Obtain the first process address corresponding to the first call instruction, wherein the first process address is used to receive the first return result corresponding to the first call instruction in the first operating system; Generate a second call instruction based on the first call instruction, and obtain the second interface of the second call instruction based on the first interface; Obtain the second process address corresponding to the second call instruction, and establish a correspondence between the first process address and the second process address, wherein the second process address is used to receive the second return result corresponding to the second call instruction in the second operating system.

34. The apparatus as claimed in claim 33, characterized in that, The modification unit is further configured to: Load the target file into memory; Obtain the Global Offset List (GOT) corresponding to the target file; The process address in memory is obtained according to the GOT, and the process address in memory is modified to the second process address.

35. The apparatus as claimed in claim 34, characterized in that, The first operating system has a first system library, the second operating system has a second system library, and the modification unit is further configured to: The address of the second system library in memory is obtained based on the GOT; Change the address of the second system library to the address of the first system library.

36. The apparatus as claimed in claim 34, characterized in that, The return unit is also used for: Execute the modified target file to generate the second return result; Based on the correspondence between the first process address and the second process address, determine the corresponding first process address; The first return result is generated based on the first process address and the content of the second return result, and then fed back to the first process address.

37. The apparatus according to any one of claims 27-29, characterized in that, The sending module further includes: The first establishment unit is configured to establish a first connection bridge between the first entity and the second entity if the type of the first operating system is consistent with the type of the second operating system, and the first entity sends the invocation instruction to the second entity through the first connection bridge; the first connection bridge is used for resource invocation between the first entity and the second entity having the same operating system type; The second establishment unit is used to establish a second connection bridge between the first entity and the second entity if the type of the first operating system is inconsistent with the type of the second operating system. The first entity sends the call instruction to the second entity through the second connection bridge. The second connection bridge is used for resource calls between the first entity and the second entity with different operating system types.

38. The apparatus as claimed in claim 37, characterized in that, The second entity may be multiple, and the sending module further includes: The second sending unit is used to send resource reporting messages to multiple second entities; The second receiving unit is used to receive resource information sent by the plurality of second entities; The third sending unit sends the resource information sent by the plurality of second entities to the first entity, so that the first entity generates a resource call list based on the resource information of the plurality of second entities for the first entity to call.

39. The apparatus as claimed in claim 37, characterized in that, The second entity may be multiple, and the sending module further includes: The third receiving unit is used to receive the resource call request of the first subject, wherein the resource call request contains the resource address of the target resource; The determining unit is configured to determine the second entity carrying the target resource based on the resource address of the target resource; The invocation unit is configured to, based on the type of the second operating system of the second subject of the target resource, invoke the first connection bridge or the second connection bridge to send the resource invocation request to the second subject of the target resource, so as to invoke the resources of the second subject of the target resource.

40. The apparatus as claimed in claim 37, characterized in that, The first establishing unit is used for: Establish shared memory between the first entity and the second entity, and establish the first connection bridge through the shared memory.

41. The apparatus as claimed in claim 37, characterized in that, The first establishing unit is further configured to: Establish a hardware component mapping table between the first entity and the second entity, wherein the hardware component mapping table contains the mapping relationship between the hardware components in the first entity and the second entity; The first connection bridge is established using the hardware component mapping table.

42. The apparatus as claimed in claim 41, characterized in that, The device further includes: The detection module is used to access the second operating system of the second entity through the first connection bridge and detect multiple hardware components of the second entity. The component determination module is used to determine if there is a hardware component in the second entity that failed the detection. Then, through the mapping relationship of the hardware components in the hardware component mapping table, it determines the target hardware component mapped to the hardware component that failed the detection, until all the multiple hardware components of the second entity pass the detection.

43. The apparatus as claimed in claim 38, characterized in that, The resource information includes the resource address of the resource in the second entity. The second establishment unit is also used for: A routing adaptation table is established based on the resource addresses of the resources in the second entity, wherein the routing adaptation table is used to establish the second connection bridge.

44. The apparatus as claimed in claim 39, characterized in that, The calling unit is also used for: If the type of the second operating system of the second entity of the target resource is inconsistent with the type of the first operating system of the first entity, then the resource address of the target resource is obtained from the resource call request; The routing adaptation table is looked up based on the resource address of the target resource in order to obtain the corresponding routing path from the routing adaptation table; The resource request is sent to the second entity corresponding to the target resource according to the routing path.

45. The apparatus as claimed in claim 38 or 39, characterized in that, The second establishing unit is further configured to: Obtain the IO interface of each resource in the second entity, and generate a corresponding virtual IO interface for each resource's IO interface; Establish a mapping relationship between the first entity and the virtual I / O interface; The second connection bridge is established through the mapping relationship.

46. ​​The apparatus as claimed in claim 37, characterized in that, The second establishing unit is further configured to: Establish a memory mapping relationship between the first entity and the second entity; The second connection bridge is established based on the memory mapping relationship.

47. The apparatus according to any one of claims 27-29, characterized in that, The sending module further includes: The third acquisition unit is used to acquire the invocation instruction sent by the first subject through the first process; The third establishment unit is used to obtain the second process in the second subject and establish a cross-process communication channel between the first process and the second process; The fourth sending unit is used to send the call instruction to the second process through the inter-process communication channel, so that the second process can call the service corresponding to the call instruction; wherein the service is obtained by encapsulating the hardware information in the second entity.

48. The apparatus as claimed in claim 47, characterized in that, The sending module further includes: The fifth sending unit is used to obtain the call result corresponding to the service through the second process, and send the call result to the first process through the cross-process communication channel.

49. The apparatus as claimed in claim 47, characterized in that, The sending module further includes: The third acquisition unit is used to acquire hardware information of multiple hardware components in the second main body; The generation unit is used to generate multiple services corresponding to the multiple hardware components based on the hardware information.

50. The apparatus as claimed in claim 47, characterized in that, The third establishing unit is also used for: Establish a client corresponding to the first process within the first entity; Establish a server corresponding to the second process within the second entity; The cross-process communication channel is established through the client and the server.

51. The apparatus as claimed in claim 50, characterized in that, The fourth transmitting unit is further configured to: Convert the invocation instruction into a first inter-process communication instruction; The client sends the first inter-process communication instruction to the server, so that the server converts the first inter-process communication instruction into a call instruction suitable for the second operating system and sends it to the second process.

52. The apparatus as claimed in claim 48, characterized in that, The fifth transmitting unit is further configured to: The call result is converted into a second inter-process communication instruction; The server sends the second inter-process communication instruction to the client, so that the client converts the second inter-process communication instruction into a call result suitable for the first operating system and sends it to the first process.

53. An electronic device, characterized in that, include: processor; Memory used to store the processor-executable call instructions; The processor is configured to execute the invocation instructions to implement the cross-operating system invocation method as described in any one of claims 1 to 26.

54. A non-transitory computer-readable storage medium, characterized in that, When the call instructions in the storage medium are executed by the processor of the electronic device, the electronic device is able to perform the cross-operating system call method as described in any one of claims 1 to 26.

Images