Data transmission method among multiple systems in electronic equipment and electronic equipment

Abstract

The invention provides a data transmission method among multiple systems in electronic equipment and the electronic equipment, at least two operating systems are installed on the electronic equipment, the at least two operating systems are both operating systems based on a linux kernel, and the method comprises the steps that in the data reading and writing process of the at least two operating systems in a data storage area, the at least two operating systems are connected with the linux kernel, and the at least two operating systems are connected with the linux kernel; and the synchronization of data reading and writing is carried out through the cortex. Through the method, data exchange among a plurality of operating systems of the electronic equipment can be realized.

Description

Technical Field

[0001] The present application relates to the technical field of electronic devices, and more particularly, to a data transmission method between multiple systems in an electronic device and the electronic device. Background Art

[0002] With the increasing popularity of smartphones, their capabilities have been continuously developed, offering a growing number of features. However, the phone's structure was originally designed for low-power, low-computing scenarios. Consequently, as phone hardware capabilities gradually improved and became capable of supporting a richer range of features, the low-power nature of the phone's operating system actually limited its capabilities. Therefore, it's possible to launch and run a separate operating system on a phone for code development, gaming, Python model training, and more. However, these two operating systems are isolated by default and cannot access each other.

[0003] How to enable the operating systems on mobile phones to access each other and bring more extended functions to the mobile phones is an urgent problem to be solved. Summary of the Invention

[0004] The present application provides a method for transmitting data between multiple systems in an electronic device and an electronic device, which can realize mutual access to resources between multiple operating systems of the electronic device.

[0005] In a first aspect, a method for data transmission between multiple systems in an electronic device is provided, wherein at least two operating systems are installed on the electronic device, and the method comprises: during the process of the at least two operating systems reading and writing data in a data storage area, synchronizing the data reading and writing through a fast user space mutex lock futex; wherein the at least two operating systems are both operating systems based on the Linux kernel.

[0006] In certain implementations, synchronizing the data reading and writing by using futex includes: preventing multiple operating systems in the two operating systems from reading and writing data in the same area of ​​the data storage area at the same time by using the futex.

[0007] In some implementations, the method of avoiding multiple operating systems of the two operating systems from reading and writing data in the same area of ​​the data storage area at the same time through the futex includes: before the first operating system of the two operating systems writes data to the first area of ​​the data storage area, the method further includes: determining that the read lock state of the first area is no data to be read, and determining that the write lock state of the first area is no data being written; setting the write lock state of the first area to data being written; after the first operating system of the two operating systems writes data to the first area of ​​the data storage area, the method further includes: setting the write lock state of the first area to no data being written; and setting the read lock state of the first area to data being read.

[0008] In some implementations, the method of avoiding multiple operating systems of the two operating systems from reading and writing data in the same area of ​​the data storage area at the same time through the futex also includes: before the first operating system of the two operating systems reads data from the first area of ​​the data storage area, the method also includes: determining that the write lock state of the first area is that no data is being written, and the read lock state of the first area is that there is data to be read; after the first operating system of the two operating systems reads data from the first area of ​​the data storage area, the method also includes: setting the read lock state of the first area to that there is no data to be read.

[0009] In some implementations, the data storage area includes at least one of the following memory areas: a memory-based file system tmpfs, a secure digital sd card, or a graphics processing unit gpu video memory.

[0010] In certain implementations, the at least two operating systems include a first operating system and a second operating system.

[0011] In certain implementations, the method further includes: mounting the data storage area in both the first operating system and the second operating system; and performing data transmission between the first operating system and the second operating system through the data storage area.

[0012] In some implementations, the method further includes exchanging audio data between the first operating system and the second operating system through a pulse audio system (pulseaudio).

[0013] In certain implementations, the method further includes: sending video data captured by a USB camera installed on the electronic device to the second operating system through a universal video library Libuvc.

[0014] In some implementations, the method further includes: sending the video data captured by the built-in photography module on the electronic device to the second operating system through the camera2 native development toolkit library libcamera2ndk.

[0015] In some implementations, the method further includes: creating a virtual desktop; sending desktop graphics data of the second operating system to the virtual desktop via the X11 protocol; and reading graphical interface data in the virtual desktop via a termux-x11 application in the first operating system.

[0016] In some implementations, the method further includes: creating a virtual desktop; sending desktop graphic data of the second operating system to the virtual desktop through a virtual network console (VNC) service; and reading graphical interface data in the virtual desktop through a VNC application in the first operating system.

[0017] In a second aspect, an electronic device is provided, on which at least two operating systems are installed, and the synchronization of data reading and writing in a data storage area by the at least two operating systems is achieved through a fast user space mutex futex, wherein the at least two operating systems are both operating systems based on the Linux kernel.

[0018] In a third aspect, an electronic device is provided, which includes modules / units for executing the method of the first aspect or any possible design of the first aspect; these modules / units can be implemented by hardware, or corresponding software implementations can be executed by hardware.

[0019] In a fourth aspect, an electronic device is provided, comprising one or more processors; one or more memories; the one or more memories storing one or more computer programs, the one or more computer programs comprising instructions, which, when executed by the one or more processors, enable the above-mentioned first aspect or any possible implementation of the above-mentioned first aspect to be executed.

[0020] In a fifth aspect, a computer-readable storage medium is provided, on which a computer program or instruction is stored. When the computer program or instruction is run on an electronic device, the electronic device executes the method provided in the first aspect or any possible implementation of the first aspect.

[0021] In a sixth aspect, a computer program product is provided, comprising a computer program or instructions for executing the method of the first aspect or any possible implementation of the first aspect. In other words, when the computer program product is executed on a computer, the computer executes the method of the first aspect or any possible implementation of the first aspect.

[0022] In the seventh aspect, a chip is provided, which includes a processor and a communication interface. The processor reads instructions on the memory through the communication interface and executes the method provided in the first aspect or any possible implementation of the first aspect.

[0023] Optionally, as an implementation, the chip also includes a memory, in which a computer program or instructions are stored, and the processor is used to execute the computer program or instructions on the memory. When the computer program or instructions are executed, the processor is used to execute the method provided in the above-mentioned first aspect or any possible implementation of the above-mentioned first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 This is a schematic diagram of a data transmission method provided by this application.

[0025] Figure 2 This is a schematic diagram of a data transmission method provided by this application.

[0026] Figure 3 This is a schematic diagram of a data transmission method provided by this application.

[0027] Figure 4 This is a schematic diagram of a data transmission method provided by this application.

[0028] Figure 5 This is a schematic diagram of a data transmission method provided by this application.

[0029] Figure 6 This is a schematic diagram of a data transmission method provided by this application. DETAILED DESCRIPTION

[0030] The technical solution in this application will be described below with reference to the accompanying drawings.

[0031] The embodiments of the present application will present various aspects, embodiments, or features around a system including multiple devices, components, modules, etc. It should be understood and appreciated that each system may include additional devices, components, modules, etc., and / or may not include all of the devices, components, modules, etc. discussed in conjunction with the figures. Furthermore, combinations of these solutions may also be used.

[0032] Additionally, in the embodiments of this application, words such as "exemplary" and "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" in the embodiments of this application should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of the word "exemplary" is intended to present concepts in a concrete manner.

[0033] The business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field will know that with the evolution of technology and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0034] References to "one embodiment" or "some embodiments" in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in one or more embodiments of the present application. Thus, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in yet other embodiments" appearing in various places in this specification do not necessarily refer to the same embodiment, but rather mean "one or more but not all embodiments," unless otherwise specifically emphasized. The terms "including," "comprising," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0035] In the embodiments of the present application, "at least one" refers to one or more, and "more" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent: including the existence of A alone, the existence of A and B at the same time, and the existence of B alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, c can be single or multiple.

[0036] While smartphone hardware capabilities have improved, operating system designs still prioritize low power consumption, failing to fully exploit the hardware's potential. While existing solutions (such as Termux / LXC) can run other operating systems on devices, resource isolation between systems prevents desktop-level functionality (such as development, gaming, and model training).

[0037] Based on the above problems, the present application proposes a data transmission method between multiple systems in an electronic device, which is used to enable resources between multiple operating systems of the electronic device to be accessible to each other.

[0038] Below, taking multiple operating systems of an electronic device including the Android system (i.e., an example of the first operating system) and the Ubuntu system (i.e., an example of the second operating system) as an example, the data transmission method provided by this application is explained through data exchange between the Android system and the Ubuntu system.

[0039] In an embodiment of the present application, data storage between the Android system and the Ubuntu system can be performed through a shared data storage area.

[0040] In one implementation, the data storage area includes at least one of the following storage areas: a memory-based file system tmpfs, a secure digital sd card, or a graphics processing unit gpu video memory.

[0041] The data storage area can be mounted in Android and Ubuntu systems.

[0042] For example, if the electronic device is an Android device, the following code can be run in the electronic device to mount the tmpfs and sd card in the ubuntu system.

[0043] #! / bin / sh

[0044] UBUNTUPATH=" / data / local / tmp / chrootubuntu"

[0045] busybox mount-o remount,dev,suid / data

[0046] busybox mount--bind / dev$UBUNTUPATH / dev

[0047] busybox mount--bind / sys$UBUNTUPATH / sys

[0048] busybox mount--bind / proc$UBUNTUPATH / proc

[0049] busybox mount -t devpts devpts$UBUNTUPATH / dev / pts

[0050] busybox mount-t tmpfs-o size=256M tmpfs$UBUNTUPATH / dev / shm

[0051] busybox mount--bind / sdcard$UBUNTUPATH / sdcard

[0052] busybox chroot$UBUNTUPATH / bin / su-root

[0053] The above code ensures that the basic file system composition of the Ubuntu system is relatively complete.

[0054] Among them, "UBUNTUPATH=" / data / local / tmp / chrootubuntu"" is used to install the Ubuntu system in / data / local / tmp. This directory has execution permissions by default (that is, the permission to read and write Ubuntu system data and execute Ubuntu system programs).

[0055] The commands "busybox mount --bind / dev $UBUNTUPATH / dev," "busybox mount --bind / sys $UBUNTUPATH / sys," and "busybox mount --bind / proc $UBUNTUPATH / proc" are used to bind the Android system's / dev (device nodes), / sys (hardware and driver information), and / proc (kernel and process information) to the corresponding directories on Ubuntu, ensuring consistency between the two. Busybox is an open-source, lightweight collection of software tools designed to provide a streamlined Unix toolkit suitable for embedded systems and resource-constrained environments.

[0056] The command "busybox mount -t tmpfs -o size=256M tmpfs $UBUNTUPATH / dev / shm" mounts the tmpfs buffer file system in the dev / shm directory on the Ubuntu system. tmpfs is a special temporary file system used primarily on Linux and Unix systems. It stores files in RAM or the swap partition rather than on the hard disk, resulting in very fast access speeds, but data is not retained across system reboots. The maximum capacity of tmpfs is 256MB.

[0057] Among them, "busybox mount --bind / sdcard $UBUNTUPATH / sdcard" is used to mount the SD card in the Ubuntu system. It should be understood that the SD card can be used as a Linux user space file system (filesystem in userspace, FUSE), so it can also be mounted in the Ubuntu system, so that the Ubuntu system can directly access the files and data in the SD card.

[0058] Optionally, when Android and Ubuntu systems need to frequently interact with the GPU or require faster data transfer, they can consider using GPU shared memory technology for data exchange. This application provides a method for implementing GPU-based data exchange between Android and Ubuntu systems.

[0059] Common GPUs such as the Compute Unified Device Architecture (CUDA) and Mali all have video memory management. Assuming that Android and Ubuntu use the same version of the Mali driver, the video memory management interfaces and data structures of Android and Ubuntu are compatible. Therefore, by sharing video memory, high-speed image-based interaction can be achieved.

