CN118445032B - Service providing method, apparatus, electronic device, storage medium, and computer program product - Google Patents
Service providing method, apparatus, electronic device, storage medium, and computer program product Download PDFInfo
- Publication number
- CN118445032B CN118445032B CN202410902864.6A CN202410902864A CN118445032B CN 118445032 B CN118445032 B CN 118445032B CN 202410902864 A CN202410902864 A CN 202410902864A CN 118445032 B CN118445032 B CN 118445032B
- Authority
- CN
- China
- Prior art keywords
- container
- target
- node
- operating system
- virtual
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 37
- 238000004590 computer program Methods 0.000 title claims abstract description 18
- 238000013507 mapping Methods 0.000 claims description 76
- 238000004891 communication Methods 0.000 claims description 22
- 230000015654 memory Effects 0.000 claims description 21
- 230000004044 response Effects 0.000 claims description 9
- 239000011230 binding agent Substances 0.000 description 61
- 238000010586 diagram Methods 0.000 description 12
- 230000006870 function Effects 0.000 description 8
- 230000006978 adaptation Effects 0.000 description 7
- 238000005516 engineering process Methods 0.000 description 5
- 230000008569 process Effects 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 239000011664 nicotinic acid Substances 0.000 description 2
- 238000005192 partition Methods 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000003786 synthesis reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45562—Creating, deleting, cloning virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The present disclosure relates to a service providing method, apparatus, electronic device, storage medium and computer program product, the method comprising: acquiring a call request sent by a first operating system in a first container, wherein the call request is used for calling a target hardware service of a second operating system in a second container; determining a target transit node matched with the target hardware service under the second container; sending a call request from the first container to the second container by accessing the target transit node; the target hardware service result is sent from the second container to the first container by accessing the target transit node. In this way, by running the first operating system in the first container and running the second operating system in the second container, and connecting the first container and the second container through the transit node, the first operating system can remotely call services in the second operating system, that is, can call the second operating system driver to access the hardware resource.
Description
Technical Field
The present disclosure relates to the field of computer technology, and more particularly, to a service providing method, apparatus, electronic device, storage medium, and computer program product.
Background
With the development of container virtualization technology and the continuous improvement of the embedded system technology level, it becomes possible to run two or more containers on an embedded hardware platform. Typically, the containers running on the computer are isolated from each other and perform their respective functions independently. And, communication between containers may be accomplished through a network.
Currently, hardware drivers provided by hardware vendors are basically android-enabled, where the libraries of graphics, multimedia related drivers or call drivers are mostly closed-source, and do not match with the non-android operating system, which may result in failure to directly call these hardware resources under the non-android operating system.
Disclosure of Invention
The present disclosure provides a service providing method, apparatus, electronic device, storage medium and computer program product to at least solve the problem that in the above related art, these hardware resources cannot be directly invoked under a non-android operating system.
According to a first aspect of an embodiment of the present disclosure, there is provided a service providing method applied to a service platform, where the service platform runs at least a first container and a second container, a first operating system is run in the first container, and a second operating system different from the first operating system is run in the second container, including: acquiring a call request sent by the first operating system in the first container, wherein the call request is used for calling a target hardware service of the second operating system in the second container; determining a target transit node under the second container, which is matched with the target hardware service, wherein the transit node is used for realizing communication between the first container and the second container; sending the call request from the first container to the second container by accessing the target transit node; and sending a target hardware service result from the second container to the first container by accessing the target transit node, wherein the hardware service result is a result generated by the second operating system in the second container executing the target hardware service in response to the call request.
Optionally, the first container includes a first virtual node corresponding to the target transit node, and the second container includes a second virtual node corresponding to the target transit node; the sending the call request from the first container to the second container by accessing the target transit node includes: sending the call request to the target transit node by accessing the first virtual node; sending the call request to the second virtual node through the target transit node to send the call request to the second operating system; the sending, by accessing the target transit node, a target hardware service result from the second container to the first container, comprising: transmitting the hardware service result to the target transit node through the second virtual node; and sending the hardware service result to the first container through the target switching node.
Optionally, the first container includes a plurality of first virtual nodes, the second container includes a plurality of second virtual nodes, a plurality of transit nodes corresponding to the second virtual nodes one to one are set under the second container, each transit node communicates with one of the first virtual nodes, and the transit nodes are applied to different types of hardware services.
Optionally, the first container includes a target mapping relation library, where the target mapping relation library includes mapping relations between the plurality of first virtual nodes and the plurality of transit nodes; further comprises: and determining a first virtual node corresponding to the target transit node through the target mapping relation library.
Optionally, the first container includes a plurality of mapping relation libraries, and the target mapping relation library is one of the plurality of mapping relation libraries; the first container further comprises an environment variable, and the environment variable is set to enable the calling priority of the target mapping relation library to be highest.
Optionally, before obtaining the call request sent by the first operating system in the first container, the method further includes: and creating the first virtual node in the first container, and correspondingly associating the created first virtual node with the target transit node, wherein the node name of the first virtual node is different from the node name of the corresponding target transit node.
Optionally, the first operating system is a non-android system, the second operating system is an android system, and the target hardware service is a service provided by the android system for accessing an android hardware library.
According to a second aspect of the embodiments of the present disclosure, there is provided a service providing apparatus applied to a service platform, where the service platform runs at least a first container and a second container, a first operating system is run in the first container, and a second operating system different from the first operating system is run in the second container, including: a call request acquisition module configured to acquire a call request sent by the first operating system in the first container, where the call request is used to call a target hardware service of the second operating system in the second container; a transit node determination module configured to determine a target transit node under the second container that matches the target hardware service, wherein the transit node is to enable communication between the first container and the second container; a request forwarding module configured to send the call request from the first container to the second container by accessing the target transit node; and a service result acquisition module configured to send a target hardware service result from the second container to the first container by accessing the target transit node, wherein the hardware service result is a result generated by the second operating system in the second container executing the target hardware service in response to the call request.
Optionally, the first container includes a first virtual node corresponding to the target transit node, and the second container includes a second virtual node corresponding to the target transit node; the request forwarding module is configured to: sending the call request to the target transit node by accessing the first virtual node; sending the call request to the second virtual node through the target transit node to send the call request to the second operating system; the service result acquisition module is configured to: transmitting the hardware service result to the target transit node through the second virtual node; and sending the hardware service result to the first container through the target switching node.
Optionally, the first container includes a plurality of first virtual nodes, the second container includes a plurality of second virtual nodes, a plurality of transit nodes corresponding to the second virtual nodes one to one are set under the second container, each transit node communicates with one of the first virtual nodes, and the transit nodes are applied to different types of hardware services.
Optionally, the first container includes a target mapping relation library, where the target mapping relation library includes mapping relations between the plurality of first virtual nodes and the plurality of transit nodes; the service providing apparatus further includes: and the virtual node determining module is configured to determine a first virtual node corresponding to the target transit node through the target mapping relation library.
Optionally, the first container includes a plurality of mapping relation libraries, and the target mapping relation library is one of the plurality of mapping relation libraries; the first container further comprises an environment variable, and the environment variable is set to enable the calling priority of the target mapping relation library to be highest.
Optionally, the service providing apparatus further includes: and the association module is configured to create the first virtual node in the first container and correspondingly associate the created first virtual node with the target transit node, wherein the node name of the first virtual node is different from the node name of the corresponding target transit node.
Optionally, the first operating system is a non-android system, the second operating system is an android system, and the target hardware service is a service provided by the android system for accessing an android hardware library.
According to a third aspect of embodiments of the present disclosure, there is provided an electronic device, comprising: a processor; a memory for storing execution instructions; wherein the processor is configured to execute the instructions to implement a service providing method according to the present disclosure.
According to a fourth aspect of embodiments of the present disclosure, there is provided a computer-readable storage medium, which when executed by a processor of an electronic device, enables the electronic device to perform a service providing method according to the present disclosure.
According to a fifth aspect of embodiments of the present disclosure, there is provided a computer program product comprising a computer program which, when executed by a processor, implements a service providing method according to the present disclosure.
The technical scheme provided by the embodiment of the disclosure at least brings the following beneficial effects:
In the method, the first operating system is operated in the first container, the second operating system is operated in the second container, and the first container and the second container are connected through the switching node, so that the first operating system can remotely call services in the second operating system, namely, the second operating system can be called to access hardware resources, and the quick adaptation of the hardware functions of the first operating system can be ensured.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description, serve to explain the principles of the disclosure and do not constitute an undue limitation on the disclosure.
Fig. 1 is a flowchart illustrating a service providing method according to an exemplary embodiment of the present disclosure;
FIG. 2 is a schematic diagram illustrating a lxc inter-container system communication architecture according to an example embodiment of the present disclosure;
FIG. 3 is a schematic diagram illustrating a first virtual node corresponding association with a transit node in accordance with an exemplary embodiment of the present disclosure;
FIG. 4 is a schematic diagram illustrating another inter-lxc-container system communication architecture according to an example embodiment of the present disclosure;
FIG. 5 is a schematic diagram illustrating the retrieval of service results from a second operating system in response to a call request in accordance with an exemplary embodiment of the present disclosure;
fig. 6 is a block diagram illustrating a service providing apparatus according to an exemplary embodiment of the present disclosure;
Fig. 7 is a block diagram illustrating an electronic device according to an exemplary embodiment of the present disclosure.
Detailed Description
In order to enable those skilled in the art to better understand the technical solutions of the present disclosure, the technical solutions of the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings.
It should be noted that the terms "first," "second," and the like in the description and claims of the present disclosure and in the foregoing figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the disclosure described herein may be capable of operation in sequences other than those illustrated or described herein. The embodiments described in the examples below are not representative of all embodiments consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present disclosure as detailed in the accompanying claims.
It should be noted that, in this disclosure, "at least one of the items" refers to a case where three types of juxtaposition including "any one of the items", "a combination of any of the items", "an entirety of the items" are included. For example, "including at least one of a and B" includes three cases side by side as follows: (1) comprises A; (2) comprising B; (3) includes A and B. For example, "at least one of the first and second steps is executed", that is, three cases are juxtaposed as follows: (1) performing step one; (2) executing the second step; (3) executing the first step and the second step.
OpenHarmony, abbreviated OpenAtom OpenHarmony, is an open source item for the hong Meng operating system. The OpenHarmony system supports the linux kernel using standard systems in addition to the LiteOS kernel. Therefore, openHarmony can be used not only in small-scale systems, but also in more complex large-scale systems, thereby better meeting the requirements in various aspects. OpenHarmony, the standard system is oriented to an application processor such as Arm Cortex-A device, the minimum memory of the supported device is 128MiB, and the system can provide enhanced interaction capability, 3D GPU and hardware synthesis capability, more controls, graphic capability with rich dynamic effects and complete application framework. Currently, part of the hardware capabilities of the chip are not fully used, e.g. the hardware codec capabilities of multimedia, due to the incomplete hardware driver adaptation.
Since the containers running on the computer are typically isolated from each other, communication between the containers is typically by way of a network, and mainly includes the following: access through container ip; port access through the ip of the host; establishing connection access through link; a bridging network is created by User-defined networks, and containers in the same bridging network can access each other.
In the related art, hardware drivers provided by hardware vendors are basically android-enabled, where libraries of graphics, multimedia related drivers or call drivers are mostly closed-source, and do not match with the non-android operating system. For example, does not match the aforementioned hong system. This can result in the inability to directly invoke these hardware resources under non-android operating systems. In addition, although the containers can communicate in a network manner, network communication between the containers is usually initiated and received at an application layer, and hardware devices cannot be directly operated to acquire hardware data, so that a process of calling hardware resources across the containers is complex and low in efficiency.
In order to solve the above-mentioned problems in the related art, the present disclosure provides a service providing method, apparatus, electronic device, storage medium, and computer program product, by running a first operating system in a first container and a second operating system in a second container, and connecting the first container and the second container through a transit node, the first operating system can remotely call a service in the second operating system, that is, can call a second operating system driver to access a hardware resource, and can ensure rapid adaptation of hardware functions of the first operating system.
In the following, some technical terms related to the present disclosure are explained.
LXC, the name of which comes from the abbreviation of Linux software Containers (Linux Containers), an Operating system layer virtualization (Operating system-level virtualization) technology, is a user space interface for Linux kernel container functions. It may package the application software system into a software Container (Container) containing the code of the application software itself and the required operating system kernel and libraries. In this way, available hardware resources of different software containers can be allocated through a unified namespace and shared API, and an independent sandboxed execution environment of the application program is created, so that Linux users can easily create and manage a system or application container.
Halium, a collaboration item, is designed to unify the hardware abstraction layers for items running Linux on Android-preloaded mobile devices. The project aims to standardize the middleware software used by the various projects to communicate with the android daemon and utilize the hardware on the installed devices. It may be distributed as free and open source software in the form of a hybrid software license.
Binder is a unique inter-process communication mechanism of Android and a remote system call method. That is, one Android process may call a routine in another Android process, and a binder may be used to identify the method to call and pass parameters between processes.
Hybris or libhybris, which is mainly aimed at solving the problem of compatibility of libc libraries, i.e. the purpose of which is to run those libraries compiled with bionic (mainly closed source HAL libraries under Android) in GNU C library-based systems.
Fig. 1 is a flowchart illustrating a service providing method according to an exemplary embodiment of the present disclosure, applied to a service platform. The service platform may run at least a first container in which a first operating system may be run and a second container in which a second operating system different from the first operating system may be run.
Referring to FIG. 1, in step 101, a call request sent by a first operating system in a first container may be obtained, where the call request may be used to call a target hardware service of a second operating system in a second container. For example, a call request generated by a target application in a first container may be obtained. The first operating system may be, for example, a hong Monte system. Fig. 2 is a schematic diagram illustrating a lxc inter-container system communication architecture according to an example embodiment of the present disclosure. Referring to fig. 2, the system communication architecture between lxc containers mainly comprises Openharmony system containers (hereinafter abbreviated as OH containers), android system containers (hereinafter abbreviated as halium containers), binder devices and drivers, libhybris, and the like.
It should be noted that, the OpenHarmony standard system is usually directly run on the linux kernel, and through the container virtualization technology, it may also be run in a container based on the linux system, that is, the Openharmony standard system may be run in the OH container. The OH container can be placed in the foreground and the user runs Openharmony standard system using the OH container consistent with the experience of running Openharmony standard system directly on the linux kernel basis.
And running a second operating system in the Android system container, namely halium containers. The second operating system may be, for example, a reduced set of android systems that may provide basic capabilities for accessing the Analyzer Zhuo Yingjian library. The halium container may be loaded with a vendor partition provided by a hardware vendor, and the partition is extracted from a complete android image, and may include an android library and services required by a hardware device driver. Since these libraries and services are generated based on bionic libraries, openharmony cannot be used directly. Through the lightweight halium container, the operation problem of android libraries and services can be solved, and too much hardware resources can not be occupied.
The above "libhybris" can be used to solve the problem of libc library compatibility. The present disclosure may use libhybris libraries in the OH container, may enable invocation of android libraries in the OH environment, and may communicate with services in the halium container through a binder device driver.
According to an exemplary embodiment of the present disclosure, a first virtual node may also be created within the first container, and the created first virtual node may be associated with the target transit node, where a node name of the first virtual node may be different from a node name of the corresponding target transit node.
Fig. 3 is a schematic diagram illustrating a first virtual node corresponding association with a transit node according to an exemplary embodiment of the present disclosure. Referring to fig. 3, the OH container may contain gst-droid multimedia plug-ins, libhybris, libubinder library. The gst-droid multimedia plug-in can change the multimedia capability hardware calling mode in the Openharmony system from directly calling the android library from the hal layer of Openharmony to calling the android library through libhybris.
At least one transit node is provided on the exterior of the halium container in FIG. 3, "/dev/binder", "/dev/hwbinder", "/dev/vndbinder", respectively. And at least one first virtual node is also arranged in the OH container, namely "/dev/u-binder" and "/dev/u-hwbinder", respectively. And, the first virtual node "/dev/u-binder" may have a mapping relationship with the transit node "/dev/binder"; the first virtual node "/dev/u-hwbinder" may have a mapping relationship with the transit node "/dev/hwbinder".
In addition, the node name of the first virtual node "/dev/u-binder" is: "/dev/u-binder", which is associated with the node name of the corresponding transit node "/dev/binder": "/dev/binder" is different; the node name of the first virtual node "/dev/u-hwbinder" is "/dev/u-hwbinder" which is the node name of the corresponding transit node "/dev/hwbinder": "/dev/hwbinder" are different. Specifically, libubinder libraries may be added to the OH container, which changes the node name of the access binder device when invoking the android library in Openharmony. I.e. at least one first virtual node obtained after renaming for at least one transit node may be created in the OH container and the created first virtual node may be associated with the corresponding transit node. In this way, the core codes of the OH container and the halium container do not need to be changed when the system communication architecture is used for cross-container resource call, and the transplanting and the maintenance are convenient.
In step 102, a target transit node under the second container that matches the target hardware service may be determined, wherein the transit node may be used to enable communication between the first container and the second container.
In step 103, a call request may be sent from the first container to the second container by accessing the target transit node.
In step 104, a target hardware service result may be sent from the second container to the first container by accessing the target transit node, wherein the hardware service result may be a result of the second operating system in the second container executing the target hardware service in response to the call request.
According to an exemplary embodiment of the disclosure, the first operating system may be a non-android system, the second operating system may be an android system, and the target hardware service may be a service provided by the android system for accessing an android hardware library.
According to an exemplary embodiment of the present disclosure, the above-described target hardware service may be a camera service (CAMERASERVICE) or a multimedia service (MEDIASERVICE).
According to an exemplary embodiment of the present disclosure, a first container may contain a first virtual node corresponding to a target transit node therein, and a second container may contain a second virtual node corresponding to the target transit node therein.
The call request may be sent to the target transit node by accessing the first virtual node. The call request may then be sent to the second virtual node by the target transit node to send the call request to the second operating system. The hardware service result may then be sent to the target transit node through the second virtual node. The hardware service results may then be sent to the first container via the target transit node.
Specifically, as mentioned above, the first container may include at least one first virtual node: "/dev/u-binder" and "/dev/u-hwbinder"; the second container may correspond to at least one transit node "/dev/binder", "/dev/hwbinder", "/dev/vndbinder"; the at least one first virtual node may be in one-to-one correspondence with the at least one transit node, and the target transit node may be one of the at least one transit node.
A first virtual node of the at least one first virtual node that corresponds to the target transit node may be determined. For example, after the call request generated by the target application program in the first container is acquired, a service that needs to be accessed by the call request may be determined first, and further, it may be determined which transit node should be used to provide the service based on the service to be accessed. It should be noted that the types of services provided by different transit nodes may be different from one another. Therefore, the type of the access service required by the call request can be determined first, and then the transit node with the capability of providing the corresponding type of service can be searched for based on the type of the service to be accessed to provide the service. Suppose that a transit node "/dev/binder" is to be used to provide services.
Then, a first virtual node of the at least one first virtual node corresponding to the target transit node "/dev/binder" may be determined. As described above, the first virtual node "/dev/u-binder" in the OH container has a mapping relationship with the target transit node "/dev/binder", and thus, the first virtual node corresponding to the target transit node "/dev/binder" can be determined as "/dev/u-binder".
Next, the target transit node may be accessed by accessing the first virtual node to obtain a service result from within the second operating system using the target transit node. That is, the target transit node "/dev/binder" may be accessed by accessing the first virtual node "/dev/u-binder" to obtain services accessing the android Zhuo Yingjian library from within the android system using the target transit node "/dev/binder".
Further, the second container may further include at least one second virtual node, where the at least one second virtual node may be in one-to-one correspondence with the at least one transit node. And, at least one second virtual node may be a homonymous mapping virtual node of at least one transit node, i.e. the names of the second virtual node and the transit node corresponding thereto may be the same.
Illustratively, referring to fig. 4, fig. 4 is a schematic diagram illustrating another inter-lxc-container system communication architecture according to an exemplary embodiment of the present disclosure. At least one transit node is located under halium containers, respectively "/dev/binder", "/dev/hwbinder", "/dev/vndbinder", ". Also, halium containers may contain homonymous map virtual nodes "/dev/binder" corresponding to transit nodes "/dev/binder", homonymous map virtual nodes "/dev/hwbinder" corresponding to transit nodes "/dev/hwbinder", homonymous map virtual nodes "/dev/vndbinder" corresponding to transit nodes "/dev/vndbinder".
The target transit node can be accessed by accessing the first virtual node, and a second virtual node corresponding to the target transit node in the at least one second virtual node can be accessed by the target transit node, so that the service result acquired by the second operating system is received by the second virtual node. For example, assuming that the target transit node is "/dev/hwbinder", a second virtual node corresponding to the target transit node "/dev/hwbinder", that is, a homonymous mapping virtual node "/dev/hwbinder", among at least one second virtual node contained in the container halium may be accessed through the target transit node "/dev/hwbinder", so as to receive a service result obtained by the android system by using the homonymous mapping virtual node "/dev/hwbinder".
Referring back to FIG. 4, in the same core, two sets of binder devices may be provided for the OH and halium containers, respectively. Specifically, at least one transit node may correspond to the halium containers: "/dev/binder", "/dev/hwbinder", "/dev/vndbinder", and these transit nodes may correspond to at least one first virtual node "/dev/u-binder" and "/dev/u-hwbinder" in the OH container.
In addition, the OH container can also contain a virtual node "/dev/binder" for use inside the OH container, and the virtual node "/dev/binder" can have a mapping relation with "/dev/OH-binder" outside the OH container frame. That is, when the OH container wants to access the service in the first operating system running in the OH container, the node "/dev/OH-binder" outside the OH container box can be accessed by accessing the virtual node "/dev/binder", and then the service result can be obtained from the first operating system by "/dev/OH-binder" and returned to the OH container.
In this way, at least one first virtual node obtained by renaming at least one transit node can be created in the first container in a mode of mount-o bind when the container is started, so that cross mapping of the binder device node is realized, the Openharmony system and the android system can be ensured not to collide when accessing/dev/binder, and a bridge for accessing halum containers by the OH container is provided. And communication efficiency between systems can be improved by borrowing a binder communication mechanism.
According to an exemplary embodiment of the present disclosure, as described above, a plurality of first virtual nodes may be included in a first container, a plurality of second virtual nodes may be included in a second container, and a plurality of transit nodes corresponding to the plurality of second virtual nodes one to one may be disposed under the second container. Each transit node may communicate with one of the plurality of first virtual nodes, and the plurality of transit nodes may be applied to different types of hardware services.
According to an exemplary embodiment of the present disclosure, a target mapping relation library may be further contained in the first container, where the target mapping relation library may contain mapping relations between a plurality of first virtual nodes and a plurality of transit nodes. The first virtual node corresponding to the target transit node may also be determined through the target mapping relation library.
According to an exemplary embodiment of the present disclosure, the first container may include a plurality of mapping relation libraries, and the target mapping relation library may be one of the plurality of mapping relation libraries. The first container may further include an environment variable, where the environment variable may be set to maximize call priority of the target mapping relation library.
Specifically, the target mapping relation library may be a libubinder library, and the target mapping relation library may include a mapping relation between at least one first virtual node and at least one transit node. In addition, the first container may further include an environment variable "HYBRIS _ld_LIBRARY_PATH", where the environment variable may specify a call priority of each of the plurality of mapping relation libraries, and the call priority of the target mapping relation LIBRARY may be highest.
It should be noted that, the OH container includes directories from mount in halium containers, where these directories include a libbinder library, and the libbinder library may include a mapping relationship between at least one transit node under halium containers and at least one virtual node mapped by the same name. Wherein, the meaning of the homonymous mapping is that the mapped virtual node and the mapped node are the same in name.
Illustratively, the homonymous mapping virtual node corresponding to the transit node "/dev/binder" may be "/dev/binder"; the corresponding homonymous mapping virtual node of the transit node "/dev/hwbinder" can be "/dev/hwbinder"; the corresponding homonymous mapping virtual node of transit node "/dev/vndbinder" may be "/dev/vndbinder".
Typically, this libbinder library is invoked by default when the OH container wants to access a service. Assuming that the OH container currently wants to call the transit node "/dev/binder" under halium containers, the virtual node recorded in the libbinder library called by default and having a mapping relation with the transit node "/dev/binder" is "/dev/binder", and the virtual node "/dev/binder" in the OH container has a mapping relation with the "/dev/binder" which is the node of "/dev/OH-binder" outside the OH container. At this time, the case where the OH container accesses the "/dev/OH-binder" node by accessing the virtual node "/dev/binder" found in the libbinder library called by default to access the service in the first operating system may occur, and the node actually intended to be accessed by the OH container is actually the transit node "/dev/binder" under the halium container, that is, the case where the OH container cannot access the service actually intended to be accessed may occur.
In response to the above-described deficiencies, the present disclosure may configure the "HYBRIS _LD_LIBRARY_PATH" environment variable in the OH container, and may add/opt/android/lib/ubinder PATH to the home position, while creating a soft link under that PATH that is synonymous with libbinder LIBRARY and pointing to libubinder LIBRARY. Thus, when the OH container accesses the service through hybris, the android LIBRARY in the directory of the opt/android/lib/ubinder can be preferentially used according to the call priority specified by the environment variable "HYBRIS _LD_LIBRARY_PATH", namely the specified call sequence.
As described above, the libubinder library describes a mapping relationship between at least one virtual node obtained by renaming at least one transit node and at least one transit node, that is, the first virtual node created in the OH container is renamed. Thus, when the OH container wants to call the transit node "/dev/binder" under halium containers, the mapping relationship contained in the target mapping relationship library with highest call priority indicated by the above environment variable can be based on: "first virtual node"/dev/u-binder "-transit node"/dev/binder under halium container ", and determining the virtual node corresponding to transit node"/dev/binder "under halium container which is actually intended to be accessed as the first virtual node"/dev/u-binder ". Then, the transit node "/dev/binder" under halium container can be accessed by accessing the first virtual node "/dev/u-binder", i.e. it can be ensured that the OH container can access the service that really wants to access.
Therefore, in the disclosure, the index sequence of the LIBRARY function directory can be configured through the environment variable of HYBRIS _LD_LIBRARY_PATH, so that the same-name LIBRARY files with different contents can be called in two containers, and the conflict is avoided.
FIG. 5 is a schematic diagram illustrating the retrieval of service results from a second operating system in response to a call request according to an exemplary embodiment of the present disclosure. Referring to fig. 5, an OH library and an android library may be contained in the OH container, and the OH library may contain "gst-droid multimedia plug-in", "libcamera _ commom", "libhybris _ commom", "libcamera _ commom" is a universal library of pointer-to-camera functions, and "libhybris _ commom" is a universal library of libhybris; the android library may contain "libcamera _ compat _layer", "libcamera _client", "libubinder library". The multimedia capability hardware calling mode in the Openharmony system can be changed from directly calling the hal layer of Openharmony to calling the android library in the halium container through libhybris through gst-droid multimedia plugin.
In the present disclosure, a communication architecture between an OH container and halium containers running on an embedded platform is provided. The OH container can remotely call hardware services in the halium container through libhybris interfaces and by means of a binder device, and can remotely call android drivers to achieve access to hardware resources. The method can realize rapid adaptation of Openhamony systems to new hardware platforms, and solves the problem that Android hardware drivers cannot be used in Openharmony systems.
Fig. 6 is a block diagram illustrating a service providing apparatus according to an exemplary embodiment of the present disclosure.
Referring to fig. 6, the service providing apparatus 600 may include a call request acquisition module 601, a transit node determination module 602, a request forwarding module 603, and a service result acquisition module 604.
The call request acquisition module 601 may acquire a call request sent by a first operating system in a first container, where the call request may be used to call a target hardware service of a second operating system in a second container. For example, a call request generated by a target application in a first container may be obtained.
According to an exemplary embodiment of the present disclosure, the service providing apparatus may further include an association module. The association module may create a first virtual node within the first container, and may associate the created first virtual node with the target transit node, where a node name of the first virtual node may be different from a node name of the corresponding target transit node.
The transit node determination module 602 may determine a target transit node under the second container that matches the target hardware service, where the transit node may be used to enable communication between the first container and the second container.
The request forwarding module 603 may send a call request from the first container to the second container by accessing the target transit node.
The service result acquisition module 604 may send the target hardware service result from the second container to the first container by accessing the target transit node, where the hardware service result may be a result of the second operating system in the second container executing the target hardware service in response to the call request.
According to an exemplary embodiment of the disclosure, the first operating system may be a non-android system, the second operating system may be an android system, and the target hardware service may be a service provided by the android system for accessing an android hardware library.
According to an exemplary embodiment of the present disclosure, the above-described target hardware service may be a camera service or a multimedia service.
According to an exemplary embodiment of the present disclosure, a first container may contain a first virtual node corresponding to a target transit node therein, and a second container may contain a second virtual node corresponding to the target transit node therein.
The request forwarding module 603 may send the call request to the target transit node by accessing the first virtual node. The request forwarding module 603 may then send the call request to the second virtual node via the target transit node to send the call request to the second operating system. Next, the service result obtaining module 604 may send the hardware service result to the target transit node through the second virtual node. The service result acquisition module 604 may then send the hardware service result to the first container via the target transit node.
According to an exemplary embodiment of the present disclosure, as described above, a plurality of first virtual nodes may be included in a first container, a plurality of second virtual nodes may be included in a second container, and a plurality of transit nodes corresponding to the plurality of second virtual nodes one to one may be disposed under the second container. Each transit node may communicate with one of the plurality of first virtual nodes, and the plurality of transit nodes may be applied to different types of hardware services.
According to an exemplary embodiment of the present disclosure, a target mapping relation library may be further contained in the first container, where the target mapping relation library may contain mapping relations between a plurality of first virtual nodes and a plurality of transit nodes. The first virtual node corresponding to the target transit node may also be determined through the target mapping relation library.
According to an exemplary embodiment of the present disclosure, the first container may include a plurality of mapping relation libraries, and the target mapping relation library may be one of the plurality of mapping relation libraries. The first container may further include an environment variable, where the environment variable may be set to maximize call priority of the target mapping relation library.
Fig. 7 is a block diagram illustrating an electronic device 700 according to an exemplary embodiment of the present disclosure.
Referring to fig. 7, an electronic device 700 includes at least one memory 701 and at least one processor 702, the at least one memory 701 having instructions stored therein that, when executed by the at least one processor 702, perform a service providing method according to an exemplary embodiment of the present disclosure.
By way of example, the electronic device 700 may be a PC computer, tablet device, personal digital assistant, smart phone, or other device capable of executing the instructions described above. Here, the electronic device 700 is not necessarily a single electronic device, but may be any apparatus or a collection of circuits capable of executing the above-described instructions (or instruction set) individually or in combination. The electronic device 700 may also be part of an integrated control system or system manager, or may be configured as a portable electronic device that interfaces with either locally or remotely (e.g., via wireless transmission).
In electronic device 700, processor 702 may include a Central Processing Unit (CPU), a Graphics Processor (GPU), a programmable logic device, a special purpose processor system, a microcontroller, or a microprocessor. By way of example, and not limitation, processors may also include analog processors, digital processors, microprocessors, multi-core processors, processor arrays, network processors, and the like.
The processor 702 may execute instructions or code stored in the memory 701, wherein the memory 701 may also store data. The instructions and data may also be transmitted and received over a network via a network interface device, which may employ any known transmission protocol.
The memory 701 may be integrated with the processor 702, for example, RAM or flash memory disposed within an integrated circuit microprocessor or the like. In addition, the memory 701 may include a separate device, such as an external disk drive, a storage array, or any other storage device usable by a database system. The memory 701 and the processor 702 may be operatively coupled or may communicate with each other, for example, through an I/O port, a network connection, etc., such that the processor 702 is able to read files stored in the memory.
In addition, the electronic device 700 may also include a video display (such as a liquid crystal display) and a user interaction interface (such as a keyboard, mouse, touch input device, etc.). All components of the electronic device 700 may be connected to each other via a bus and/or a network.
According to an exemplary embodiment of the present disclosure, there may also be provided a computer-readable storage medium, which when executed by a processor of an electronic device, enables the electronic device to perform the above-described service providing method. Examples of the computer readable storage medium herein include: read-only memory (ROM), random-access programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), random-access memory (RAM), dynamic random-access memory (DRAM), static random-access memory (SRAM), flash memory, nonvolatile memory, CD-ROM, CD-R, CD + R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD + R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R LTH, BD-RE, blu-ray or optical disk storage, hard Disk Drives (HDD), solid State Disks (SSD), card-type memories (such as multimedia cards, secure Digital (SD) cards or ultra-fast digital (XD) cards), magnetic tapes, floppy disks, magneto-optical data storage devices, hard disks, solid state disks, and any other devices configured to store computer programs and any associated data, data files and data structures in a non-transitory manner and to provide the computer programs and any associated data, data files and data structures to a processor or computer to enable the processor or computer to execute the programs. The computer programs in the computer readable storage media described above can be run in an environment deployed in a computer device, such as a client, host, proxy device, server, etc., and further, in one example, the computer programs and any associated data, data files, and data structures are distributed across networked computer systems such that the computer programs and any associated data, data files, and data structures are stored, accessed, and executed in a distributed fashion by one or more processors or computers.
According to an exemplary embodiment of the present disclosure, there may also be provided a computer program product comprising a computer program which, when executed by a processor, implements a service providing method according to the present disclosure.
According to the service providing method, the device, the electronic equipment, the storage medium and the computer program product, through running the first operating system in the first container and running the second operating system in the second container, and connecting the first container and the second container through the transfer node, the first operating system can remotely call services in the second operating system, namely, the second operating system can be called to access hardware resources, and the quick adaptation of the hardware functions of the first operating system can be ensured.
According to the exemplary embodiment of the present disclosure, the migration and maintenance are facilitated without modifying the core code of the OH container and halium containers when cross-container resource calls are made using the system communication architecture described above.
According to the exemplary embodiment of the disclosure, at least one first virtual node obtained by renaming at least one transit node can be created in the first container by means of a mount-o bind, so that cross mapping of the binder device nodes is realized, the Openharmony system and the android system access/dev/binder can be guaranteed not to collide, and a bridge for accessing the halum container by the OH container is provided. And communication efficiency between systems can be improved by borrowing a binder communication mechanism.
According to the exemplary embodiment of the disclosure, the index sequence of the LIBRARY function directory can be configured through the environment variable 'HYBRIS _LD_LIBRARY_PATH', so that the same-name LIBRARY files with different contents can be called in two containers, and the conflict is avoided.
Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This disclosure is intended to cover any adaptations, uses, or adaptations of the disclosure following the general principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.
It is to be understood that the present disclosure is not limited to the precise arrangements and instrumentalities shown in the drawings, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.
Claims (9)
1. A service providing method applied to a service platform, wherein the service platform runs at least a first container and a second container, a first operating system runs in the first container, and a second operating system different from the first operating system runs in the second container, and the service providing method is characterized by comprising the following steps:
acquiring a call request sent by the first operating system in the first container, wherein the call request is used for calling a target hardware service of the second operating system in the second container;
determining a target transit node under the second container, which is matched with the target hardware service, wherein the transit node is used for realizing communication between the first container and the second container;
Sending the call request from the first container to the second container by accessing the target transit node;
Transmitting a target hardware service result from the second container to the first container by accessing the target transit node, wherein the hardware service result is a result generated by the second operating system in the second container executing the target hardware service in response to the call request;
The first container comprises a first virtual node corresponding to the target transit node, and the second container comprises a second virtual node corresponding to the target transit node;
the first container comprises a plurality of first virtual nodes, the second container comprises a plurality of second virtual nodes, a plurality of transit nodes corresponding to the second virtual nodes one by one are arranged under the second container, and each transit node is communicated with one of the first virtual nodes;
the first container comprises a target mapping relation library, and the target mapping relation library comprises mapping relations between the plurality of first virtual nodes and the plurality of transit nodes;
Further comprises:
Determining a first virtual node corresponding to the target transit node through the target mapping relation library;
The first container comprises a plurality of mapping relation libraries, the target mapping relation library is one of the plurality of mapping relation libraries, the plurality of mapping relation libraries further comprise libbinder libraries, the libbinder libraries comprise mapping relations between the plurality of transit nodes and a plurality of virtual nodes mapped by the same names based on the plurality of transit nodes, the virtual nodes mapped by the same names correspond to nodes outside the first container, and the nodes corresponding to the virtual nodes mapped by the same names outside the first container are used for accessing services in the first operating system;
The first container further comprises an environment variable, and the environment variable is set to enable the calling priority of the target mapping relation library to be highest.
2. The service providing method according to claim 1, wherein the sending the call request from the first container to the second container by accessing the target transit node includes:
sending the call request to the target transit node by accessing the first virtual node;
sending the call request to the second virtual node through the target transit node to send the call request to the second operating system;
the sending, by accessing the target transit node, a target hardware service result from the second container to the first container, comprising:
transmitting the hardware service result to the target transit node through the second virtual node;
And sending the hardware service result to the first container through the target switching node.
3. The service providing method according to claim 2, wherein the plurality of transit nodes are applied to different types of hardware services.
4. The service providing method according to claim 2, further comprising, before acquiring the call request sent by the first operating system in the first container:
and creating the first virtual node in the first container, and correspondingly associating the created first virtual node with the target transit node, wherein the node name of the first virtual node is different from the node name of the corresponding target transit node.
5. The service providing method according to claim 1, wherein the first operating system is a non-android system, the second operating system is an android system, and the target hardware service is a service provided by the android system and accessing an android hardware library.
6. A service providing apparatus applied to a service platform, the service platform running at least a first container in which a first operating system is running and a second container in which a second operating system different from the first operating system is running, comprising:
A call request acquisition module configured to acquire a call request sent by the first operating system in the first container, where the call request is used to call a target hardware service of the second operating system in the second container;
a transit node determination module configured to determine a target transit node under the second container that matches the target hardware service, wherein the transit node is to enable communication between the first container and the second container;
A request forwarding module configured to send the call request from the first container to the second container by accessing the target transit node;
A service result acquisition module configured to send a target hardware service result from the second container to the first container by accessing the target transit node, wherein the hardware service result is a result of the second operating system in the second container executing the target hardware service in response to the call request;
The first container comprises a first virtual node corresponding to the target transit node, and the second container comprises a second virtual node corresponding to the target transit node;
the first container comprises a plurality of first virtual nodes, the second container comprises a plurality of second virtual nodes, a plurality of transit nodes corresponding to the second virtual nodes one by one are arranged under the second container, and each transit node is communicated with one of the first virtual nodes;
the first container comprises a target mapping relation library, and the target mapping relation library comprises mapping relations between the plurality of first virtual nodes and the plurality of transit nodes;
The service providing apparatus further includes:
the virtual node determining module is configured to determine a first virtual node corresponding to the target transit node through the target mapping relation library;
The first container comprises a plurality of mapping relation libraries, the target mapping relation library is one of the plurality of mapping relation libraries, the plurality of mapping relation libraries further comprise libbinder libraries, the libbinder libraries comprise mapping relations between the plurality of transit nodes and a plurality of virtual nodes mapped by the same names based on the plurality of transit nodes, the virtual nodes mapped by the same names correspond to nodes outside the first container, and the nodes corresponding to the virtual nodes mapped by the same names outside the first container are used for accessing services in the first operating system;
The first container further comprises an environment variable, and the environment variable is set to enable the calling priority of the target mapping relation library to be highest.
7. An electronic device, comprising:
A processor;
a memory for storing execution instructions;
Wherein the processor is configured to execute the instructions to implement the service providing method of any one of claims 1 to 5.
8. A computer readable storage medium, characterized in that instructions in the computer readable storage medium, when executed by a processor of an electronic device, enable the electronic device to perform the service providing method of any one of claims 1 to 5.
9. A computer program product comprising a computer program which, when executed by a processor, implements the service providing method according to any one of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410902864.6A CN118445032B (en) | 2024-07-05 | 2024-07-05 | Service providing method, apparatus, electronic device, storage medium, and computer program product |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410902864.6A CN118445032B (en) | 2024-07-05 | 2024-07-05 | Service providing method, apparatus, electronic device, storage medium, and computer program product |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN118445032A CN118445032A (en) | 2024-08-06 |
| CN118445032B true CN118445032B (en) | 2024-08-30 |
Family
ID=92328410
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410902864.6A Active CN118445032B (en) | 2024-07-05 | 2024-07-05 | Service providing method, apparatus, electronic device, storage medium, and computer program product |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN118445032B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110618876A (en) * | 2019-03-21 | 2019-12-27 | 天津麒麟信息技术有限公司 | Linux and Android coexistence and interaction method based on Feiteng platform and shared kernel |
| CN114077462A (en) * | 2021-04-07 | 2022-02-22 | 北京鲸鲮信息系统技术有限公司 | Method, device, device and medium for calling Android HIDL interface by software operating system |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112612536B (en) * | 2020-12-15 | 2022-11-18 | 麒麟软件有限公司 | Method and device for controlling camera shooting based on Android application program in Linux system |
| CN113190280A (en) * | 2021-04-07 | 2021-07-30 | 北京鲸鲮信息系统技术有限公司 | Method and device for calling Android HAL dynamic library by Linux system and storage medium |
| CN117992189A (en) * | 2022-11-03 | 2024-05-07 | 华为技术有限公司 | Window implementation method and electronic device under multiple systems |
-
2024
- 2024-07-05 CN CN202410902864.6A patent/CN118445032B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110618876A (en) * | 2019-03-21 | 2019-12-27 | 天津麒麟信息技术有限公司 | Linux and Android coexistence and interaction method based on Feiteng platform and shared kernel |
| CN114077462A (en) * | 2021-04-07 | 2022-02-22 | 北京鲸鲮信息系统技术有限公司 | Method, device, device and medium for calling Android HIDL interface by software operating system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN118445032A (en) | 2024-08-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN114077462B (en) | Method, device, equipment and medium for software operating system to call Android HIDL interface | |
| JP4297790B2 (en) | Persistent key-value repository with pluggable architecture abstracting physical storage | |
| US10831474B2 (en) | ISA-ported container images | |
| CN111930473B (en) | Method and apparatus for deploying image recognition service on container cloud | |
| US11030025B2 (en) | Managing inter-process communications in a containerized application environment | |
| WO2017165151A1 (en) | Operating system layering | |
| US11010355B2 (en) | Layer-based file access method and apparatus of virtualization instance | |
| CN109144478B (en) | Component frame system and method of using the same | |
| AU2014311782A1 (en) | Scalable distributed storage architecture | |
| US9075634B2 (en) | Minimizing overhead in resolving operating system symbols | |
| CN114942796B (en) | Plug-in compiling and calling method, device, equipment and storage medium | |
| CN114780950B (en) | Method, system, device and storage medium for cross-version compatible operation of application software | |
| US8484616B1 (en) | Universal module model | |
| CN114064594B (en) | Data processing method and device | |
| US9141352B2 (en) | Dynamically building locale objects at run-time | |
| US8677354B2 (en) | Controlling kernel symbol visibility and accessibility across operating system linkage spaces | |
| CN118445032B (en) | Service providing method, apparatus, electronic device, storage medium, and computer program product | |
| US20230195695A1 (en) | File Sharing Method and Terminal Device | |
| CN114996750A (en) | Data sharing method and device | |
| CN117097739A (en) | Server splitting method, equipment and computer readable medium | |
| CN113703691B (en) | Virtual cloud disk method and system | |
| CN117544641A (en) | Cloud host image uploading method and device | |
| CN118708364B (en) | NUMA adaptation method, NUMA optimizer and chip | |
| CN117009308B (en) | Executable file loading method and system based on compatible layer | |
| CN114443130B (en) | Application program transplantation method, device, equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |