Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The terminology used in the embodiments of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in the examples of the present invention and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, and "a" and "an" generally include at least two, but do not exclude at least one, unless the context clearly dictates otherwise.
It should be understood that the term "and/or" as used herein is merely one type of association that describes an associated object, meaning that three relationships may exist, e.g., a and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" herein generally indicates that the former and latter related objects are in an "or" relationship.
It should be understood that although the terms first, second, third, etc. may be used to describe XXX in embodiments of the present invention, these XXX should not be limited to these terms. These terms are used only to distinguish XXX. For example, a first XXX may also be referred to as a second XXX, and similarly, a second XXX may also be referred to as a first XXX, without departing from the scope of embodiments of the present invention.
The words "if", as used herein, may be interpreted as "at … …" or "at … …" or "in response to a determination" or "in response to a detection", depending on the context. Similarly, the phrases "if determined" or "if detected (a stated condition or event)" may be interpreted as "when determined" or "in response to a determination" or "when detected (a stated condition or event)" or "in response to a detection (a stated condition or event)", depending on the context.
It is also noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a good or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such good or system. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a commodity or system that includes the element.
In addition, the sequence of steps in each method embodiment described below is only an example and is not strictly limited.
Fig. 1 is a schematic diagram of a multiplexing scenario of a hardware abstraction layer according to an embodiment of the present invention, as shown in fig. 1, it is assumed that a terminal device includes two operating systems, OS _ a and OS _ B, based on different basic C libraries, where OS _ a is developed based on a basic C library, Libc _ a, and OS _ B is developed based on a basic C library, Libc _ B. Corresponding to this scenario, the hardware abstraction layer multiplexing method provided by the embodiment of the present invention is used to implement the multiplexing of the HAL located on the OS _ a side by the two operating systems shown in fig. 1, i.e., OS _ a and OS _ B.
The initially developed HAL is assumed to be for OS _ a, and is assumed to be a real HAL, as distinguished from a virtual HAL. To enable OS _ B to multiplex the real HAL, a virtual HAL is set on the OS _ B side. Specifically, the configuration (also referred to as definition) of the API encapsulated in the virtual HAL has a corresponding relationship with the configuration of the API encapsulated in the real HAL, wherein preferably, the configuration of the API encapsulated in the virtual HAL may be set to be the same as the configuration of the API encapsulated in the real HAL, but the implementation of the API encapsulated in the virtual HAL is different from the implementation of the API encapsulated in the real HAL, the implementation of the API encapsulated in the virtual HAL indicates that the API called by the OS _ B side is transmitted to the OS _ a side through cross-process communication, and the implementation of the API encapsulated in the real HAL is related operation information that needs to be executed to actually complete the API call.
The configuration of the API encapsulated in the virtual HAL and the configuration of the API encapsulated in the real HAL have a corresponding relationship, which may be expressed as a one-to-one corresponding relationship or a many-to-one corresponding relationship. For example, assuming that there is some API configuration as function (a, B, C) in the real HAL, the API configuration corresponding to the API in the virtual HAL may be: function (A), function (B) and function (C) form a corresponding relationship of three to one.
Among them, since the API implemented in the virtual HAL involves cross-process communication, a cross-process communication (IPC) connection between the two operating systems as shown in fig. 1 needs to be established: IPC Bridge, IPC _ A as illustrated in the figure, IPC _ B is the two-end interface for this communication. Alternatively, the cross-process communication may be established in advance for subsequent direct use, or may be established in real time as needed.
It can be understood that the above-mentioned cross-process communication is established, that is, the interface IPC _ a is established on the OS _ a side, and the interface IPC _ B is established on the OS _ B side, wherein the IPC _ a is based on Libc _ a, and the IPC _ B is based on Libc _ B.
Alternatively, the cross-process communication connection may be implemented based on an IPC mechanism provided in Kernel of the operating system, such as Socket, OpenBinder, but is not limited to these two implementations.
In addition, the real HAL and the virtual HAL in the embodiment of the present invention may be regarded as an abstraction layer for some hardware in the terminal device, such as a hardware abstraction layer of the camera: camera HAL; alternatively, the hardware abstraction layer of the sensor: sensorHAL, and the like.
Based on the setting conditions of the two operating systems, for example, when a certain camera application on the OS _ B side needs to call a camera HAL to operate the camera in response to the operation of the user, the camera application may start a process, which may be regarded as a process B, for example, calling a certain API in the virtual camera HAL, assuming that the configuration and implementation of the API are as follows:
the API is used to trigger the camera opening operation. Wherein, the cool open (int camera id) is the configuration of the API, and the content in { } is the implementation of the API. The camera Id is a call parameter indicating which camera needs to be operated, for example, Id 0 is a front camera and Id 1 is a rear camera. API _ OPEN indicates that OPEN is the calling API, and return returns the returned result of ipc _ send as the API result of OPEN.
As can be seen, the implementation of the API indicates that the call to the API is passed to the OS _ A side through cross-process communication (IPC). Therefore, the process B can create cross-process communication with a certain preset process on the OS _ a side in real time, which is called as process a, and send a call request for the API to the process a through the created cross-process communication. The call request may carry API call related parameters, such as identification information of which API the API to be called is, API _ OPEN, and which camera to be turned on, camera id, so that the process a may call a corresponding API in the real camera HAL according to the call request to complete the operation of the camera required by the camera application program. Assume that the configuration and implementation of the corresponding API in the real camera HAL is as follows:
wherein, open (int camera id) is the configuration of the API, and the content in { } is the implementation of the API. It can be seen that the implementation of the API in the real camera HAL differs from the implementation in the virtual camera HAL, and the implementation in the real camera HAL is specifically the operation information for the corresponding hardware, etc.
In the above examples, the virtual HAL has the same configuration as the API of the real HAL, and is a cool open (intcameraId).
It should be noted that the process a is a process corresponding to the real camera HAL, and may be regarded as a service process of the real camera HAL, and is created in advance, and the process B may be regarded as a client process, and the process a may be started with the start of the OS _ a, and then always monitors whether there is a client process from the OA _ B that needs to call the API in the real camera HAL.
By providing the virtual HAL in OS _ B and having a correspondence between the configuration of the APIs in the virtual HAL and the configuration of the real APIs, the API configuration in the virtual HAL can be formed, for example, by directly copying from the real HAL. And the realization of API in the virtual HAL only needs to provide the sending function of IPC and provide the relevant calling parameter, so that the virtual HAL does not need complex function realization logic relative to the real HAL, namely, does not need to really execute the operation control of hardware, and the realization is simple.
The following embodiments are combined to respectively introduce the hardware abstraction layer multiplexing method provided by the embodiments of the present invention from the perspective of the different operating systems.
Fig. 2 is a flowchart of a hardware abstraction layer multiplexing method according to an embodiment of the present invention, where the hardware abstraction layer multiplexing method according to the embodiment is implemented in the first operating system shown in fig. 1 and is executed by a first process in the first operating system. With reference to fig. 1, it is assumed in this embodiment that the first operating system is OS _ B, the second operating system is OS _ a, the first process is process B, and the second process is process a. As shown in fig. 2, the method comprises the steps of:
201. and responding to the hardware operation instruction, and calling a first application program interface in a virtual hardware abstraction layer corresponding to the first operating system by a first process of the first operating system.
Alternatively, in practical applications, the process B may be a process started by an application program or an application framework layer on the OS _ B side, such as a process started by the camera application program in the above example. Optionally, the process B may also be a dedicated process corresponding to the virtual HAL, and is configured to call an API in the virtual HAL, and at this time, the process B may be accessible to the application program.
Such as: the camera application program responds to a photographing operation instruction triggered by a user, accesses the process B corresponding to the virtual camera HAL corresponding to the camera, and transmits related parameters such as camera identification 0 and working mode-photographing to the first process. Thus, process B calls the photo API in the virtual camera HAL based on the parameter.
202. And the first process sends the call request of the application program interface to the second operating system through cross-process communication, so that the second process in the second operating system calls the second application program interface in the hardware abstraction layer corresponding to the second operating system to execute the hardware operation instruction according to the call request.
The configuration of the first application program interface in the virtual HAL and the configuration of the second application program interface in the HAL corresponding to the second operating system, namely the real HAL, have a corresponding relation.
In this embodiment, it is assumed that the corresponding relationship is embodied in the same configuration, and thus the first API is the same as the second API.
As described above, when a process B calls a certain API, based on the implementation of the API, a call request of the API is sent to the OS _ a through cross-process communication, so that the process a in the OS _ a calls the API in the real HAL corresponding to the process B according to the call request to execute a hardware operation instruction. The content included in the implementation of the API indicates that a call parameter of the API is transmitted to the process a through cross-process communication, where the call parameter includes, for example, an identifier of the API and a hardware identifier corresponding to the API. The process B may extract the invocation parameter therefrom, encapsulate it in an invocation request, and send it to the process a.
In practical applications, the process a calls an API that the process B needs to call in the real HAL to execute the hardware operation instruction, and may or may not involve a callback of a hardware operation result, that is, a callback of the hardware operation result is fed back to the process B. For example, the API may only implement, for example, querying a user terminal device, that has several cameras in common, and there will be no callback of a hardware operation result at this time; for another example, the API may trigger the camera to record a video, and at this time, a hardware operation result is called back, that is, a video captured by the camera is called back to the first process.
Therefore, in the case of hardware operation result callback, process B needs to receive the hardware operation result fed back by process a.
Optionally, the hardware operation result may include: hardware data generated by hardware executing hardware operating instructions, i.e. hardware corresponding to the real HAL, such as the video recording video mentioned above; or the hardware operation result is the storage address of the hardware data in the shared memory; or the hardware operation result is operation failure prompt information.
Optionally, in order to avoid that an excessively large amount of data needs to be transmitted between the process B and the process a, so that the required transmission time is excessively long, and thus, the excessively long occupied time of the real HAL and the virtual HAL affects the call of other processes that need to call the real HAL and the virtual HAL, the process a may determine, according to the size of the data amount of the hardware data, that the hardware data is directly fed back to the process B. For example, when the data amount of the hardware data is smaller than the preset threshold, the hardware data is directly fed back to the process B, otherwise, the hardware data is stored in the shared memory, so that only the storage address of the hardware data in the shared memory is fed back to the process B, and the process B acquires the hardware data from the shared memory. The shared memory is a storage space that can be shared by two preset operating systems.
It should be noted that the operation failure prompt message may be regarded as a special hardware operation result, where the operation failure prompt message is sent to the process B when the process a receives a call request sent by the process B, and before calling a corresponding API in the real HAL based on the call request, if it is recognized that the API to be called has an exclusive operation attribute, and it is determined that the hardware corresponding to the real HAL is in a busy state. When the hardware is in a busy state, it indicates that there are other processes calling the real HAL to operate the hardware, and at this time, the process a cannot call the API in the real HAL, so as to feed back an operation failure prompt message to the first process. The description of the exclusive operation attribute will be described in detail in the following embodiments.
To sum up, the hardware abstraction layer multiplexing method provided in the embodiment of the present invention only needs to set the virtual HAL with the following characteristics on the first operating system side, so that the multiplexing of the first operating system on the real hardware abstraction layer corresponding to the second operating system can be implemented: the configuration of the API set in the virtual HAL has a correspondence L with the API configuration in the real HAL and the API implementation in the virtual HAL is set to pass a call to a certain API in the virtual HAL into the second operating system corresponding to the real HAL by cross-process communication. The scheme is convenient to realize and can be suitable for any different operating systems.
Fig. 3 is a flowchart of another hardware abstraction layer multiplexing method according to an embodiment of the present invention, where the hardware abstraction layer multiplexing method is executed by a first process in a first operating system according to the embodiment. Assume that the first operating system in this embodiment is OS _ a shown in fig. 1, the second operating system is OS _ B shown in fig. 1, the first process is process a shown in fig. 1, and the second process is process B shown in fig. 1, so that, as shown in fig. 3, the method may include the steps of:
301. and the first process receives a call request sent by a second process in the second operating system through cross-process communication, wherein the call request is triggered by the second process responding to a hardware operating instruction to call a first application program interface in a virtual hardware abstraction layer corresponding to the second operating system.
302. And the first process calls a second application program interface in the hardware abstraction layer corresponding to the first operating system according to the call request so as to execute the hardware operation instruction.
The configuration of the first application program interface in the virtual HAL and the configuration of the second application program interface in the hardware abstraction layer corresponding to the first operating system osa, i.e. the real HAL, have a corresponding relationship.
In the present embodiment, the correspondence relationship is assumed to be the same as the configuration of the first application program interface in the virtual HAL and the configuration of the second application program interface in the real HAL, and the following description is made based on this assumption.
The calling request may carry information such as an identifier of the API to be called by the process B and an identifier of hardware that needs to be operated, so that the process a may call the corresponding API in the real HAL accordingly.
The process a may be a process preset on the OS _ a side, and exists when the OS _ a is started. The process a is responsible for the call of the process in the OS _ B to the real HAL corresponding to the OS _ a, so that the OS _ B can multiplex the real HAL on the OS _ a side.
For a specific process of the process a to execute the above steps, reference may be made to the relevant description in the foregoing embodiments, which is not described herein again.
Fig. 4 is a flowchart of another hardware abstraction layer multiplexing method according to an embodiment of the present invention, and like the embodiment shown in fig. 3, the hardware abstraction layer multiplexing method according to this embodiment may be executed by a first process in a first operating system. Assume that the first operating system in this embodiment is OS _ a shown in fig. 1, the second operating system is OS _ B shown in fig. 1, the first process is process a shown in fig. 1, and the second process is process B shown in fig. 1, so that, as shown in fig. 4, the method may include the steps of:
401. and the first process receives a call request sent by a second process in the second operating system through cross-process communication, wherein the call request is triggered by the second process responding to a hardware operating instruction to call a first application program interface in a virtual hardware abstraction layer corresponding to the second operating system.
402. And the first process determines that a second application program interface in the hardware abstraction layer corresponding to the first operating system needs to be called according to the calling request, and checks the state of the hardware corresponding to the hardware abstraction layer if the second application program interface is identified to have the exclusive operation attribute.
403. And if the state of the hardware represents that the hardware is in an idle state, calling a second application program interface in a hardware abstraction layer corresponding to the first operating system by the first process according to the calling request so as to execute the hardware operating instruction.
404. The first process places the state of the hardware in a busy state.
405. If the data volume of the hardware data generated by the hardware executing the hardware operation instruction is smaller than a preset threshold value, the first process sends the hardware data to the second process; and if the data volume of the hardware data is greater than or equal to the preset threshold, the first process stores the hardware data into the shared memory and sends the storage address of the hardware data in the shared memory to the second process.
Because the call request sent by the process B carries the identifier of the first API called by the process B in the virtual HAL, the process a may determine, based on the correspondence between the API configuration in the real HAL and the API configuration in the virtual HAL, the second API corresponding to the first API that the process B needs to call in the real HAL.
In an alternative embodiment, process a may call the corresponding second API in the real HAL immediately after receiving the call request. However, in some practical application scenarios, when the process a needs to call the second API in the real HAL to perform some operation on the hardware corresponding to the real HAL, there may be some APIs that have been called by other processes in the OS _ a before to perform the operation on the hardware. If the hardware can only be operated by one process at the same time, i.e. if the hardware belongs to exclusive hardware, then process a should not be allowed to call the API in the real HAL at this time. For example, if a process is controlling a camera to take a picture, another process cannot use the camera at the same time.
Therefore, in order to avoid simultaneous invocation of the same real HAL by different processes, i.e. to avoid simultaneous slave operation of different processes on the same hardware, the process a also provides an exclusive mechanism, which is simply to say that when a real HAL is currently invoked by a certain process, the process a will set the state of the hardware corresponding to the real HAL to a busy state, otherwise to an idle state, so as to avoid simultaneous invocation of the real HAL by multiple processes. The busy state refers to that the hardware is occupied by a process, and therefore, the busy state also refers to an occupied state, and correspondingly, the idle state may also refer to an unoccupied state.
Therefore, in order to implement the above-mentioned mutual exclusion function, before the process a calls the second API in the real HAL based on the call request of the process B, the process a may first identify whether the second API has the exclusive operation attribute, if the second API is identified to have the exclusive operation attribute, check the state of the hardware corresponding to the real HAL, and if the state of the hardware indicates that the hardware is in the idle state, the process a may call the second API in the real HAL according to the call request of the process B to execute the hardware operation instruction; and if the state of the hardware indicates that the hardware is in a busy state, the process A sends operation failure prompt information to the process A, and at the moment, the operation failure prompt information indicates that the hardware is operated by other processes. On the contrary, if it is recognized that the second API does not have the exclusive operation attribute, it indicates that even if another process is calling the real HAL to operate the hardware, the execution of the second API called by the process a does not affect the normal operation of the other process, and at this time, the process a may also call the second API in the real HAL to execute the hardware operation instruction.
In this embodiment, the exclusive operation attribute of the second API may also be referred to as an exclusive operation attribute, and the meaning of the exclusive operation attribute may be understood as: if the different processes are allowed to simultaneously call the second API to perform some operation on the hardware, the second API does not have the exclusive operation attribute, and conversely, if the different processes are not allowed to simultaneously call the second API to perform some operation on the hardware, the second API has the exclusive operation attribute. For example, if the second API is capable of implementing a camera opening operation, since another process is not allowed to open the camera again in the case that a process has already opened the camera, the second API for implementing the camera opening function has an exclusive operation attribute. For another example, assuming that the second API is used to implement the function of querying the number of cameras included in the terminal device, the second API does not have an exclusive operation attribute since multiple processes can be allowed to query the number of cameras at the same time.
Optionally, it may be identified whether the second API has an exclusive operation attribute according to the configuration of the second API in the real HAL. For example, a field may be set in the configuration of the second API, where different values of the field are used to indicate whether the second API has an exclusive operation attribute, for example, 00 indicates that the second API does not have the exclusive operation attribute, and 01 indicates that the second API has the exclusive operation attribute.
In an optional embodiment, the process a may perform the query of the hardware status immediately after receiving the call request sent by the process B and recognizing that the API corresponding to the call request in the real HAL has the exclusive operation attribute. However, in an alternative embodiment, process A may also view the state of the hardware only upon identifying that a particular API with an exclusive operation attribute needs to be called, to reduce the query operation. Therefore, after receiving the call request sent by the process B, the process a checks the state of the hardware if it is recognized that the second API corresponding to the call request in the real HAL has the exclusive operation attribute, and the second API is used for implementing the opening operation on the hardware. Taking a camera application as an example, generally, in the process of taking a picture through a camera, the process B may need to sequentially call several APIs of starting the camera, starting a preview, taking a picture, and closing the camera. When the process B calls the API for opening the camera in the virtual HAL, the process a may receive a call request corresponding to the API for opening the camera sent by the process B, and then the process a recognizes that the API has an exclusive operation attribute and is used to implement the operation for opening the camera, and then queries the state of the camera, and if the camera is in an idle state at this time, the process a calls the API for opening the camera corresponding to the real HAL to perform the operation for opening the camera, and sets the state of the camera to a busy state, and at this time, optionally, the process a may also record the process for setting the camera to the busy state as the process B. Thereafter, optionally, process a feeds back an opening success indication to process B, so that process B continues to call the API in the virtual HAL that opens the preview. At this time, after receiving the call request corresponding to the API for opening the preview, even if it is recognized that the API for opening the preview in the real HAL has the exclusive operation attribute, the process a may not query the camera status, because the process B has not finished operating the camera. Until the process A receives a call request of the process B to the API for closing the camera, the API for closing the camera is identified to have exclusive operation attribute and is used for realizing the closing operation of the camera, at the moment, the process A sets the state of the camera to be an idle state, and at the moment, the process B finishes the operation of the camera.
Therefore, if the process a recognizes that the second API has the exclusive operation attribute and the second API is used to implement the closing operation on the hardware, the state of the hardware is set to the idle state. In addition, in practical applications, in addition to the situation that the process a needs to call the real HAL, there may be a process started by an application program on the OS _ a side, which is referred to as a situation that the third process needs to call the real HAL. At this time, before invoking the real HAL, the third process needs to query the process a for the state of the hardware corresponding to the real HAL, so as to invoke the real HAL when the hardware is in the idle state. Therefore, the process a may further receive an inquiry request, which is sent by a third process in the OS _ a through cross-process communication, for inquiring the state of the hardware corresponding to the real HAL, and send the state of the hardware to the third process, so that the third process determines whether to invoke the real HAL according to the state.
As described in the foregoing embodiment, in order to avoid the excessively long occupation time of the real HAL, the process a may determine whether to directly feed back the hardware data to the process B or to feed back the storage address of the hardware data in the shared memory to the process B according to the data size of the hardware data generated by the hardware when the hardware operation instruction is executed by calling the second API.
In summary, process a is provided on the OS _ a side with the real HAL to listen for a call request from OS _ B to the real HAL in order to assist in completing the multiplexing of the real HAL by OS _ B; in addition, process a also provides a mutual exclusion mechanism to avoid multiple processes from invoking the real HAL corresponding to the exclusive hardware at the same time.
Fig. 5 is an interaction diagram of a hardware abstraction layer multiplexing method according to an embodiment of the present invention, and referring to fig. 1, in this embodiment, the first operating system is OS _ B, the second operating system is OS _ a, the first process is process B, and the second process is process a. And the API configuration in the virtual HAL is assumed to be the same as the API configuration in the real HAL. As shown in fig. 5, the following steps may be included:
501. and responding to the hardware operation instruction, and calling an application program interface in a virtual hardware abstraction layer corresponding to the first operating system by a first process of the first operating system.
502. And the first process sends the call request of the application program interface to a second process in a second operating system through cross-process communication.
503. And the second process identifies that the application program interface has the exclusive operation attribute and checks the state of the hardware corresponding to the real hardware abstraction layer.
504. And if the hardware is in an idle state, the second process calls the application program interface in the real hardware abstraction layer corresponding to the second operating system according to the call request so as to execute the hardware operating instruction.
505. The second process places the state of the hardware into a busy state.
506. And the second process receives an inquiry request which is sent by a third process in the second operating system through cross-process communication and is used for inquiring the state of the hardware corresponding to the real HAL.
507. The second process sends a query response to the third process indicating that the hardware is in a busy state.
508. The third process gives up calling the real HAL.
509. The second process sends hardware data generated by hardware executing the hardware operation instruction to the first process.
The hardware abstraction layer multiplexing apparatus of one or more embodiments of the present invention will be described in detail below. Those skilled in the art will appreciate that these hardware abstraction layer multiplexing devices can each be constructed using commercially available hardware components configured through the steps taught in this scheme.
Fig. 6 is a schematic structural diagram of a hardware abstraction layer multiplexing device corresponding to the embodiment shown in fig. 2, and as shown in fig. 6, the device includes: a calling module 11, a sending module 12 and a receiving module 13.
And the calling module 11 is configured to call, in response to the hardware operation instruction, a first application program interface in a virtual hardware abstraction layer corresponding to the first operating system.
A sending module 12, configured to send, through cross-process communication, the call request of the application program interface to a second operating system, so that a second process in the second operating system calls, according to the call request, a second application program interface in a hardware abstraction layer corresponding to the second operating system to execute the hardware operation instruction.
The configuration of the first application program interface in the virtual hardware abstraction layer and the configuration of the second application program interface in the hardware abstraction layer have a corresponding relation.
Optionally, the configuration of the first application program interface in the virtual hardware abstraction layer is the same as the configuration of the second application program interface in the hardware abstraction layer.
Optionally, the apparatus further comprises: and a receiving module 13.
And the receiving module 13 is configured to receive a hardware operation result fed back by the second process.
Wherein the hardware operation result comprises:
hardware data generated by hardware executing the hardware operational instructions; or the storage address of the hardware data in the shared memory; or operation failure prompt information; wherein the hardware data and the storage address are sent or not determined by the second process according to the data size of the hardware data; the operation failure prompt message is sent by the second process when the hardware is determined to be busy.
The apparatus shown in fig. 6 can execute the method shown in fig. 2, and reference may be made to the related description of the embodiment shown in fig. 2 for a part not described in detail in this embodiment. The implementation process and technical effect of the technical solution refer to the description in the embodiment shown in fig. 2, and are not described herein again.
Fig. 7 is a schematic diagram illustrating a composition of an operating system corresponding to the embodiment shown in fig. 2, and as shown in fig. 7, the operating system may be OS _ B shown in fig. 1, and the operating system includes: an application framework layer and a virtual hardware abstraction layer.
The application framework layer includes a process, and the process is used to implement the hardware abstraction layer multiplexing method in the embodiment shown in fig. 2. This process may be process B in the embodiment shown in fig. 2.
Referring to the introduction of the foregoing embodiment, the configuration of the application program interface in the virtual hardware abstraction layer has a corresponding relationship with the configuration of the application program interface in the hardware abstraction layer corresponding to another operating system. The implementation of the application program interface in the virtual hardware abstraction layer indicates that a call request to the application program interface in the virtual hardware abstraction layer is transmitted to another operating system through cross-process communication.
Since the implementation of the application program interface in the virtual hardware abstraction layer involves cross-process communication, in an optional embodiment, the cross-process communication may be implemented based on a cross-process communication mechanism provided in a kernel of the operating system, such as Socket, and therefore, optionally, the kernel as shown in fig. 7 may also be included in the operating system.
In one possible design, the structure of the hardware abstraction layer multiplexing apparatus shown in fig. 6 may be implemented as an electronic device, where the electronic device is a user terminal device, such as a smart phone, a tablet computer, a PC, and the like, and as shown in fig. 8, the user terminal device may include: a processor 21 and a memory 22. The memory 22 is configured to store a program that supports the user terminal device to execute the hardware abstraction layer multiplexing method provided in each of the above exemplary embodiments, and the processor 21 is configured to execute the program stored in the memory 22.
The program comprises one or more computer instructions which, when executed by the processor 21, are capable of performing the steps of:
responding to a hardware operation instruction, and calling a first application program interface in a virtual hardware abstraction layer corresponding to the first operating system;
sending a calling request of the application program interface to a second operating system through cross-process communication so that a second process in the second operating system calls a second application program interface in a hardware abstraction layer corresponding to the second operating system to execute the hardware operation instruction according to the calling request;
the configuration of the first application program interface in the virtual hardware abstraction layer and the configuration of the second application program interface in the hardware abstraction layer have a corresponding relation.
Optionally, the processor 21 is further configured to perform all or part of the steps of the method shown in fig. 2.
The structure of the user terminal device may further include a communication interface 23, which is used for the user terminal device to communicate with other devices or a communication network.
In addition, an embodiment of the present invention provides a computer storage medium, configured to store computer software instructions for a user terminal device, where the computer software instructions include a program for executing the hardware abstraction layer multiplexing method in the embodiment of the method shown in fig. 2.
Fig. 9 is a schematic structural diagram of a hardware abstraction layer multiplexing device corresponding to the embodiment shown in fig. 3 or fig. 4, as shown in fig. 9, the device includes: a receiving module 31 and a calling module 32.
The receiving module 31 is configured to receive a call request sent by a second process in a second operating system through cross-process communication, where the call request is triggered by the second process calling a first application program interface in a virtual hardware abstraction layer corresponding to the second operating system in response to a hardware operation instruction.
And the calling module 32 is configured to call a second application program interface in a hardware abstraction layer corresponding to the second operating system according to the call request, so as to execute the hardware operation instruction.
Wherein, the configuration of the first application program interface in the virtual hardware abstraction layer and the configuration of the second application program interface in the hardware abstraction layer have a corresponding relationship.
Optionally, the apparatus further comprises: a query module 33 and a setting module 34.
And the query module 33 is configured to check a state of the hardware corresponding to the hardware abstraction layer if it is identified that the second application program interface has the exclusive operation attribute.
Accordingly, the calling module 32 is specifically configured to: if the query module 33 finds that the state indicates that the hardware is in an idle state, the second application program interface is called according to the call request to execute the hardware operation instruction.
A setting module 34, configured to set the state of the hardware to a busy state under the trigger of the invoking module 32.
Optionally, the query module 33 is specifically configured to: and if the second application program interface is identified to have the exclusive operation attribute and is used for realizing the opening operation of the hardware, checking the state of the hardware.
Optionally, the invoking module 32 is specifically configured to: and if the second application program interface is identified to have the non-exclusive operation attribute, calling the second application program interface according to the calling request so as to execute the hardware operation instruction.
Optionally, the apparatus further comprises: a sending module 35.
A sending module 35, configured to feed back a hardware operation result corresponding to the hardware operation instruction to the first process.
Optionally, the sending module 35 is specifically configured to:
if the data volume of hardware data generated by the hardware executing the hardware operation instruction is smaller than a preset threshold value, sending the hardware data to the first process as the hardware operation result;
if the data volume of the hardware data is larger than or equal to the preset threshold, storing the hardware data into a shared memory, and sending the storage address of the hardware data in the shared memory to the first process.
Optionally, the sending module 35 is further configured to:
and if the state indicates that the hardware is in a busy state, sending operation failure prompt information to the first process.
Optionally, the receiving module 31 is further configured to: and receiving a query request sent by a third process in the second operating system through cross-process communication, wherein the query request is used for querying the state of the hardware.
The sending module 35 is further configured to: and sending the state of the hardware to the third process so that the third process determines whether the hardware abstraction layer can be called according to the state.
The apparatus shown in fig. 9 can execute the method of the embodiment shown in fig. 3 or fig. 4, and the related description of the embodiment shown in fig. 3 or fig. 4 can be referred to for the part not described in detail in this embodiment. The implementation process and technical effect of the technical solution refer to the description in the embodiment shown in fig. 3 or fig. 4, and are not described herein again.
Fig. 10 is a schematic diagram of an operating system corresponding to the embodiment shown in fig. 3 or fig. 4, as shown in fig. 10, the operating system may be OS _ a shown in fig. 1, and the operating system includes: an application framework layer and a cross-process communication interface.
Wherein, the application framework layer includes a process, and the process is used to implement the hardware abstraction layer multiplexing method in the embodiment shown in fig. 3 or fig. 4. This process may be process a in the embodiment shown in fig. 2.
Referring to the descriptions in the foregoing embodiments, optionally, a hardware abstraction layer may also be included in the operating system. The configuration of the application program interface in the hardware abstraction layer has a corresponding relationship with the configuration of the application program interface in the virtual hardware abstraction layer corresponding to another operating system, i.e., the operating system shown in fig. 7.
The cross-process communication interface is used for the process to receive a call request sent by another operating system through the cross-process communication interface.
In an optional embodiment, the cross-process communication interface may be implemented based on a cross-process communication mechanism provided in a kernel of an operating system, such as Socket, and therefore, optionally, the kernel shown in fig. 10 may also be included in the operating system.
In one possible design, the structure of the hardware abstraction layer multiplexing apparatus shown in fig. 9 may be implemented as an electronic device, where the electronic device is a user terminal device, and as shown in fig. 11, the user terminal device may include: a processor 41 and a memory 42. The memory 42 is configured to store a program that supports the user terminal device to execute the hardware abstraction layer multiplexing method provided in each of the above exemplary embodiments, and the processor 41 is configured to execute the program stored in the memory 42.
The program comprises one or more computer instructions which, when executed by the processor 41, are capable of performing the steps of:
receiving a calling request sent by a second process in a second operating system through cross-process communication, wherein the calling request is triggered by the second process responding to a hardware operating instruction and calling a first application program interface in a virtual hardware abstraction layer corresponding to the second operating system;
calling a second application program interface in a hardware abstraction layer corresponding to the second operating system according to the calling request so as to execute the hardware operating instruction;
the configuration of the first application program interface in the virtual hardware abstraction layer and the configuration of the second application program interface in the hardware abstraction layer have a corresponding relation.
Optionally, the processor 41 is further configured to perform all or part of the steps of the method shown in fig. 3 or fig. 4.
The structure of the user terminal device may further include a communication interface 43, which is used for the user terminal device to communicate with other devices or a communication network.
In addition, an embodiment of the present invention provides a computer storage medium for storing computer software instructions for a user terminal device, which includes a program for executing the hardware abstraction layer multiplexing method in the method embodiment shown in fig. 3 or fig. 4.
The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by adding a necessary general hardware platform, and of course, can also be implemented by a combination of hardware and software. With this understanding in mind, the above-described aspects and portions of the present technology which contribute substantially or in part to the prior art may be embodied in the form of a computer program product, which may be embodied on one or more computer-usable storage media having computer-usable program code embodied therein, including without limitation disk storage, CD-ROM, optical storage, and the like.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable hardware abstraction layer multiplexing device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable hardware abstraction layer multiplexing device, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable hardware abstraction layer multiplexing device to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable hardware abstraction layer multiplexing device to cause a series of operational steps to be performed on the computer or other programmable device to produce a computer implemented process such that the instructions which execute on the computer or other programmable device provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
Finally, it should be noted that: the above examples are only intended to illustrate the technical solution of the present invention, but not to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions of the embodiments of the present invention.