[0060] For example, Figure 1 As shown in the figure, with the help of the GPU driver, a shared embedded-system graphics library (EGL) with a shared context is created in the Ubuntu system. Graphics are then drawn based on the OpenGL for embedded systems (OpenGLES) graphics library (libOpenGLES). Then, in the Android system, the corresponding video memory buffer is found based on the EGL context and mapped to an Android native window (ANativeWindow) in the Android Native Development Kit (NDK). The Android system can then draw the graphics using the Android graphics display system (e.g., the SurfaceFlinger interface rendering process). Furthermore, the Android system can transmit feedback operation information to the Ubuntu system via the aforementioned tmpfs and SD card.

[0061] ANativeWindow is a low-level native interface for directly manipulating a window's graphics buffer in C / C++, supporting high-performance graphics rendering or image processing. SurfaceFlinger is a core service in the Android system responsible for synthesizing all application window surfaces and sending them to the display device.

[0062] Through the above solution, the isolation between the Android system and the Ubuntu system can be bypassed, and data exchange between the Android system and the Ubuntu system can be carried out through the above data storage area.

[0063] It should be understood that data exchange between the Android system and the Ubuntu system can be completed through the above-mentioned data storage area. In addition, in some possible implementations, for some specific types of data, transmission can be completed through other methods.

[0064] For example, for the exchange of audio data, such as Figure 2 As shown, audio data can be exchanged between the Android system and the Ubuntu system through the pulse audio system.

[0065] Specifically, the client-server (CS) architecture of Linux audio software can be utilized. In the Ubuntu system, the pulse server is used to bypass the Android system and connect to the underlying Linux audio driver library (such as libsles). This allows the microphones and speakers of the Android and Ubuntu systems to be mutually accessible.

[0066] For example, for audio data transmission from Ubuntu system to Android system, first, the audio source (audio speaker) of the Ubuntu system generates audio data, which is sent to the PulseAudio service. The Android system obtains the audio data through the TCP protocol and calls the underlying audio driver library such as the Embedded Audio Interface Library (LibSLES), and finally outputs the sound from the speaker or earphones of the electronic device.

[0067] For example, for audio data transmission from Android system to Ubuntu system, first, the microphone collects audio data, then processes the audio data through the libsles driver, and then receives the audio data through the pulseaudio service. Finally, the Ubuntu system application (such as recording software) reads the audio data from the pulseaudio service.

[0068] Optionally, before exchanging audio data between the Android system and the Ubuntu system through pulseaudio, you can run the following auxiliary code in the electronic device:

[0069] Pulseaudio--start--load="module-native-protocol-tcp auth-ip-acl=127.0.0.1auth-anonymous=1"--exit-idle-time=-1

[0070] pacmd load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1auth-anonymous=1

[0071] pacmd load-module module-sles-source

[0072] virgl_test_server_android&

[0073] In the above code, pulseaudio is an audio auxiliary service used to build an architecture that bridges the audio playback in the Ubuntu system to the playback in the underlying Linux system.

[0074] The command "pulseaudio --start --load="module-native-protocol-tcp auth-ip-acl=127.0.0.1auth-anonymous=1" --exit-idle-time=-1" starts the Pulseaudio audio service and loads the TCP protocol module. This provides audio services for the Ubuntu system and bridges the audio stream to the Linux underlying audio driver via TCP.

[0075] Among them, pacmd is the package manager used to import a specific software package. "module-native-protocol-tcp" is the module loaded by pulseaudio to enable local TCP monitoring. The second line of code is used to double-check the loading of the "module-native-protocol-tcp" module in this environment to improve robustness. "module-sles-source" is the playback source setting, used to import the OpenSSL / libSSL-based playback source in Linux into the pulse service.

[0076] Among them, "virgl_test_server_android&" is used to start GPU acceleration. This code is not related to the exchange of audio data and can run simultaneously. It is used for graphical interface launcher software such as xfce4 / xubuntu-desktop.

[0077] For example, for the exchange of USB camera data, Figure 3 As shown, the video data collected by the USB camera installed on the electronic device can be sent to the Ubuntu system through the universal video class library (libuvc).

