CN110347475B - Service calling method, service calling device and service calling system - Google Patents

Service calling method, service calling device and service calling system Download PDF

Info

Publication number
CN110347475B
CN110347475B CN201910533703.3A CN201910533703A CN110347475B CN 110347475 B CN110347475 B CN 110347475B CN 201910533703 A CN201910533703 A CN 201910533703A CN 110347475 B CN110347475 B CN 110347475B
Authority
CN
China
Prior art keywords
service
virtual machine
driving unit
identification information
information
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
Application number
CN201910533703.3A
Other languages
Chinese (zh)
Other versions
CN110347475A (en
Inventor
李伟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dongsoft Group Dalian Co ltd
Neusoft Corp
Original Assignee
Dongsoft Group Dalian Co ltd
Neusoft Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Dongsoft Group Dalian Co ltd, Neusoft Corp filed Critical Dongsoft Group Dalian Co ltd
Priority to CN201910533703.3A priority Critical patent/CN110347475B/en
Publication of CN110347475A publication Critical patent/CN110347475A/en
Application granted granted Critical
Publication of CN110347475B publication Critical patent/CN110347475B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10Program control for peripheral devices
    • G06F13/102Program control for peripheral devices where the programme performs an interfacing function, e.g. device driver
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45562Creating, 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)
  • Computer And Data Communications (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The disclosure relates to a service calling method, a service calling device and a service calling system. The service calling method comprises the following steps: if a first service address acquisition request sent by a virtual machine client is received, determining whether a target service corresponding to service identification information is a shared service of a host according to the service identification information included in the first service address acquisition request; if the target service is not the shared service, generating a second service address acquisition request, wherein the second service address acquisition request comprises service identification information and identification information of the virtual machine; sending a second service address acquisition request to the first driving unit; and receiving address information of the target service returned by the first driving unit, and sending the address information to the virtual machine client, so that the virtual machine client can call the target service according to the address information. Therefore, the purpose that multiple persons operate respective applications on one chip simultaneously without mutual interference can be achieved, and the requirement of simultaneous entertainment of multiple persons is met.

Description

Service calling method, service calling device and service calling system
Technical Field
The present disclosure relates to the field of vehicle-mounted entertainment technologies, and in particular, to a service invocation method, a service invocation device, and a service invocation system.
Background
Along with the popularization of automobiles, the intelligent development of the vehicle-mounted entertainment system is mature day by day, the requirements of people on in-vehicle entertainment are diversified and complicated, the simple vehicle-mounted entertainment application of listening music and broadcasting cannot meet the requirements of people, and the requirements of multi-screen interaction and multi-person entertainment are gradually the standard configuration of the vehicle-mounted entertainment system.
Because the Android ecosystem is relatively mature, and third-party application and entertainment software are very popular, most of the current vehicle-mounted entertainment systems adopt the Android system. However, the existing Android system basically only supports single-person operation, for example, a vehicle-mounted entertainment system can only receive operation input by one passenger at the same time, and thus, when multiple passengers exist in a vehicle at the same time, some passengers cannot operate the vehicle-mounted entertainment system. Therefore, in the related art, the vehicle-mounted entertainment System cannot enable multiple users to operate their respective applications on one SOC (System on Chip) at the same time without mutual interference, which results in that the vehicle-mounted entertainment System in the related art cannot meet the requirement of multiple users for entertainment at the same time.
Disclosure of Invention
The purpose of the disclosure is to provide a service calling method, a service calling device and a service calling system, so as to meet the requirement of entertainment of multiple people at the same time.
In order to achieve the above object, the present disclosure provides a service invocation method, including: if a first service address acquisition request sent by a virtual machine client is received, determining whether a target service corresponding to service identification information is a shared service of a host according to the service identification information included in the first service address acquisition request, wherein a virtual machine where the virtual machine client is located and the host coexist on the same chip; if the target service is not the shared service, generating a second service address acquisition request, wherein the second service address acquisition request comprises the service identification information and the identification information of the virtual machine; sending the second service address acquisition request to a first driving unit so as to acquire the address information of the target service from a service manager through the first driving unit according to the service identification information and the identification information of the virtual machine, wherein the first driving unit is coupled between a host client and a host server, the first driving unit is further coupled with the service manager, and the service manager stores the service identification information of the first service provided by the virtual machine server, and a first corresponding relationship between the identification information of the virtual machine and the address information of the first service; and receiving the address information of the target service returned by the first driving unit, and sending the address information to the virtual machine client, so that the virtual machine client can call the target service according to the address information.
Optionally, the service manager further stores a second correspondence between service identification information of a second service provided by the host server and address information of the second service; and, the method further comprises: and if the target service is the shared service, sending the first service address acquisition request to the first driving unit so as to acquire the address information of the target service from the service manager through the first driving unit according to the service identification information of the target service.
Optionally, the method further comprises: receiving a service calling request sent by the virtual machine client, wherein the service calling request comprises address information of the target service; sending the service calling request to the virtual machine service end or the first driving unit so as to send the service calling request to the host service end through the first driving unit, wherein the service calling request is used for enabling the service end receiving the service calling request to execute the target service according to the address information of the target service; receiving execution result information, wherein the execution result information is returned after the virtual machine server executes the target service, or is sent to the first driving unit and returned through the first driving unit after the host server executes the target service; and sending the execution result information to the virtual machine client.
Optionally, the method further comprises: receiving layer information to be displayed sent by the virtual machine client, wherein the layer information to be displayed comprises layer data to be displayed and identification information of the virtual machine; and sending the layer information to be displayed to the first driving unit, so that the layer information to be displayed is sent to a layer merging unit of the host through the first driving unit, so that the layer merging unit merges the layer information to be displayed corresponding to the same virtual machine at intervals of preset time length to obtain target display layer data, and sends the target display layer data to a display screen corresponding to the virtual machine for displaying, wherein the first driving unit is further coupled with the layer merging unit.
The present disclosure also provides a service invoking device, including: a determining module, configured to determine, if a first service address acquisition request sent by a virtual machine client is received, whether a target service corresponding to service identification information is a shared service of a host according to the service identification information included in the first service address acquisition request, where a virtual machine in which the virtual machine client is located and the host coexist on the same chip; a generating module, configured to generate a second service address obtaining request if the target service is not the shared service, where the second service address obtaining request includes the service identification information and the identification information of the virtual machine; a first sending module, configured to send the second service address obtaining request to a first driving unit, so as to obtain, by the first driving unit, address information of the target service from a service manager according to the service identification information and the identification information of the virtual machine, where the first driving unit is coupled between a host client and a host server, the first driving unit is further coupled with the service manager, and the service manager stores therein service identification information of a first service provided by the virtual machine server, and a first correspondence between the identification information of the virtual machine and the address information of the first service; and the first receiving module is used for receiving the address information of the target service returned by the first driving unit and sending the address information to the virtual machine client so that the virtual machine client can call the target service according to the address information.
Optionally, the service manager further stores a second correspondence between service identification information of a second service provided by the host server and address information of the second service; and, the apparatus further comprises: a second sending module, configured to send the first service address obtaining request to the first driving unit if the target service is the shared service, so as to obtain, by the first driving unit, address information of the target service from the service manager according to the service identification information of the target service.
Optionally, the apparatus further comprises: a second receiving module, configured to receive a service invocation request sent by the virtual machine client, where the service invocation request includes address information of the target service; a third sending module, configured to send the service invocation request to the virtual machine server or the first driving unit, so as to send the service invocation request to the host server through the first driving unit, where the service invocation request is used to enable the server that receives the service invocation request to execute the target service according to the address information of the target service; a third receiving module, configured to receive execution result information, where the execution result information is returned after the virtual machine server executes the target service, or is sent to the first driving unit and returned through the first driving unit after the host server executes the target service; and the fourth sending module is used for sending the execution result information to the virtual machine client.
Optionally, the apparatus further comprises: the fourth receiving module is configured to receive to-be-displayed layer information sent by the virtual machine client, where the to-be-displayed layer information includes to-be-displayed layer data and identification information of the virtual machine; and the fifth sending module is configured to send the layer information to be displayed to the first driving unit, so that the layer information to be displayed is sent to the layer merging unit of the host through the first driving unit, so that the layer merging unit merges the layer data to be displayed corresponding to the same virtual machine every preset time period to obtain target display layer data, and sends the target display layer data to a display screen corresponding to the virtual machine for display, where the first driving unit is further coupled to the layer merging unit.
The present disclosure also provides a service invocation system, including: the virtual machine runs in a user space and comprises a virtual machine client and a virtual machine server; a host running in the user space and coexisting with the at least one virtual machine on the same chip, the host comprising a host client, a host server and a service manager, the service manager storing therein service identification information of a first service provided by the virtual machine server of each of the virtual machines, a first correspondence between the identification information of the virtual machine and address information of the first service, and a second correspondence between service identification information of a second service provided by the host server and address information of the second service; the first driving unit runs in a kernel space, and the host client is coupled with the host server through the first driving unit; and at least one second driving unit, corresponding to the virtual machines one to one, running in the kernel space, where the virtual machine client and the virtual machine server on the same virtual machine are coupled through a second driving unit corresponding to the virtual machine, the second driving unit is further coupled with the first driving unit, and the second driving unit is configured to execute the method according to the first aspect of the present disclosure.
Optionally, the host further comprises: and the layer merging unit is coupled with the first driving unit and used for merging the data of the to-be-displayed layer corresponding to the same virtual machine at intervals of preset time length to obtain data of a target displayed layer and sending the data of the target displayed layer to a display screen corresponding to the virtual machine for displaying.
In the above technical solution, the second driving unit corresponding to the virtual machine is coupled with the first driving unit, so that the virtual machine client can obtain address information of a target service that the virtual machine client needs to call from a service manager of the host according to the second driving unit and the first driving unit, and then call the target service according to the address information. In addition, because the service provided by the virtual machine service end can be distinguished from the service provided by the host machine service end or other virtual machine service ends through the identification information of the virtual machine, the problem that the virtual machine or the host machine calls the service provided by other non-self service ends because the service identification information of the service provided by the host machine service end and each virtual machine service end is the same is avoided, and the defect of mutual interference when multiple persons operate simultaneously is avoided, therefore, the purpose that the multiple persons operate respective applications on one chip simultaneously without mutual interference can be realized, and the requirement of multiple persons for entertainment simultaneously is met.
Additional features and advantages of the disclosure will be set forth in the detailed description which follows.
Drawings
The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this specification, illustrate embodiments of the disclosure and together with the description serve to explain the disclosure without limiting the disclosure. In the drawings:
FIG. 1 is a diagram illustrating a namespace in accordance with an exemplary embodiment.
FIG. 2 is a schematic diagram illustrating a service invocation system in accordance with an exemplary embodiment.
FIG. 3 is a flow diagram illustrating a method of service invocation in accordance with an exemplary embodiment.
Fig. 4 is a schematic diagram illustrating a service invocation system according to another exemplary embodiment.
Fig. 5 is a flow chart illustrating a method of service invocation according to another exemplary embodiment.
FIG. 6 is an interaction diagram illustrating a service invocation method in accordance with an exemplary embodiment.
Fig. 7 is a block diagram of a service invocation device according to an exemplary embodiment of the present disclosure.
Detailed Description
The following detailed description of specific embodiments of the present disclosure is provided in connection with the accompanying drawings. It should be understood that the detailed description and specific examples, while indicating the present disclosure, are given by way of illustration and explanation only, not limitation.
Aiming at the defect that multiple persons cannot operate respective applications on one chip simultaneously without mutual interference in the related technology, the inventor considers that LinuxCgroup (Linux control Group) has the characteristic of limiting, controlling and separating resources of a process Group, and LinuxNamespace (Linux namespace) has the characteristic of guaranteeing resource isolation, and provides a service calling method, a service calling device and a service calling system by utilizing the LinuxCgroup characteristic and the LinuxNamespace characteristic based on a Linux Container (Container) technology.
It should be noted that Linux group is called Linux control group, and is mainly used to control resources. Specifically, a group of processes is placed in a control group, and the control group is allocated with a specified available resource, so that the purpose of controlling the available resource of the group of processes is achieved. Linux namespace is called Linux namespace and is mainly used for isolating resources. Specifically, a class of resources is abstracted, packaged together, and the packaged class of resources is stored in a container. For each type of resource, there is a container, and since each container has its own abstraction and is invisible, it can be used to isolate the resource.
In the present disclosure, linux grid is used to isolate physical resources (e.g., CPU (Central Processing Unit) resources, memory resources, etc.), and linux namespace is used to isolate system resources such as Process ID, Inter Process Communication (IPC), Network, etc. For example, different namespaces may be allocated to system resources according to different categories, resources in each Namespace are transparent to other namespaces, and different namespaces are transparent to each other and do not interfere with each other.
Each user has an init process within each Namespace, and the ID corresponding to the init process is 1, even though one physical Linux server is used together with other users, the user can own the Linux server exclusively. In this Linux server, there is an init process of its own (the ID of this process is 1), and the IDs of other processes are sequentially incremented. As shown in fig. 1, the parent namespace includes four processes, which are respectively labeled as: 1. 2, 3, 4, and, in fig. 1, assume that the parent namespace includes two child namespaces: sub-namespace A and sub-namespace B. The child namespace A and the child namespace B both have processes with ID 1, each process of the child namespace can be mapped to a process of the parent namespace, and the parent namespace can know the running state of each child namespace. The parent namespace includes all processes running on the host, and the child namespace A, the child namespace B and the parent namespace are isolated from each other.
As shown in fig. 1, process 3 has an ID of 3 in the parent namespace, but the ID of process 3 in the child namespace a has an ID of 1, that is, the user may consider process 3 to be an initialization process (init process) of the child namespace a from the perspective of the child namespace a, but the child namespace a is only one of the virtualized subspaces of process 3 from the perspective of the entire host. Similarly, the sub-namespace B is just a sub-space virtualized by process 4. Note that the process with ID 2 in the sub-namespace a is hatched by the process with ID 1 in the sub-namespace a. The process with ID 2 in sub-namespace B is hatched by the process with ID 1 in sub-namespace B. In the present disclosure, a virtual machine is constructed from the set of processes within each child namespace and the system resources allocated by the CGroup for each child namespace.
Based on the above scheme for constructing the virtual machine, the present disclosure provides a service invocation system, which may include: the system comprises at least one virtual machine, a host, a first driving unit and at least one second driving unit, wherein the second driving units correspond to the virtual machines one to one.
The at least one virtual machine runs in a user space, and each virtual machine comprises a virtual machine client and a virtual machine server; the host also runs in the user space, the host and at least one virtual machine coexist on the same chip, and the host may include a host client, a host server and a service manager, where the service manager stores therein service identification information of a first service provided by the virtual machine server of each virtual machine, a first correspondence between the identification information of the virtual machine and address information of the first service, and a second correspondence between service identification information of a second service provided by the host server and address information of the second service.
A first drive unit running in the kernel space and passing between the host client and the host server
A first drive unit coupling; and the at least one second driving unit runs in the kernel space, the virtual machine client and the virtual machine server on the same virtual machine are coupled through the second driving unit corresponding to the virtual machine, and the second driving unit is also coupled with the first driving unit. Therefore, the host client and the host server can communicate through the first driving unit, the virtual machine client and the virtual machine service on the same virtual machine can communicate through the second driving unit corresponding to the virtual machine, and the virtual machine and the host can also communicate through the second driving unit and the first driving unit.
Illustratively, as shown in fig. 2, the service invocation system described above may include: virtual machine 101Virtual machine 102A host 20, a first driving unit 30, a second driving unit 401A second driving unit 402. Wherein the virtual machine 101Virtual machine 10, which can be constructed based on sub-namespace A in FIG. 12Can be constructed based on the sub-namespace B in FIG. 1. Virtual machine 101Virtual machine 102And the host 20 runs in a user space, each virtual machine comprises a virtual machine client and a virtual machine server, the host 20 comprises a host client, a host server and a service manager, and the service manager stores the virtual machine 10 therein1The virtual machine server provides service identification information of a first service, a first correspondence between the identification information of the virtual machine and address information of the first service, and the virtual machine 102The service identification information of the first service provided by the virtual machine service end, the first corresponding relation between the identification information of the virtual machine and the address information of the first service, and the second corresponding relation between the service identification information of the second service provided by the host service end and the address information of the second service. First and second drive units 30 and 401A second driving unit 402All operate in kernel space. The host client and the host server are coupled through a first driving unit 30. Second drive unit 401And virtual machine 101Correspondingly, virtual machine 101Between the virtual machine client and the virtual machine server via the second driving unit 401And (4) coupling. Second drive unit 402And virtual machine 102Correspond toVirtual machine 102Between the virtual machine client and the virtual machine server via the second driving unit 402And (4) coupling. And a second driving unit 401A second driving unit 402And also coupled to the first driving units 30, respectively.
It should be understood that, when the host system is an Android system, the system of the virtual machine is also an Android system, and accordingly, the first driving unit 30 may be a binder driving unit, and the second driving unit 40 may be a binder driving unit1A second driving unit 402May be a combiner drive unit. Wherein, the binder drive unit is obtained based on the binder drive unit.
Specifically, the binder driver unit runs in the kernel space, but it provides file system call functions such as open, close, ioctl, mmap, etc. for the user space, and these system call functions are used by services running in the user space. The ioctl system call function is used for controlling sending and receiving of communication data and communication response data between two communication processes. Therefore, in the process of packaging the binder driving unit to obtain the binder driving unit, the inventor redirects the ioctl system call function to obtain an ioctl1 system call function, and introduces the ioctl1 system call function into the binder driving unit, so that the binder driving unit can provide the ioctl1 system call function for the user space. It should be noted that, the ioctl1 system call function in the binder driving unit needs to be customized, taking the service call method provided by the present disclosure as an example, the ioctl1 system call function may be defined by two parts, where one part is a command for generating a second service address acquisition request according to service identification information included in the first service address acquisition request and identification information of the virtual machine when the target service is the unshared service, and the second part is a command for sending the first service address acquisition request to the binder driving unit when the target service is the shared service and sending the second service address acquisition request to the binder driving unit when the target service is the unshared service.
Illustratively, the binder driver unit provides a device call interface of/dev/binder N for the user space, and the code for registering the binder driver unit is as follows:
initializing function static int __ initcombiner _ init (void);
{
int ret;
init_devs(MAX_CONBINDER);
// register/dev/conbinedern device driver
ret=register_devs(9);
V/registration/dev/connectidern device driver, and N is 9
init_default_shared_services();
conbinder_proc_root=proc_mkdir("conbinder",NULL);
conbinder_proc_sharedservices=proc_create("sharedservices",0666,conbinder_proc_root,&conbinder_proc_fops);
proc_buffer_ss=(char*)get_zeroed_page(GFP_KERNEL);
return ret;
}
The code in which the file operation related function is registered is as follows:
staticconststructfile_operationsconbinder_fops={
.owner=THIS_MODULE,
.poll=binder_poll,
.unlocked_ioctl1=conbinder_ioctl1,
.compat_ioctl1=conbinder_ioctl1,
.mmap=binder_mmap,
.open=binder_open,
.flush=binder_flush,
.release=binder_release,
};
when a user opens/dev/conjugate N and calls ioctl1, it is called into conjugate _ ioctl1, and the conjugate _ ioctl1 is the main implementation part of the conjugate driver, and its code logic is as follows:
static long conbinder_ioctl1(struct file*filp,unsigned intcmd,unsignedlong arg)
interface description// interface description:
// file: file pointer passed on call for user
I/cmd, Command data communicated in for the user
V/arg as parameters for user commands
It should be noted that Linux simplifies the segmentation mechanism, so that the virtual address is always consistent with the linear address, and therefore the virtual address space of Linux is also 0-4G. The Linux kernel divides the 4 gigabytes of space into two parts. The highest 1 Gbyte (from virtual address 0xC0000000 to 0xFFFFFFFF) is used by the kernel, called "kernel space". And the lower 3 gigabytes (from virtual addresses 0x00000000 to 0xBFFFFFFF) are used by various processes, called "user space". Kernel space and user space typically communicate through system service calls. The service invocation method provided by the present disclosure will be described in detail below.
Fig. 3 is a flowchart illustrating a service invocation method according to an exemplary embodiment, which is applied to a second driving unit in the service invocation system. As shown in fig. 3, the method may include the following steps.
In step 21, if a first service address obtaining request sent by a virtual machine client is received, determining whether a target service corresponding to service identification information is a shared service of a host according to the service identification information included in the first service address obtaining request, where a virtual machine where the virtual machine client is located and the host coexist on the same chip.
It should be understood that, when a client of a virtual machine or a host needs to invoke a target service in a server of the virtual machine or the host where the client is located, communication needs to be established with the target service, and before the communication is established with the target service, address information of the target service needs to be obtained first, and then the client can communicate with the target service according to the address information of the target service. Therefore, when the client needs to call the target service, the first service address acquisition request is sent. The first service address acquisition request is used for requesting address information of a target service which a virtual machine client wants to call, and the first service address acquisition request comprises service identification information of the target service.
In this disclosure, since the second driving unit is coupled to the virtual machine client, when the virtual machine client sends a first service address obtaining request, correspondingly, the second driving unit may receive the first service address obtaining request, and determine whether a target service corresponding to the service identification information is a shared service according to the service identification information included in the first service address obtaining request. The service identification information may be a name of the service, for example, the service identification information of the window management service may be: WindowManager. The shared service of the host refers to a service which is provided by the host server and can be used by the virtual machine and the host together.
In an embodiment, when receiving a first service address acquisition request, a second driving unit traverses a shared service list pre-stored in a kernel space, determines whether service identification information included in the first service address acquisition request is located in the shared service list, and determines that the target service is not a shared service if the service identification information included in the first service address acquisition request is not located in the shared service list. The shared service list includes service identification information of the shared service, and the shared service may be predetermined by the user according to actual needs.
In step 22, if the target service is not the shared service, a second service address obtaining request is generated, where the second service address obtaining request includes the service identification information and the identification information of the virtual machine.
In the present disclosure, the identification information of the virtual machine may be a virtual machine ID set by the user when creating the virtual machine, for example, the user may name the virtual machine as: virtual machine 1, virtual machine 2, etc. Wherein, "1" and "2" are IDs of the virtual machine 1 and the virtual machine 2, that is, identification information of the virtual machine 1 and the virtual machine 2.
It should be noted that, when a user registers a service provided by a virtual machine server in a service manager, the service provided by the virtual machine server may be distinguished from services provided by a host server or other virtual machine servers by using identification information of a virtual machine. Therefore, the service identification information of the service provided by the host server and the service identification information of the service provided by each virtual machine server can coexist in the service manager in the host, and conflict caused by the fact that the service identification information of the service provided by the host server and each virtual machine server is the same does not occur.
For example, when a user registers a service provided by a virtual machine server in a service manager, if the registered service is not a shared service, that is, the service is a service provided by the virtual machine server, at this time, the service identification information of the service may be added to the identification information of the virtual machine before or after the service identification information of the service, for example, if the window management service is a non-shared service and the identification information of the virtual machine where the virtual machine server providing the service is located is 1, the service identification information of the window management service may be determined to be 1WindowManagerService or may be determined to be WindowManagerService 1. Of course, the service provided by the host server and the service provided by the virtual machine server can be determined in other forms as long as the services provided by the host server and the virtual machine server can be distinguished.
It should be noted that, in one case, the second driving units correspond to the virtual machines one to one, and when the virtual machines and the second driving units are created, the second driving units can acquire the identification information of the virtual machines corresponding to the second driving units. In this way, when determining that the target service is not the shared service, the second driving unit may generate the second service address acquisition request according to the service identification information and the identification information of the virtual machine. In another case, the first service address obtaining request sent by the virtual machine client may include, in addition to the service identification information, identification information of a virtual machine in which the virtual machine client is located. In this way, when determining that the target service is not the shared service, the second driving unit may generate the second service address acquisition request according to the service identification information and the identification information of the virtual machine.
In step 23, a second service address obtaining request is sent to the first driving unit, so as to obtain address information of the target service from the service manager through the first driving unit according to the service identification information and the identification information of the virtual machine, wherein the first driving unit is coupled between the host client and the host server, the first driving unit is further coupled with the service manager, and the service manager stores therein the service identification information of the first service provided by the virtual machine server, the first correspondence between the identification information of the virtual machine and the address information of the first service.
Since the first driving unit is coupled to the service manager, and the service manager stores the service identification information of the first service provided by the virtual machine service end, the first corresponding relationship between the identification information of the virtual machine and the address information of the first service, after the first driving unit receives the second service address acquisition request including the service identification information and the identification information of the virtual machine, the address information of the target service can be searched from the service manager according to the service identification information and the identification information of the virtual machine. The first drive unit may send the address information of the target service to the second drive unit after finding the address information.
In step 24, address information of the target service returned by the first driving unit is received, and the address information is sent to the virtual-machine client, so that the virtual-machine client calls the target service according to the address information.
For example, assuming that Service identification information included in a first Service address acquisition request sent by a virtual machine client is WindowManager Service, the second driving unit determines that a target Service is window management Service according to the first Service address acquisition request, and determines that the target Service is not shared Service if the Service identification information of the window management Service is not in a shared Service list. At this time, the second driving unit generates a second Service address acquisition request according to the Service identification information WindowManager Service of the window management Service and the identification information of the corresponding virtual machine, for example, when the Service provided by the virtual machine server is registered in the Service manager, if the identification information of the virtual machine is added before the Service identification information, the second Service address acquisition request includes 1WindowManager Service. And if the identification information of the virtual machine is added after the Service identification information, the second Service address acquisition request comprises a WindowManagerService 1. The second drive unit sends a second service address acquisition request to the first drive unit. When receiving the second service address acquisition request, the first drive unit searches the corresponding address information in the service manager according to 1windowManagerservice or WindowManagerservice1, and returns the address information to the second drive unit. The second driving unit sends the received address information to the virtual machine client, so that the virtual machine client can call the target service according to the address information.
Illustratively, as shown in fig. 4, assume that two virtual machines, such as virtual machine 1 and virtual machine 2, are created based on the linux client technology described above and the Android host (host in fig. 4). The system of the virtual machine 1 is Android 1, the system of the virtual machine 2 is Android 2, and the virtual machine 1 corresponds to the display screen 1, that is, the display content of the virtual machine 1 can be displayed on the display screen 1, and the virtual machine 2 corresponds to the display screen 2, that is, the display content of the virtual machine 2 can be displayed on the display screen 2. For example, passenger a may operate on the virtual machine client of virtual machine 1, so that the virtual machine client of virtual machine 1 sends a first service address acquisition request to binder1 corresponding to virtual machine 1, where the first service may be any service pre-installed in virtual machine 1, which may be, for example: window management services, QQ services, WeChat services, and the like. As shown in fig. 4, taking the first service as the window management service as an example, the binder1 executes the above steps 21-24 after receiving the address acquisition request, so that the virtual machine client of the virtual machine 1 can call the window management service according to the address information and display the display content corresponding to the window management service on the display screen 1.
Similarly, the operation of the passenger B in the virtual machine client of the virtual machine 2 in the same vehicle can be received by the Android 2. For example, passenger B may operate on the virtual machine client of virtual machine 2, so that the virtual machine client of virtual machine 2 sends a first service address acquisition request to binder2 corresponding to virtual machine 2, where the first service may be any service pre-installed in virtual machine 2, which may also be, for example: window management services, camera management services, and the like. As shown in fig. 4, taking the first service as the camera management service as an example, the binder2 performs the above steps 21-24 after receiving the first service address acquisition request, so that the virtual machine client of the virtual machine 2 can call the camera management service according to the address information and display the display content corresponding to the camera management service on the display screen 2. Therefore, the passenger A and the passenger B in the same vehicle can operate respective applications on one chip simultaneously without mutual interference, and the requirement of simultaneous entertainment of multiple people can be met.
As shown in fig. 4, the virtual machines 1 and 2 share a host CPU and a Graphics Processing Unit (GPU) of the host, and the CPU of the host in fig. 4 is a 4-core CPU. In the present disclosure, the display content corresponding to the window management service is displayed in the display screen 1, and the display content corresponding to the camera management service is displayed in the display screen 2, which are both controlled by the host, and a specific implementation of displaying the display content corresponding to the target service by the display screen will be described in detail below, which is not described herein again. In addition, the host may also correspond to another display screen (not shown in fig. 4), so that the display content corresponding to the target service called by the host may also be displayed in the corresponding display screen.
For example, it is assumed that the QQ management service is a non-shared service, but identification information of a virtual machine is not used for distinguishing when the QQ management service provided by the virtual machine server and the QQ management service provided by the host server are registered, and thus, when the passenger a calls the QQ management service in the virtual machine, there may be a case where the QQ management service provided by the host server is called. In one embodiment, if the passenger a is using the QQ management service in the virtual machine, and the passenger B is using the QQ management service in the host and communicating with the QQ friend C thereof, when the passenger a wants to communicate with the QQ friend D thereof, the first driving unit may return the address information of the QQ management service provided by the host server to the second driving unit, so that the second driving unit returns the address information of the QQ management service provided by the host server to the virtual machine client, which may cause the virtual machine client to call the QQ management service provided by the host server, and further cause the communication interface of the passenger B and the QQ friend C thereof to be displayed on the display screen corresponding to the virtual machine. Therefore, if the service provided by the virtual machine server is not distinguished from the service provided by the host server or other virtual machine servers, the services will interfere with each other when multiple users operate simultaneously.
In the disclosure, when a user registers a service provided by a virtual machine server in a service manager, the QQ management service provided by the virtual machine server can be distinguished from the QQ management service provided by a host server by using identification information of a virtual machine, so that even if a passenger a and a passenger B use the QQ management service at the same time, the first driving unit can search address information corresponding to the QQ management service provided by the virtual machine server in the service manager based on the identification information of the virtual machine, so that the virtual machine client can call the QQ management service provided by the virtual machine server of the virtual machine where the virtual machine client is located according to the address information, thereby ensuring that the passenger a and the passenger B use the QQ management service provided by the corresponding service terminals (for example, the passenger a uses the QQ management service provided by the virtual machine server, and the passenger B uses the QQ management service provided by the host server), the problem of mutual interference does not occur.
In the above technical solution, the second driving unit corresponding to the virtual machine is coupled with the first driving unit, so that the virtual machine client can obtain address information of a target service that the virtual machine client needs to call from a service manager of the host according to the second driving unit and the first driving unit, and then call the target service according to the address information. In addition, because the service provided by the virtual machine service end can be distinguished from the service provided by the host machine service end or other virtual machine service ends through the identification information of the virtual machine, the problem that the virtual machine or the host machine calls the service provided by other non-self service ends because the service identification information of the service provided by the host machine service end and each virtual machine service end is the same can not be caused, and the defect of mutual interference when a plurality of people operate simultaneously can be avoided. Therefore, the purpose that multiple persons operate respective applications on one chip at the same time without mutual interference can be achieved, and the requirement of simultaneous entertainment of multiple persons is met.
Fig. 5 is a flowchart illustrating a service invoking method according to another exemplary embodiment, and a second corresponding relationship between service identification information of a second service provided by a host server and address information of the second service is further stored in a service manager. The above method may further include the following steps as shown in fig. 5.
In step 25, if the target service is a shared service, a first service address obtaining request is sent to the first driving unit, so as to obtain the address information of the target service from the service manager through the first driving unit according to the service identification information of the target service.
In an embodiment, if service identification information included in the first service address acquisition request is located in a shared service list, it is determined that a target service corresponding to the service identification information is a shared service. Since the shared service is a service provided by the host server, and there is only one host, when the user registers the service provided by the host server in the service manager, the user does not need to consider the identification information of the host, in this embodiment, if the target service is the shared service, the second driving unit directly sends the first service address acquisition request to the first driving unit. In addition, since the service manager stores the second corresponding relationship between the service identification information of the second service provided by the host service end and the address information of the second service, when the first driving unit receives the first service address acquisition request, the address information of the target service can be acquired from the service manager according to the service identification information of the target service.
Through the technical scheme, the second driving unit can receive the address information of the non-shared service returned by the first driving unit and also can receive the address information of the shared service returned by the first driving unit. Therefore, the aim of distinguishing the respective services of the virtual machine and the host can be fulfilled while the virtual machine and the host share the services.
A detailed procedure of the service invocation method provided by the present disclosure will be described below with reference to fig. 6. FIG. 6 is an interaction diagram illustrating a service invocation method in accordance with an exemplary embodiment. As shown in fig. 6, the method may include the following steps.
In step 41, the second driving unit receives a first service address obtaining request sent by the virtual machine client, where the first service address obtaining request includes service identification information.
In step 42, the second driving unit determines whether the target service corresponding to the service identification information is a shared service of the host according to the service identification information. If the target service is not a shared service, steps 43-45 are performed, otherwise steps 46-47 are performed.
In step 43, if the target service is not the shared service, the second driving unit generates a second service address obtaining request, where the second service address obtaining request includes the service identification information and the identification information of the virtual machine.
In step 44, the second drive unit sends a second service address acquisition request to the first drive unit.
In step 45, the first driving unit acquires address information of the target service from the service manager according to the service identification information and the identification information of the virtual machine.
In step 46, if the target service is the shared service, the second driving unit sends a first service address obtaining request to the first driving unit.
In step 47, the first drive unit acquires address information of the target service from the service manager according to the service identification information of the target service.
In step 48, the first drive unit returns address information of the target service to the second drive unit.
Exemplarily, the first correspondence and the second correspondence stored in the service manager are as shown in table 1. In table 1, the Camera Service and the NFC Service provide Service identification information of the shared Service provided by the host server, and the corresponding address information is: 0x01, 0x 02. The system comprises a virtual machine server, a WindowManagerService and a WindowManagerService, wherein the WindowManagerService is Service identification information of non-shared services, represents the Service identification information of services provided by the host server, and has the corresponding address information of 0x03, the 1WindowManagerService represents the Service identification information of the services provided by the virtual machine server, and the corresponding address information is 0x 04.
TABLE 1
Service identification information Address information
Camera Service Handler:0x01
NFC Service Handler:0x02
WindowManager Service Handler:0x03
1WindowManager Service Handler:0x04
As can be seen from table 1, when the Service identification information of the target Service is the NFC Service, the second driving unit sends the first Service address acquisition request to the first driving unit because the target Service corresponding to the Service identification information is the shared Service. Thus, the first driving unit can search the address information 0x02 corresponding to the NFC Service in the Service manager according to the NFC Service, and return the address information to the second driving unit. When the Service identification information of the target Service is the WindowManagerService, because the target Service corresponding to the Service identification information is the non-shared Service, the second driving unit generates a second Service address acquisition request according to the Service identification information of the target Service and the identification information of the virtual machine, wherein the second Service address acquisition request comprises 1 WindowManagerService. Thus, when receiving the second service address acquisition request, the first drive unit may search, according to 1WindowManagerService, address information 0x04 corresponding to 1WindowManagerService in the service manager, and return the address information to the second drive unit.
In step 49, the second drive unit sends the address information to the virtual-machine client.
In step 410, the second driver unit receives a service invocation request sent by the virtual-machine client, where the service invocation request includes address information of the target service.
In step 411, the second driver unit sends a service invocation request to the virtual machine server or the first driver unit, where the service invocation request is used to enable the server receiving the service invocation request to execute the target service according to the address information of the target service.
Since the shared service is provided by the host server and the non-shared service of the virtual machine is provided by the virtual machine server of the virtual machine, if the virtual machine client needs to invoke the shared service, the second driving unit needs to send the service invocation request to the first driving unit so as to send the service invocation request to the host server through the first driving unit, and if the virtual machine client needs to invoke the non-shared service, the second driving unit needs to send the service invocation request to the virtual machine server.
In one embodiment, the service invocation request may further include service identification information of the target service in addition to the address information, so that when receiving the service invocation request, the second driving unit may query a preset shared service list according to the service identification information included in the service invocation request to determine whether the target service is a shared service. And if the target service is not the shared service, sending a service calling request to the virtual machine service end. And if the target service is the shared service, sending a service calling request to the first driving unit.
In another embodiment, when receiving the address information returned by the first driving unit, the second driving unit may record whether the address information is obtained based on the first service address acquisition request or the second service address acquisition request. In this way, when receiving a service invocation request sent by the virtual machine client, the second driving unit sends the service invocation request to the virtual machine client if determining that the address information included in the service invocation request is obtained based on the second service address acquisition request. And if the address information included in the service calling request is determined to be obtained based on the first service address acquisition request, sending the service calling request to the first driving unit.
In step 412, the second driving unit receives the execution result information and sends the execution result information to the virtual-machine client.
If the second driver unit sends the service invocation request to the vm server in step 411, the execution result information is returned after the vm server executes the target service. If the second driver unit sends the service invocation request to the first driver unit in step 411, the execution result information is sent to the first driver unit and returned by the first driver unit after the host server executes the target service.
Therefore, the purpose of calling the target service by the virtual machine client can be realized, and the requirement that multiple users operate respective applications on one chip simultaneously without mutual interference can be met.
In addition, after the virtual machine client calls the target service, a display interface corresponding to the target service can be displayed in a display screen, so that the user can conveniently view the display interface. In one embodiment, the host further includes an overlay merging unit. The second driving unit receives the layer information to be displayed sent by the virtual machine client, wherein the layer information to be displayed comprises the layer data to be displayed and the identification information of the virtual machine; the layer information to be displayed is sent to the first driving unit, so that the layer information to be displayed is sent to the layer merging unit of the host through the first driving unit, the layer data to be displayed corresponding to the same virtual machine are merged by the layer merging unit every preset time length to obtain target display layer data, and the target display layer data are sent to a display screen corresponding to the virtual machine to be displayed. The layer merging unit is coupled to the first driving unit, and in an Android system, the layer merging unit may be a surfaceflag.
The virtual machine and the host machine both adopt the layer merging unit of the host machine to determine the data of a target display layer. Specifically, when receiving the layer information to be displayed sent by the virtual machine client, the second driving unit sends the layer information to be displayed to the first driving unit. And the first driving unit sends the layer information to be displayed to a layer merging unit of the host. The layer merging unit may merge layer data to be displayed corresponding to the same virtual machine every preset time period to obtain target display layer data, and send the target display layer data to a display screen corresponding to the virtual machine for display. Because the identification information of the same virtual machine is the same, the layer merging unit may determine the layer data to be displayed corresponding to the same virtual machine according to the identification information of the virtual machine. In addition, the layer merging unit periodically works, and the preset time length is the time length of the layer merging unit in an inoperative state in one period. It should be understood that the layer merging unit merges the layer data to be displayed, which belongs to the prior art and is not described herein again.
In the present disclosure, a plurality of display screens are provided, for example, one display screen at each seat in the rear row of the cabin in the vehicle. Each virtual machine can correspond to a display screen, and the content needing to be displayed in the virtual machines can be displayed in the corresponding display screens, so that the user can operate freely in the display screens corresponding to the seats of the user without influencing the use of other passengers, and therefore the requirement of simultaneous entertainment of multiple people can be met.
Based on the same inventive concept, the disclosure also provides a service calling device. Fig. 7 is a block diagram of a service invocation device according to an exemplary embodiment of the present disclosure. As shown in fig. 7, the service invocation means 500 may include:
a determining module 501, configured to determine, if a first service address acquisition request sent by a virtual machine client is received, according to service identification information included in the first service address acquisition request, whether a target service corresponding to the service identification information is a shared service of a host, where a virtual machine where the virtual machine client is located and the host coexist on the same chip;
a generating module 502, configured to generate a second service address obtaining request if the target service is not the shared service, where the second service address obtaining request includes the service identification information and the identification information of the virtual machine;
a first sending module 503, configured to send the second service address obtaining request to a first driving unit, so as to obtain, by the first driving unit, address information of the target service from a service manager according to the service identification information and the identification information of the virtual machine, where the first driving unit is coupled between a host client and a host server, the first driving unit is further coupled with the service manager, and a first correspondence relationship between the service identification information of the first service provided by the virtual machine server, the identification information of the virtual machine, and the address information of the first service is stored in the service manager;
a first receiving module 504, configured to receive address information of the target service returned by the first driving unit, and send the address information to the virtual machine client, so that the virtual machine client invokes the target service according to the address information.
Optionally, the service manager further stores a second correspondence between service identification information of a second service provided by the host server and address information of the second service; and, the apparatus further comprises:
a second sending module, configured to send the first service address obtaining request to the first driving unit if the target service is the shared service, so as to obtain, by the first driving unit, address information of the target service from the service manager according to the service identification information of the target service.
Optionally, the apparatus further comprises:
a second receiving module, configured to receive a service invocation request sent by the virtual machine client, where the service invocation request includes address information of the target service;
a third sending module, configured to send the service invocation request to the virtual machine server or the first driving unit, so as to send the service invocation request to the host server through the first driving unit, where the service invocation request is used to enable the server that receives the service invocation request to execute the target service according to the address information of the target service;
a third receiving module, configured to receive execution result information, where the execution result information is returned after the virtual machine server executes the target service, or is sent to the first driving unit and returned through the first driving unit after the host server executes the target service;
and the fourth sending module is used for sending the execution result information to the virtual machine client.
Optionally, the apparatus further comprises:
the fourth receiving module is configured to receive to-be-displayed layer information sent by the virtual machine client, where the to-be-displayed layer information includes to-be-displayed layer data and identification information of the virtual machine;
and the fifth sending module is configured to send the layer information to be displayed to the first driving unit, so that the layer information to be displayed is sent to the layer merging unit of the host through the first driving unit, so that the layer merging unit merges the layer data to be displayed corresponding to the same virtual machine every preset time period to obtain target display layer data, and sends the target display layer data to a display screen corresponding to the virtual machine for display, where the first driving unit is further coupled to the layer merging unit.
With regard to the apparatus in the above-described embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.
The preferred embodiments of the present disclosure are described in detail with reference to the accompanying drawings, however, the present disclosure is not limited to the specific details of the above embodiments, and various simple modifications may be made to the technical solution of the present disclosure within the technical idea of the present disclosure, and these simple modifications all belong to the protection scope of the present disclosure.
It should be noted that the various features described in the above embodiments may be combined in any suitable manner without departing from the scope of the invention. In order to avoid unnecessary repetition, various possible combinations will not be separately described in this disclosure.
In addition, any combination of various embodiments of the present disclosure may be made, and the same should be considered as the disclosure of the present disclosure, as long as it does not depart from the spirit of the present disclosure.

Claims (7)

1. A service invocation method, characterized by comprising:
if a first service address acquisition request sent by a virtual machine client is received, determining whether a target service corresponding to service identification information is a shared service of a host according to the service identification information included in the first service address acquisition request, wherein a virtual machine where the virtual machine client is located and the host coexist on the same chip;
if the target service is not the shared service, generating a second service address acquisition request, wherein the second service address acquisition request comprises the service identification information and the identification information of the virtual machine;
sending the second service address acquisition request to a first driving unit so as to acquire the address information of the target service from a service manager through the first driving unit according to the service identification information and the identification information of the virtual machine, wherein the first driving unit is coupled between a host client and a host server, the first driving unit is further coupled with the service manager, and the service manager stores the service identification information of the first service provided by the virtual machine server, and a first corresponding relationship between the identification information of the virtual machine and the address information of the first service;
receiving address information of the target service returned by the first driving unit, and sending the address information to the virtual machine client, so that the virtual machine client can call the target service according to the address information, and record that the address information is obtained based on the first service address acquisition request or the second service address acquisition request;
receiving layer information to be displayed sent by the virtual machine client, wherein the layer information to be displayed comprises layer data to be displayed and identification information of the virtual machine;
and sending the layer information to be displayed to the first driving unit, so that the layer information to be displayed is sent to a layer merging unit of the host through the first driving unit, so that the layer merging unit merges the layer information to be displayed corresponding to the same virtual machine at intervals of preset time length to obtain target display layer data, and sends the target display layer data to a display screen corresponding to the virtual machine for displaying, wherein the first driving unit is further coupled with the layer merging unit.
2. The method according to claim 1, wherein the service manager further stores a second correspondence between service identification information of a second service provided by the host server and address information of the second service; and, the method further comprises:
and if the target service is the shared service, sending the first service address acquisition request to the first driving unit so as to acquire the address information of the target service from the service manager through the first driving unit according to the service identification information of the target service.
3. The method of claim 1, further comprising:
receiving a service calling request sent by the virtual machine client, wherein the service calling request comprises address information of the target service;
sending the service calling request to the virtual machine service end or the first driving unit so as to send the service calling request to the host service end through the first driving unit, wherein the service calling request is used for enabling the service end receiving the service calling request to execute the target service according to the address information of the target service;
receiving execution result information, wherein the execution result information is returned after the virtual machine server executes the target service, or is sent to the first driving unit and returned through the first driving unit after the host server executes the target service;
and sending the execution result information to the virtual machine client.
4. A service invocation apparatus, characterized by comprising:
a determining module, configured to determine, if a first service address acquisition request sent by a virtual machine client is received, whether a target service corresponding to service identification information is a shared service of a host according to the service identification information included in the first service address acquisition request, where a virtual machine in which the virtual machine client is located and the host coexist on the same chip;
a generating module, configured to generate a second service address obtaining request if the target service is not the shared service, where the second service address obtaining request includes the service identification information and the identification information of the virtual machine;
a first sending module, configured to send the second service address obtaining request to a first driving unit, so as to obtain, by the first driving unit, address information of the target service from a service manager according to the service identification information and the identification information of the virtual machine, where the first driving unit is coupled between a host client and a host server, the first driving unit is further coupled with the service manager, and the service manager stores therein service identification information of a first service provided by the virtual machine server, and a first correspondence between the identification information of the virtual machine and the address information of the first service;
the first receiving module is used for receiving the address information of the target service returned by the first driving unit and sending the address information to the virtual machine client, so that the virtual machine client can call the target service according to the address information and record that the address information is obtained based on the first service address acquisition request or the second service address acquisition request;
the fourth receiving module is configured to receive to-be-displayed layer information sent by the virtual machine client, where the to-be-displayed layer information includes to-be-displayed layer data and identification information of the virtual machine;
and the fifth sending module is configured to send the layer information to be displayed to the first driving unit, so that the layer information to be displayed is sent to the layer merging unit of the host through the first driving unit, so that the layer merging unit merges the layer data to be displayed corresponding to the same virtual machine every preset time period to obtain target display layer data, and sends the target display layer data to a display screen corresponding to the virtual machine for display, where the first driving unit is further coupled to the layer merging unit.
5. The apparatus according to claim 4, wherein the service manager further stores a second correspondence between service identification information of a second service provided by the host server and address information of the second service; and, the apparatus further comprises:
a second sending module, configured to send the first service address obtaining request to the first driving unit if the target service is the shared service, so as to obtain, by the first driving unit, address information of the target service from the service manager according to the service identification information of the target service.
6. The apparatus of claim 4, further comprising:
a second receiving module, configured to receive a service invocation request sent by the virtual machine client, where the service invocation request includes address information of the target service;
a third sending module, configured to send the service invocation request to the virtual machine server or the first driving unit, so as to send the service invocation request to the host server through the first driving unit, where the service invocation request is used to enable the server that receives the service invocation request to execute the target service according to the address information of the target service;
a third receiving module, configured to receive execution result information, where the execution result information is returned after the virtual machine server executes the target service, or is sent to the first driving unit and returned through the first driving unit after the host server executes the target service;
and the fourth sending module is used for sending the execution result information to the virtual machine client.
7. A service invocation system, characterized by comprising:
the virtual machine runs in a user space and comprises a virtual machine client and a virtual machine server;
a host running in the user space and coexisting with the at least one virtual machine on the same chip, the host comprising a host client, a host server and a service manager, the service manager storing therein service identification information of a first service provided by the virtual machine server of each of the virtual machines, a first correspondence between the identification information of the virtual machine and address information of the first service, and a second correspondence between service identification information of a second service provided by the host server and address information of the second service;
the first driving unit runs in a kernel space, and the host client is coupled with the host server through the first driving unit; and
at least one second driving unit, corresponding to the virtual machines one by one, running in the kernel space, where the virtual machine client and the virtual machine server on the same virtual machine are coupled through a second driving unit corresponding to the virtual machine, the second driving unit is further coupled with the first driving unit, and the second driving unit is configured to execute the method according to any one of claims 1 to 3;
the host further comprises: and the layer merging unit is coupled with the first driving unit and used for merging the data of the to-be-displayed layer corresponding to the same virtual machine at intervals of preset time length to obtain data of a target displayed layer and sending the data of the target displayed layer to a display screen corresponding to the virtual machine for displaying.
CN201910533703.3A 2019-06-19 2019-06-19 Service calling method, service calling device and service calling system Active CN110347475B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910533703.3A CN110347475B (en) 2019-06-19 2019-06-19 Service calling method, service calling device and service calling system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910533703.3A CN110347475B (en) 2019-06-19 2019-06-19 Service calling method, service calling device and service calling system

Publications (2)

Publication Number Publication Date
CN110347475A CN110347475A (en) 2019-10-18
CN110347475B true CN110347475B (en) 2022-03-04

Family

ID=68182532

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910533703.3A Active CN110347475B (en) 2019-06-19 2019-06-19 Service calling method, service calling device and service calling system

Country Status (1)

Country Link
CN (1) CN110347475B (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110955399B (en) * 2019-11-29 2024-03-01 东软集团股份有限公司 Vehicle-mounted display system, image display method, storage medium, and host
CN116743903B (en) * 2022-09-09 2024-05-14 荣耀终端有限公司 Chip identification method and electronic equipment

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103339600A (en) * 2010-10-01 2013-10-02 Flex Electronics ID Co.,Ltd. Instant remote rendering
CN103593225A (en) * 2013-10-30 2014-02-19 浙江大学 Method for multiplexing Binder IPC mechanism by multiple Android systems in mobile virtualization scene
CN104951298A (en) * 2014-03-27 2015-09-30 飞搜股份有限公司 Methods and systems for communications between apps and virtual machines
CN108366097A (en) * 2018-01-18 2018-08-03 北京奇艺世纪科技有限公司 Resource access control method and system
CN108574601A (en) * 2018-03-27 2018-09-25 无锡华云数据技术服务有限公司 A kind of gray scale dissemination method and system

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7028312B1 (en) * 1998-03-23 2006-04-11 Webmethods XML remote procedure call (XML-RPC)
US9075661B2 (en) * 2010-10-20 2015-07-07 Microsoft Technology Licensing, Llc Placing objects on hosts using hard and soft constraints
EP2798784B1 (en) * 2011-12-27 2019-10-23 Cisco Technology, Inc. System and method for management of network-based services
US8954964B2 (en) * 2012-02-27 2015-02-10 Ca, Inc. System and method for isolated virtual image and appliance communication within a cloud environment
CN104468171A (en) * 2013-09-25 2015-03-25 和沛科技股份有限公司 Topology architecture management method and system for virtual machines
CN105094997B (en) * 2015-09-10 2018-05-04 重庆邮电大学 Physical memory sharing method and system between a kind of cloud computing host node

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103339600A (en) * 2010-10-01 2013-10-02 Flex Electronics ID Co.,Ltd. Instant remote rendering
CN103593225A (en) * 2013-10-30 2014-02-19 浙江大学 Method for multiplexing Binder IPC mechanism by multiple Android systems in mobile virtualization scene
CN104951298A (en) * 2014-03-27 2015-09-30 飞搜股份有限公司 Methods and systems for communications between apps and virtual machines
CN108366097A (en) * 2018-01-18 2018-08-03 北京奇艺世纪科技有限公司 Resource access control method and system
CN108574601A (en) * 2018-03-27 2018-09-25 无锡华云数据技术服务有限公司 A kind of gray scale dissemination method and system

Also Published As

Publication number Publication date
CN110347475A (en) 2019-10-18

Similar Documents

Publication Publication Date Title
US6560656B1 (en) Apparatus and method for providing downloadable code for use in communicating with a device in a distributed system
CN104823163B (en) Virtual machine configuration based on metadata
US8978051B2 (en) Method and apparatus for displaying application image
CN110347475B (en) Service calling method, service calling device and service calling system
CN112073448B (en) Service isolation method and device for dual-system terminal
WO2018163087A1 (en) System, device and method for accessing shared infrastructure
US20040215725A1 (en) System and method for multi-platform queue queries
WO2018071489A1 (en) Searching index information for application data
CN115543546A (en) Spring-based module heat deployment method and system
JP2002505553A (en) Diversity token based control
US6304918B1 (en) Object interface control system
CN114816655A (en) Device access method and system for secure container
CN115048642A (en) Communication method between trusted applications in multiple trusted execution environments and electronic equipment
CN108667750B (en) Virtual resource management method and device
CN116088784B (en) Image screen projection method, device, electronic equipment, chip, storage medium and vehicle
CN112445568A (en) Data processing method, device and system based on hardware acceleration
US11847611B2 (en) Orchestrating and automating product deployment flow and lifecycle management
CN112583927B (en) Service management system based on airborne embedded real-time operating system
US8978042B2 (en) Method and system for maintaining game functionality for a plurality of game instances running on a computer system
CN106843851A (en) Implementation method and device based on ActiveMQ isomery Classloader unserializings
CN114731343A (en) Cloud service method and device
CN113691575A (en) Communication method, device and system
CN115396478B (en) User domain and equipment communication method and device and automobile
CN109669793A (en) Object calling method in middleware process
CN109901826B (en) Data processing method and device for Java program and electronic equipment

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