[0078] Libuvc is an open-source, cross-platform library for directly accessing USB Video Class (UVC)-compliant camera devices. It bypasses operating system interface restrictions and allows direct access to USB camera devices via the USB protocol.

[0079] For video capture devices such as USB cameras, USB devices are generally not managed by the Android system, so they can be accessed using libuvc. Therefore, for the fusion system, the Ubuntu system can seamlessly access the camera video source using libuvc. If you want to play the time and frequency data of the Ubuntu system on the Android system, for example, when using Simple Direct Media Layer 2 (SDL2) for playback, you can send it back to the Android system through the tmpfs shared memory bridge, and the Android system can read the application screen running on the Ubuntu system.

[0080] For example, for the exchange of built-in photographic data, such as Figure 4 As shown, the video data collected by the built-in photography module on the electronic device can be sent to the Ubuntu system through the Camera2 native development toolkit library (libcamera2ndk).

[0081] libcamera2ndk is a native library provided by the Android NDK that allows developers to directly access Android's Camera2 API from C / C++ code. It is the official Android interface for native access to camera hardware, replacing older libcamera or third-party libraries such as libuvc. It is designed for scenarios requiring high performance or depth control of the camera.

[0082] Android's built-in camera is strictly controlled by the system. Ordinary applications must access it through Android APIs (such as Camera2). Directly using libuvc cannot bypass Android's permission isolation. Therefore, by leveraging libcamera2 in the Android NDK and, provided that system permissions are configured effectively (usually required when flashing the firmware), registering the running code with the system's binder inter-process communication library (libbinder_ndk) allows access to the built-in camera.

[0083] For example, the Android.mk example is as follows:

[0084] LOCAL_SRC_FILES:=camera.cpp

[0085] LOCAL_C_INCLUDE:=frameworks / av / camera / ndk / include / \

[0086] libnativehelper / include_jni /

[0087] LOCAL_SHARED_LIBRARIES:=libcamera2ndk\

[0088] libmediandk\

[0089] libnativewindow\

[0090] liblog\

[0091] libutils\

[0092] libbinder_ndk

[0093] The first line of code specifies the C++ source code file containing the camera operation logic; the second line indicates the path to the camera2 NDK header file; and the third line provides JNI interaction support. Furthermore, the fourth to last lines of code link to the dynamic library, providing low-level hardware access and system service communication capabilities.

[0094] For example, if you want to access the desktop of the Ubuntu system through the Android system, you can do so in the following two ways.

[0095] In the first implementation, Figure 5As shown, you can create a virtual desktop in the Ubuntu system; send the desktop graphics data of the Ubuntu system to the virtual desktop through the X11 protocol; and read the graphical interface data in the virtual desktop through the termux-x11 application in the Android system.

[0096] Specifically, for the desktop graphical interface, since it is locally containerized and isolated, the Android system's desktop screen pixel stream, that is, the surfaceflinger renderer side, can be transmitted in a high-speed cache without encoding at a limited bit rate (for example, less than 256M). Conversely, Ubuntu system desktop graphical applications such as xfce4 can also output their pixel streams to the virtual X11 buffer :0, where :0 is an abbreviation for 127.0.0.1:0, indicating the local virtual display device :0 (DISPLAY:0) with the X11 service enabled. Then, an Android application such as termux-x11 can continuously read the X11 service (X11 server) buffer bitmap to obtain the Ubuntu graphical interface.

[0097] In the second implementation, Figure 6 As shown, a virtual desktop can be created in the Ubuntu system; the desktop graphic data of the Ubuntu system is sent to the virtual desktop through the virtual network console (VNC) service; and the graphical interface data in the virtual desktop is read through the VNC application in the Android system.

[0098] Specifically, if you replace the graphical interface in the Ubuntu system and switch to remote access mode, you will get a remote desktop, which can be achieved through the following script:

[0099] export DISPLAY=:0PULSE_SERVER=tcp:127.0.0.1:4713

[0100] Xvfb$DISPLAY-screen 0 1920x1080x16&startxfce4&

[0101] x11vnc-display$DISPLAY-nopw-forever-loop-noxdamage-repeat-rfbport5900-shared-noshm

[0102] Among them, you can use the X virtual frame buffer (xvfb) to open a local memory virtual buffer (for example, a 2KB, 16-bit bitmap) and then register a monitor in the memory through x11vnc. When a VNC client (such as a VNC application, including termux-x11, etc.) accesses it, the buffer image is encoded using the remote frame buffer (RFB) protocol.

[0103] Through the above solution, data exchange between Android system and Ubuntu system can be realized.

[0104] It should be understood that the Android system and the Ubuntu system may read or write to the same part of the data storage area at the same time. Therefore, in order to avoid resource conflicts caused by this process, it is necessary to determine the synchronization mechanism for the Android system and the Ubuntu system to read and write data in the data storage area.

[0105] Regarding the resource preemption problem, since Android and Ubuntu systems share the Linux kernel, the Linux kernel mechanism can be used to implement a data reading and writing synchronization mechanism, thereby achieving the most functions with the smallest data storage area.

[0106] For the fusion system of Android and Ubuntu, the fast userspace mutexes (futex) mechanism can be used to achieve seamless interaction between the Android and Ubuntu systems, reduce performance overhead, and increase the speed of data exchange.

[0107] Specifically, synchronizing the reading and writing of data in the data storage area by at least two operating systems of the electronic device through futex includes: preventing multiple operating systems in the two operating systems from reading and writing data in the same area of ​​the data storage area at the same time through futex.

[0108] Exemplarily, the binary bits corresponding to the memory structure of the data storage area are as follows:

[0109]

[0110] Among them, it includes a 4-bit read (WRITING) lock bit, which is of int type; a 4-bit write (TOBREAD) lock bit, which is of int type; a 4-bit frame number (FRMEIDX), which is of uint type and is used to indicate the read and write order of different operating systems; a 4-bit payload length (DATALEN), which is of uint type and is used to indicate the data length; and a data bit (DATAS), which is used to carry data and serves as a high-speed swap area in the memory.

[0111] For example, before the Android system or the Ubuntu system writes data to the first area in the data storage area, the following steps may be performed:

[0112] 1) Determine that the read lock status of the first region is no data to be read, that is, determine that the value of the read lock bit is 0.

[0113] Specifically, you can monitor the read lock through the following code:

[0114] libc::syscall(SYS_futex,tbr_flag,FUTEX_WAIT,0,×pec); / / Monitor read lock

[0115] 2) Setting the write lock state of the first region to data being written, that is, setting the value of the write lock bit to 1;

[0116] After writing data to the first area in the data storage area on the Android system or the Ubuntu system, you can perform the following steps:

[0117] 3) The write lock state of the first region is set to no data being written, that is, the value of the write lock bit is set to 0.

[0118] Specifically, you can release the write lock through the following code:

[0119] libc::syscall(SYS_futex,write_flag,FUTEX_WAKE,readers); / / Release write lock

[0120] For example, before the Android system or the Ubuntu system reads data from the first area in the data storage area, the following steps may be performed:

[0121] 1) determining that the write lock state of the first region is set to no data being written, that is, determining that the value of the write lock bit is set to 0;

[0122] Specifically, you can monitor the write lock through the following code:

[0123] let code = libc::syscall(SYS_futex,write_flag,FUTEX_WAIT,0,×pec); / / Monitor write lock

[0124] After the Android system or the Ubuntu system reads data from the first area in the data storage area, the following steps can be performed:

[0125] 2) The read lock state of the first region is set to no data to be read, that is, the value of the read lock bit is set to 0, or the value of the read lock bit is reduced by 1.

[0126] Specifically, you can release the read lock through the following code:

[0127] libc::syscall(SYS_futex,tbr_flag,FUTEX_WAKE,1); / / Release read lock

[0128] Based on the above method, the present application also provides an electronic device on which multiple operating systems (such as Android system and Ubuntu system) are installed, and data can be transmitted between the multiple operating systems using the above data transmission method.

[0129] The present application provides a computer program product that, when executed on an electronic device, enables the electronic device to execute the technical solution in the above embodiment. The implementation principle and technical effects are similar to those of the above method-related embodiments and will not be described in detail here.

[0130] The embodiment of the present application provides a readable storage medium, which contains instructions. When the instructions are executed on an electronic device, the electronic device executes the technical solution of the above embodiment. The implementation principle and technical effect are similar and will not be repeated here.

[0131] The present application provides a chip for executing instructions. When the chip is running, the technical solution of the above embodiment is executed. The implementation principle and technical effect are similar and will not be described here.

[0132] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0133] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0134] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0135] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0136] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0137] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0138] The above are only specific embodiments of the present application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for transmitting data between multiple systems in an electronic device, characterized in that: At least two operating systems are installed on the electronic device, and the method includes: During the process of the at least two operating systems reading and writing data in the data storage area, synchronizing the data reading and writing through a fast user space mutex; Wherein, the at least two operating systems are both operating systems based on the Linux kernel.

2. The method according to claim 1, characterized in that The data reading and writing are synchronized through futex, including: The futex is used to prevent multiple operating systems in the two operating systems from reading and writing data in the same area in the data storage area at the same time.

3. The method according to claim 2, characterized in that The method of preventing multiple operating systems in the two operating systems from reading and writing data in the same area of ​​the data storage area at the same time by using the futex includes: Before the first operating system of the two operating systems writes data to the first area in the data storage area, the method further includes: Determining that the read lock state of the first region is no data to be read; Setting the write lock state of the first region to writing data; After the first operating system of the two operating systems writes data to the first area in the data storage area, the method further includes: The write lock state of the first region is set to no data being written.

4. The method according to claim 2 or 3, characterized in that The method of preventing multiple operating systems in the two operating systems from reading and writing data in the same area of ​​the data storage area at the same time by using the futex further includes: Before the first operating system of the two operating systems reads data from the first area in the data storage area, the method further includes: Determining that the write lock state of the first region is that no data is being written; After the first operating system of the two operating systems reads data from the first area in the data storage area, the method further includes: The read lock state of the first region is set to no data to be read, or the value of the read lock bit is reduced by 1.

5. The method according to any one of claims 1 to 4, characterized in that The data storage area includes at least one of the following storage areas: a memory-based file system tmpfs, a secure digital sd card, or a graphics processing unit gpu video memory.

6. The method according to any one of claims 1 to 5, characterized in that The at least two operating systems include a first operating system and a second operating system; The method further comprises: Mounting the data storage area in both the first operating system and the second operating system; Data is stored between the first operating system and the second operating system through the data storage area.

7. The method according to claim 6, characterized in that The method further comprises: The audio data is exchanged between the first operating system and the second operating system via the pulse audio system pulseaudio.

8. The method according to claim 6 or 7, characterized in that The method further comprises: The video data collected by the USB camera installed on the electronic device is sent to the second operating system through the universal video library libuvc.

9. The method according to any one of claims 6 to 8, characterized in that The method further comprises: The video data collected by the built-in photography module on the electronic device is sent to the second operating system through the Camera2 native development toolkit library libcamera2ndk.

10. The method according to any one of claims 6 to 9, characterized in that The method further comprises: Create virtual desktops; Sending the desktop graphics data of the second operating system to the virtual desktop via the X11 protocol; The graphical interface data in the virtual desktop is read through the termux-x11 application in the first operating system.

11. The method according to any one of claims 6 to 10, characterized in that The method further comprises: Create virtual desktops; Sending the desktop graphic data of the second operating system to the virtual desktop through the virtual network console VNC service; The graphical interface data in the virtual desktop is read through a VNC application in the first operating system.

12. An electronic device, characterized in that: At least two operating systems are installed on the electronic device, and synchronization of data reading and writing in the data storage area by the at least two operating systems is achieved through a fast user space mutex futex, wherein the at least two operating systems are both operating systems based on the Linux kernel.

13. An electronic device, characterized in that: The electronic device comprises a processor configured to execute a computer program or instruction so as to enable the electronic device to perform the method according to any one of claims 1 to 11.

Images