Operating system operation method and device, electronic device and storage medium

Abstract

The present application is about an operating system operation method and device, electronic device, and storage medium. The method includes: in response to the initial startup instruction for the first operating system, the second operating system loads system resources and system classes to start the first process; the first process generates the second process in response to the generation request of the second process; in response to the second process, the operating environment of the first operating system is generated on the second operating system, and the ability to access peripherals is provided to the first operating system; the second process derives a second child process; in response to the second child process, the file system of the first operating system is called to start the first operating system. The operation of the first operating system of the present application on the second operating system is relatively convenient, and the first operating system can freely access peripheral devices.

Description

Technical Field

[0001] Embodiments of the present application relate to operating system startup technology, and specifically to an operating system running method and device, an electronic device, and a readable non-temporary storage medium. Background Art

[0002] Currently, when running Linux on Android, Android only provides Linux command line support. Linux on Android does not support hardware peripherals such as graphics, sound, codec, and Camera.

[0003] Application Contents

[0004] In view of this, the embodiments of the present application provide a method and device for building and compiling an operating system, an electronic device, and a storage medium to at least solve the above technical problems existing in the prior art.

[0005] According to a first aspect of an embodiment of the present application, there is provided a method for operating an operating system, comprising:

[0006] In response to the initial startup instruction for the first operating system, the second operating system loads system resources and system classes to start the first process;

[0007] The first process generates the second process in response to the generation request of the second process;

[0008] In response to the second process, generating an operating environment of the first operating system on the second operating system, and providing the first operating system with a capability of accessing peripherals;

[0009] The second process derives a second child process; in response to the second child process, the file system of the first operating system is called to start the first operating system.

[0010] In one embodiment, calling the file system of the first operating system and starting the first operating system includes:

[0011] Obtain permission to use the chroot instruction for changing the root directory of the second operating system, call and execute the chroot instruction, switch from the second operating system to the file system of the first operating system, and start the first operating system.

[0012] In one embodiment, calling the file system of the first operating system and starting the first operating system includes:

[0013] The user space root Proot instruction of the second operating system is called and executed, the second operating system is switched to the file system of the first operating system, and the first operating system is started.

[0014] In one embodiment, calling the file system of the first operating system to start the first operating system includes:

[0015] A third process is started to read the environment configuration information required to modify the root directory; a shared file is created through the third process, and the environment configuration information is written into the shared file; a third child process is derived through the third process, and environment variables are set in the third child process; a first function is called through the third child process, and a file path parameter passed in by the function call is replaced by the path of the second operating system with the path of the first operating system, and a file path parameter returned by the function call is replaced by the path of the second operating system with the path of the first operating system.

[0016] In one embodiment, replacing the file path parameter passed in by the function call from the path of the second operating system to the path of the first operating system, and replacing the file path parameter returned by the function call from the path of the second operating system to the path of the first operating system, includes:

[0017] The dynamic library is loaded through a linker, so that the dynamic library calls a fourth function to obtain the environment configuration information through the environment variable, and saves the functions related to the file path, wherein the functions related to the file path include: a fifth function whose input parameter includes the file path and a sixth function whose return result includes the file path;

[0018] When the third child process needs to call the fifth function, the seventh function in the dynamic library corresponding to the fifth function is called to replace the file path parameter passed in by the function call from the path of the second operating system to the path of the first operating system;

[0019] When the third subprocess needs to call the sixth function, it calls the eighth function in the dynamic library corresponding to the sixth function to replace the file path parameter of the function call return result from the path of the second operating system to the path of the first operating system.

[0020] In one embodiment, after the first operating system is initially started, the method further includes:

[0021] In response to a first startup instruction for the first operating system, after initializing the device driver and data structure of the first operating system, the user-level program process is started, the system service and software framework-related services of the first operating system are started, and the first operating system is started.

[0022] In one embodiment, providing the first operating system with a capability of accessing a peripheral device includes:

[0023] The second process provides a corresponding virtual device for the first operating system, reads peripheral device information corresponding to the virtual device according to an application program interface (API) of the second operating system, and configures the virtual device based on the peripheral device information;

[0024] When determining that the virtual device receives the access request sent by the first operating system, send the access request to the second process;

[0025] The second process calls the corresponding peripheral device through the corresponding API of the second operating system based on the access request and according to the identification information of the virtual device in the access request.

[0026] In one embodiment, providing the first operating system with a capability of accessing a peripheral device includes:

[0027] After receiving the access request for the graphics library, the first operating system sends the access request to the second process;

[0028] The second process obtains the application binary interface ABI for calling the graphics function in the access request, converts the ABI into a Java API of the second operating system through a Java native interface, calls the peripheral device through the Java API, responds to the first operating system, and implements access to the peripheral device.

[0029] According to a second aspect of an embodiment of the present application, there is provided an operating system running device, including:

[0030] A first startup unit, configured to respond to an initial startup instruction for the first operating system, causing the second operating system to load system resources and system classes to start the first process;

[0031] A first generating unit, configured to enable the first process to generate a second process in response to a request for generating a second process;

[0032] a second generating unit, configured to generate, in response to the second process, an operating environment of the first operating system on the second operating system, and provide the first operating system with a capability of accessing peripherals;

[0033] A deriving unit, used for triggering the second process to derive a second child process;

[0034] The second starting unit is used to call the file system of the first operating system and start the first operating system in response to the second sub-process.

[0035] In one embodiment, the first starting unit is further used for:

[0036] Obtain permission to use the chroot instruction of the second operating system, call and execute the chroot instruction, switch from the second operating system to the file system of the first operating system, and start the first operating system.

[0037] In one embodiment, the first starting unit is further used for:

[0038] The Proot instruction of the second operating system is called and executed, the second operating system is switched to the file system of the first operating system, and the first operating system is started.

[0039] In one embodiment, the first starting unit is further used for:

[0040] A third process is started to read the environment configuration information required to modify the root directory; a shared file is created through the third process, and the environment configuration information is written into the shared file; a third child process is derived through the third process, and environment variables are set in the third child process; a first function is called through the third child process, and a file path parameter passed in by the function call is replaced by the path of the second operating system with the path of the first operating system, and a file path parameter returned by the function call is replaced by the path of the second operating system with the path of the first operating system.

[0041] In one embodiment, the first starting unit is further used for:

[0042] The dynamic library is loaded through a linker, so that the dynamic library calls a fourth function to obtain the environment configuration information through the environment variable, and saves the functions related to the file path, wherein the functions related to the file path include: a fifth function whose input parameters include the file path and a sixth function whose return results include the file path; when the third child process needs to call the fifth function, the seventh function corresponding to the fifth function in the dynamic library is called to replace the file path parameter passed in by the function call from the path of the second operating system to the path of the first operating system; when the third child process needs to call the sixth function, the eighth function corresponding to the sixth function in the dynamic library is called to replace the file path parameter of the function call return result from the path of the second operating system to the path of the first operating system.

[0043] In one embodiment, the apparatus further comprises:

[0044] The third startup unit is used to respond to the first startup instruction for the first operating system after the initial startup of the first operating system, initialize the device driver and data structure of the first operating system, start the user-level program process, start the system service and software framework-related services of the first operating system, and start the first operating system.

[0045] In one embodiment, the second generating unit is further configured to:

[0046] Trigger the second process to provide a corresponding virtual device for the first operating system, and read the peripheral device information corresponding to the virtual device according to the application program interface API of the second operating system, and configure the virtual device based on the peripheral device information; when it is determined that the virtual device receives an access request sent by the first operating system, send the access request to the second process; based on the access request and the identification information of the virtual device in the access request, the second process calls the corresponding peripheral device through the corresponding API of the second operating system.

[0047] In one embodiment, the second generating unit is further configured to:

[0048] After the first operating system receives an access request for the graphics library, the access request is sent to the second process; the second process obtains the ABI for calling the graphics function in the access request, converts the ABI into a Java API of the second operating system through a Java native interface, calls the peripheral device through the Java API, responds to the first operating system, and implements access to the peripheral device.

[0049] According to a third aspect of an embodiment of the present application, an electronic device is provided, comprising a processor, a memory, and an executable program stored in the memory and capable of being run by the processor, wherein the processor executes the steps of the operating system running method when running the executable program.

[0050] According to a fourth aspect of an embodiment of the present application, a readable non-temporary storage medium is provided, on which an executable program is stored, and when the executable program is executed by a processor, the steps of the operating system running method are implemented.

[0051] In the embodiment of the present application, in view of the situation that the first operating system is installed on the second operating system, a peripheral device access method is provided for the first operating system, so that the first operating system can run independently on the second operating system and can access corresponding peripheral devices such as hardware devices. In addition, the first operating system is equivalent to an application of the second operating system, which is relatively convenient to run, can realize free access to peripheral devices, and is easy to maintain. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the prior art descriptions. Obviously, the drawings described below are some embodiments of the present invention, and for ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0053] Figure 1 A flowchart of the operating system operation method according to an embodiment of the present application;

[0054] Figure 2 This is an example schematic diagram of the operating system operation method of the embodiment of the present application;

[0055] Figure 3 A schematic diagram of a first operating system accessing a peripheral device according to an embodiment of the present application;

[0056] Figure 4 A schematic diagram of the structure of the operating system running device according to an embodiment of the present application;

[0057] Figure 5 This is a schematic block diagram of the composition of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0058] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0059] The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here. In addition, the "and / or" in the specification and claims represents at least one of the connected objects, and the character " / " generally represents that the objects associated with each other are in an "or" relationship.

[0060] It should be noted that, in the absence of conflicts, the embodiments and features in the embodiments of the present application can be combined with each other. The following is a detailed description of the method for modifying the root directory, the device for modifying the root directory, the electronic device, and the readable non-transitory storage medium provided in the embodiments of the present application through specific embodiments and their application scenarios in conjunction with the accompanying drawings.

[0061] Figure 1 Schematic diagram of the operating system operation method of the present application embodiment. Figure 1 As shown, the operating system running method of the embodiment of the present application includes the following processing steps:

[0062] Step 101 : In response to an initial startup instruction for a first operating system, a second operating system loads system resources and system classes to start a first process.

[0063] As an example, the first operating system may include a Linux system, and the second operating system may include an Android system. In the embodiment of the present application, a Linux operating system (OS, Operating System) is installed on the Android system, and the Linux system is installed on the Android system as an application. The embodiment of the present application can not only run the Linux system, but also support access to peripherals such as graphics, audio, video, and camera by the Linux system.

[0064] In the embodiment of the present application, the first process includes Zygote. When the Linux system is started in the Android system, the startup method of the application (App) in the normal Android system is the same, and both are started by Android Zygote fork.

[0065] Step 102: the first process generates a second process in response to a request for generating the second process.

[0066] In the embodiment of the present application, the second process may include a Wrapper. After the first process Zygote forks the AndroidOS App process, it will first run a Linux Wrapper process.

[0067] Step 103: In response to the second process, generate an operating environment of the first operating system on the second operating system, and provide the first operating system with a capability of accessing peripherals.

[0068] In the embodiment of the present application, after the first process Zygote forks the Android operating system App, a Linux Wrapper process will be run first. The main purpose of the Linux Wrapper is to generate the operating environment of the Linux operating system (OS) on the Android system and provide the Linux operating system with the ability to access hardware peripherals.

[0069] Step 104: the second process derives a second child process; in response to the second child process, the file system of the first operating system is called to start the first operating system.

[0070] The Linux Wrapper process forks a new process, namely the second child process. Here, the second child process is a Linux Wrapper derived process, that is, the second child process has exactly the same functions as the Linux Wrapper, but it is controlled by the Linux Wrapper. After the second child process is derived and generated, the file system of the Linux OS is prepared, and chroot is performed to the root of the Linux OS to implement the switch from the second operating system to the first operating system. When chrooting to the root of the Linux OS, it is necessary to first obtain the permission to use chroot. Specifically, by obtaining the permission to use the chroot instruction for changing the root directory of the second operating system, calling and executing the chroot instruction, the second operating system is switched to the file system of the first operating system, and the first operating system is started.

[0071] As an implementation method, the user space root (Proot) instruction of the second operating system may be called and executed, and the second operating system may switch to the file system of the first operating system to start the first operating system, that is, the first operating system may be directly called and started through Proot.

[0072] As an implementation method, the first operating system can also be started in the following manner without obtaining the root permission of the first operating system. Specifically, a third process is started to read the environment configuration information required to modify the root directory; a shared file is created through the third process, and the environment configuration information is written into the shared file; a third child process is derived through the third process, and environment variables are set in the third child process; a first function is called through the third child process, and the file path parameter passed in by the function call is replaced by the path of the second operating system with the path of the first operating system, and the file path parameter returned by the function call is replaced by the path of the second operating system with the path of the first operating system. Specifically, the dynamic library is loaded through the linker, so that the dynamic library calls the fourth function to obtain the environment configuration information through the environment variable, and saves the functions related to the file path, wherein the functions related to the file path include: the fifth function whose input parameter includes the file path and the sixth function whose return result includes the file path; when the third child process needs to call the fifth function, it calls the seventh function corresponding to the fifth function in the dynamic library to replace the file path parameter of the function call input from the path of the second operating system to the path of the first operating system; when the third child process needs to call the sixth function, it calls the eighth function corresponding to the sixth function in the dynamic library to replace the file path parameter of the function call return result from the path of the second operating system to the path of the first operating system. In this example, the third process is the sroot process, and the binary executable program of the chroot environment can be constructed by the sroot command. By starting the sroot process, the root directory (i.e.: chroot) environment configuration information is read and modified, and the environment configuration information specifically includes the root directory of chroot, the mapping relationship between the host file (host file) and the guest file (guest file), etc. A shared file is created through a third process, and the environment configuration information is written to the shared file using the mmap function. The third process derives (fork) a child process and sets environment variables in the child process. Specifically, a first environment variable is set in the child process so that the linker can load the dynamic library in advance and replace functions related to the file path; a second environment variable is set in the child process to pass and save the file path of the environment configuration information. The first environment variable is the LD_LIBRARY_PATH / LD_PRELOAD environment variable, and the second environment variable is the SROOT_CONFIG_FILE environment variable. LD_LIBRARY_PATH / LD_PRELOAD are environment variables for the Linux system. The LD_LIBRARY_PATH environment variable is mainly used to specify other paths besides the default path when searching for shared libraries (dynamic link libraries).The LD_PRELOAD environment variable can affect the runtime linking of the program and allow the definition of dynamic link libraries that are loaded first before the program runs. This function is mainly used to selectively load the same functions in different dynamic link libraries. Through this environment variable, other dynamic link libraries can be loaded between the main program and its dynamic link library, and even overwrite normal function libraries. This example configures the LD_LIBRARY_PATH / LD_PRELOAD environment variable to configure the linker to load the libsroot-libc.so dynamic library in advance and replace functions related to file paths such as libc open or getcwd. This example configures the SROOT_CONFIG_FILE (non-existing) environment variable to pass the file path that saves the chroot environment configuration information. The first function is the exec function, and the child process calls the exec function to execute the child process program to be executed, for example, it can be bash or other binary programs that are executed separately. The file path parameter passed in by the function call is replaced by the main path from the guest path, and the file path parameter returned by the function call is replaced by the path of the second operating system with the path of the first operating system. The dynamic library is the libsroot-libc.so dynamic library. The fourth function includes an init function configured with a construction attribute. The fifth and seventh functions include functions such as open / fopen whose incoming parameters include file paths. The sixth and eighth functions include functions such as getcwd whose return results include file paths. The linker will load the libsroot-libc.so dynamic library by reading the LD_LIBRARY_PATH / LD_PRELOAD environment variables. When the libsroot-libc.so dynamic library is loaded by the linker, it executes the init function configured with the construction (constructor) attribute. The init function will obtain the chroot environment configuration by reading the file through the value of the environment variable SROOT_CONFIG_FILE, and will also save the symbolic addresses of functions such as open / getcwd in libc in the label (table) through the dlsym function. When calling functions such as open / fopen whose incoming parameters include file paths, the corresponding open / fopen and other functions in the libsroot-libc.so dynamic library will be called. It first replaces the incoming file path parameter from the guest path to the host path, and then calls the corresponding open / fopen functions through the previously saved libc.so function address. When calling getcwd and other functions whose return results include the file path, the corresponding getcwd and other functions in the libsroot-libc.so dynamic library are also called.It first calls the corresponding getcwd and other functions through the previously saved function address of libc.so, and then changes the file path parameter of the returned result from the host path to the guest path.

[0073] In this example, the mapping from guest path to host path is implemented by replacing and hacking the open and getcwd functions in libc. The parent process in the host system passes the chroot environment configuration (such as the file mapping table) to all processes in the chroot guest environment through inter-process communication (such as using environment variables and shared memory).

[0074] Figure 2 This is an example schematic diagram of the operating system operation method of the present application embodiment, such as Figure 2 The figure shows the startup process of LinuxOS App in Android system, including the following processing:

[0075] Linux OS is started in the Android operating system. The Linux OS is started in the same way as a normal Android App, and is started by the Android Zygote fork.

[0076] After Zygote forks the Android OS App process, it will first run a Linux Wrapper process. The main purpose of the Linux Wrapper is to generate a Linux OS operating environment on the Android system and provide Linux with the ability to access hardware peripherals.

[0077] The Linux Wrapper process forks a new process, prepares the Linux OS file system, and chroots to the root of the Linux OS. Use the chroot system call to switch the Linux OS file system. This requires root system permissions. You can also use the above two methods to start the Linux system.

[0078] After the initial startup of the Linux system is completed, the subsequent startup process is no different from the standard Linux system startup. That is, the system services and framework-related services are started in sequence through the Init process of the Linux system, and then the related Linux applications are started as needed.

[0079] In the embodiment of the present application, after the first operating system is initially started, the method further includes:

[0080] In response to a first startup instruction for the first operating system, after initializing the device driver and data structure of the first operating system, a user-level program process is started, the system service of the first operating system and the software framework-related service are started, and the first operating system is started. Here, the user-level program process may include an Init process. The first startup instruction here refers to any startup instruction for the first operating system after the initial startup.

[0081] After the initial startup of the Linux system is completed, the kernel has been loaded into the memory, and all device drivers and data structures have been initialized. The kernel can then start itself, and the boot process is completed by starting a user-level program init. That is, after the initial startup of the Linux system is completed, the subsequent startup process is the same as the standard Linux system startup. By starting the Init process of the Linux system, the system services and framework-related services are started in sequence, and then the related Linux applications are started as needed.

[0082] In the embodiment of the present application, when the Linux system is started, access to the peripheral device can be achieved. Specifically, the second process provides the first operating system with a corresponding virtual device, and reads the peripheral device information corresponding to the virtual device according to the application program interface API of the second operating system, and configures the virtual device based on the peripheral device information; when it is determined that the virtual device receives the access request sent by the first operating system, the access request is sent to the second process; based on the access request, the second process calls the corresponding peripheral device through the corresponding API of the second operating system according to the identification information of the virtual device in the access request.

[0083] Alternatively, as an implementation method, Linux implements access to peripheral devices including: after the first operating system receives an access request for a graphics library, the access request is sent to the second process; the second process obtains an application binary interface ABI for calling a graphics function in the access request, converts the ABI into a Java API of the second operating system through a Java native interface, calls the peripheral device through the Java API, and responds to the first operating system to implement access to the peripheral device.

[0084] Figure 3 Schematic diagram of a first operating system accessing a peripheral device according to an embodiment of the present application, such as Figure 3As shown in the figure, there are two ways for LinuxOS to access peripheral devices, namely hardware. One is to directly access hardware driver devices. Such peripheral devices mainly include audio, video, input and other devices. For example, some Linux applications will directly access Linux V4L2 vedio devices. The other is to use the user-mode device driver ABI interface to access hardware devices, such as graphics devices. The following is a detailed description.

[0085] How Linux OS directly accesses hardware devices:

[0086] When the Linux OS App is started, the Linux Wrapper is the virtual device required by the Linux OS, such as virtual input and virtual video devices. According to the Android APP API, the device information corresponding to the virtual device is read and the relevant virtual device is configured.

[0087] When the Linux OS process is ready to access the hardware device, it directly accesses the virtual device previously created by the Linux Wrapper.

[0088] After receiving the access request, the virtual device forwards the request to the Linux Wrapper process.

[0089] After receiving the request forwarded by the virtual device, the Linux Wrapper process calls the Android App API to access the real physical device.

[0090] Linux accesses hardware devices through the user-mode ABI interface:

[0091] This method is mainly to solve the problem of converting the C / C++ABI interface called by Linux OS into Android's Java API interface, and to solve the problem of differences in the basic C library between Linux and Android systems.

[0092] Take the graph as an example for explanation, the rest is the same as this:

[0093] The graphics system of the Linux system mainly calls the mesa graphics library, and a new driver process is set in the mesa graphics library. The new driver process can call the C / C++ABI interface provided by the Linux Wrapper to access the graphics function. Since the Linux system uses GlibC, and the C / C++ dynamic library provided by the Andriod system and the Linux Wrapper uses Bionic, it cannot be called directly without the relevant data packet conversion. The GlibC program can call the Bionic dynamic library through a compatible linker. Specifically, when the Linux Wrapper is called by Linux to call the graphics function C / C++ABI interface, the relevant interface is converted to call the Android Java API interface through the Java JNI mechanism. Through the interface encapsulation conversion implemented by the Linux Wrapper, the Linux system can indirectly call the Android App API to implement system access to hardware functions.

[0094] Figure 4 Schematic diagram of the structure of the operating system running device of the embodiment of the present application. Figure 4 As shown, the operating system running device of the embodiment of the present application includes:

[0095] A first startup unit 40, configured to respond to an initial startup instruction for the first operating system, causing the second operating system to load system resources and system classes to start the first process;

[0096] A first generating unit 41, configured to enable the first process to generate a second process in response to a request for generating a second process;

[0097] A second generating unit 42, configured to generate, in response to the second process, an operating environment of the first operating system on the second operating system, and provide the first operating system with a capability of accessing peripherals;

[0098] A deriving unit 43, configured to trigger the second process to derive a second child process;

[0099] The second starting unit 44 is used to call the file system of the first operating system and start the first operating system in response to the second sub-process.

[0100] As an implementation manner, the first starting unit 40 is further configured to:

[0101] Obtain permission to use the chroot instruction of the second operating system, call and execute the chroot instruction, switch from the second operating system to the file system of the first operating system, and start the first operating system.

[0102] As an implementation manner, the first starting unit 40 is further configured to:

[0103] The Proot instruction of the second operating system is called and executed, the second operating system is switched to the file system of the first operating system, and the first operating system is started.

[0104] As an implementation manner, the first starting unit 40 is further configured to:

[0105] A third process is started to read the environment configuration information required to modify the root directory; a shared file is created through the third process, and the environment configuration information is written into the shared file; a third child process is derived through the third process, and environment variables are set in the third child process; a first function is called through the third child process, and a file path parameter passed in by the function call is replaced by the path of the second operating system with the path of the first operating system, and a file path parameter returned by the function call is replaced by the path of the second operating system with the path of the first operating system.

[0106] As an implementation manner, the first starting unit 40 is further configured to:

[0107] The dynamic library is loaded through a linker, so that the dynamic library calls a fourth function to obtain the environment configuration information through the environment variable, and saves the functions related to the file path, wherein the functions related to the file path include: a fifth function whose input parameters include the file path and a sixth function whose return results include the file path; when the third child process needs to call the fifth function, the seventh function corresponding to the fifth function in the dynamic library is called to replace the file path parameter passed in by the function call from the path of the second operating system to the path of the first operating system; when the third child process needs to call the sixth function, the eighth function corresponding to the sixth function in the dynamic library is called to replace the file path parameter of the function call return result from the path of the second operating system to the path of the first operating system.

[0108] As a way to achieve this, Figure 4 Based on the operating system running device shown, the operating system running device of the embodiment of the present application further includes:

[0109] The third startup unit ( Figure 4 ), which is used to respond to a first startup instruction for the first operating system after the initial startup of the first operating system, initialize the device driver and data structure of the first operating system, start the user-level program process, start the system service and software framework-related services of the first operating system, and start the first operating system.

[0110] As an implementation manner, the second generating unit 42 is further configured to:

[0111] Trigger the second process to provide a corresponding virtual device for the first operating system, and read the peripheral device information corresponding to the virtual device according to the application program interface API of the second operating system, and configure the virtual device based on the peripheral device information; when it is determined that the virtual device receives an access request sent by the first operating system, send the access request to the second process; based on the access request and the identification information of the virtual device in the access request, the second process calls the corresponding peripheral device through the corresponding API of the second operating system.

[0112] As an implementation manner, the second generating unit 42 is further configured to:

[0113] After the first operating system receives an access request for the graphics library, the access request is sent to the second process; the second process obtains the ABI for calling the graphics function in the access request, converts the ABI into a Java API of the second operating system through a Java native interface, calls the peripheral device through the Java API, responds to the first operating system, and implements access to the peripheral device.

[0114] In an exemplary embodiment, the first startup unit 40, the first generation unit 41, the second generation unit 42, the derivation unit 43, the second startup unit 44 and the third startup unit, etc. can be implemented by one or more central processing units (CPU, Central Processing Unit), application specific integrated circuits (ASIC, Application Specific Integrated Circuit), digital signal processors (Digital Signal Processor, DSP), programmable logic devices (PLD, Programmable Logic Device), complex programmable logic devices (CPLD, Complex Programmable Logic Device), field programmable gate arrays (FPGA, Field-Programmable Gate Array), general-purpose processors, controllers, microcontrollers (MCU, Micro Controller Unit), microprocessors (Microprocessors), or other electronic components, and are used to execute the steps of the operating system running method of the aforementioned embodiments.

[0115] In the disclosed embodiment, Figure 4The specific manner in which each unit in the operating system running device shown performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0116] The operating system running device in the embodiment of the present application can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. Exemplarily, the mobile electronic device can be a mobile phone, a tablet computer, a laptop computer, a PDA, an in-vehicle electronic device, a wearable device, an ultra-mobile personal computer (UMPC), a netbook, or a personal digital assistant (PDA), etc. The non-mobile electronic device can be a server, a network attached storage (NAS), a personal computer (PC), a television (TV), a teller machine or a self-service machine, etc., which is not specifically limited in the embodiment of the present application.

[0117] The operating system running device in the embodiment of the present application may be a device having an operating system. The operating system may be an Android operating system, an iOS operating system, or other possible operating systems, which are not specifically limited in the embodiment of the present application.

[0118] Below, reference Figure 5 The electronic device 11 according to an embodiment of the present application is described.

[0119] like Figure 5 As shown, the electronic device 11 includes one or more processors 111 and a memory 112 .

[0120] The processor 111 may be a central processing unit (CPU) or other forms of processing units having data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 11 to perform desired functions.

[0121] The memory 112 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, a random access memory (RAM) and / or a cache memory (cache), etc. The non-volatile memory may include, for example, a read-only memory (ROM), a hard disk, a flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 111 may run the program instructions to implement the operating system operation method of each embodiment of the present application described above and / or other desired functions. Various contents such as input signals, signal components, noise components, etc. may also be stored in the computer-readable storage medium.

[0122] In one example, the electronic device 11 may further include: an input device 113 and an output device 114 , and these components are interconnected via a bus system and / or other forms of connection mechanisms (not shown).

[0123] The input device 113 may include, for example, a keyboard, a mouse, etc.

[0124] The output device 114 can output various information to the outside, including determined distance information, direction information, etc. The output device 114 can include, for example, a display, a speaker, a printer, a communication network and a remote output device connected thereto, and the like.

[0125] Of course, to simplify, Figure 5 Only some of the components related to the present application in the electronic device 11 are shown, and components such as a bus, an input / output interface, etc. are omitted. In addition, according to specific application situations, the electronic device 11 may also include any other appropriate components.

[0126] The embodiment of the present application also records a readable non-temporary storage medium on which an executable program is stored, and the executable program is executed by a processor to perform the steps of the operating system running method of the aforementioned embodiment.

[0127] In addition to the above-mentioned methods and devices, an embodiment of the present application may also be a computer program product, which includes computer program instructions, which, when executed by a processor, enable the processor to execute the steps of the method according to various embodiments of the present application described in the above-mentioned "Exemplary Method" section of this specification.

[0128] The computer program product may be written in any combination of one or more programming languages ​​to write program codes for performing the operations of the embodiments of the present application, including object-oriented programming languages, such as Java, C++, etc., and conventional procedural programming languages, such as "C" language or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as an independent software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0129] In addition, an embodiment of the present application may also be a computer-readable storage medium on which computer program instructions are stored. When the computer program instructions are executed by a processor, the processor executes the steps of the method according to various embodiments of the present application described in the above "Exemplary Method" section of this specification.

[0130] The computer readable storage medium can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can include, for example, but is not limited to, a system, device or device of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination of the above. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0131] The basic principles of the present application are described above in conjunction with specific embodiments. However, it should be noted that the advantages, strengths, effects, etc. mentioned in the present application are only examples and not limitations, and it cannot be considered that these advantages, strengths, effects, etc. are required by each embodiment of the present application. In addition, the specific details disclosed above are only for the purpose of illustration and ease of understanding, not for limitation, and the above details do not limit the present application to being implemented by adopting the above specific details.

[0132] The block diagrams of the devices, apparatuses, equipment, and systems involved in this application are only illustrative examples and are not intended to require or imply that they must be connected, arranged, and configured in the manner shown in the block diagram. As will be appreciated by those skilled in the art, these devices, apparatuses, equipment, and systems can be connected, arranged, and configured in any manner. Words such as "including", "comprising", "having", etc. are open words, referring to "including but not limited to", and can be used interchangeably with them. The words "or" and "and" used here refer to the words "and / or" and can be used interchangeably with them, unless the context clearly indicates otherwise. The words "such as" used here refer to the phrase "such as but not limited to", and can be used interchangeably with them.

[0133] It should also be noted that in the apparatus, device and method of the present application, each component or each step can be decomposed and / or recombined. Such decomposition and / or recombination should be regarded as equivalent solutions of the present application.

[0134] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use the present application. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of the present application. Therefore, the present application is not intended to be limited to the aspects shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

[0135] The above description has been given for the purpose of illustration and description. In addition, this description is not intended to limit the embodiments of the present application to the forms disclosed herein. Although multiple example aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, changes, additions and sub-combinations thereof.

Claims

1. A method for operating an operating system, characterized in that: The method comprises: In response to an initial startup instruction for the first operating system, the second operating system loads system resources and system classes to start a first process; the first operating system is installed in the second operating system; The first process generates the second process in response to the generation request of the second process; In response to the second process, generating an operating environment of the first operating system on the second operating system, and providing the first operating system with a capability of accessing peripherals; The second process derives a second child process; in response to the second child process, calls the file system of the first operating system and starts the first operating system; The capability of providing the first operating system with access to peripheral devices includes: upon receiving an access request sent by the first operating system, sending the access request to the second process; and the second process calling the peripheral device corresponding to the virtual device through the corresponding interface of the second operating system based on the identification information of the virtual device in the access request.

2. The method according to claim 1, characterized in that The calling the file system of the first operating system and starting the first operating system includes: Obtain permission to use the chroot instruction for changing the root directory of the second operating system, call and execute the chroot instruction, switch from the second operating system to the file system of the first operating system, and start the first operating system.

3. The method according to claim 1, characterized in that: The calling the file system of the first operating system and starting the first operating system includes: The user space root Proot instruction of the second operating system is called and executed, the second operating system is switched to the file system of the first operating system, and the first operating system is started.

4. The method according to claim 1, characterized in that: The calling the file system of the first operating system and starting the first operating system includes: A third process is started to read the environment configuration information required to modify the root directory; a shared file is created through the third process, and the environment configuration information is written into the shared file; a third child process is derived through the third process, and environment variables are set in the third child process; a first function is called through the third child process, and a file path parameter passed in by the function call is replaced by the path of the second operating system with the path of the first operating system, and a file path parameter returned by the function call is replaced by the path of the second operating system with the path of the first operating system.

5. The method according to claim 4, characterized in that The step of replacing the file path parameter passed in by the function call from the path of the second operating system to the path of the first operating system, and replacing the file path parameter returned by the function call from the path of the second operating system to the path of the first operating system, comprises: The dynamic library is loaded through a linker, so that the dynamic library calls a fourth function to obtain the environment configuration information through the environment variable, and saves the functions related to the file path, wherein the functions related to the file path include: a fifth function whose input parameter includes the file path and a sixth function whose return result includes the file path; When the third child process needs to call the fifth function, the seventh function in the dynamic library corresponding to the fifth function is called to replace the file path parameter passed in by the function call from the path of the second operating system to the path of the first operating system; When the third subprocess needs to call the sixth function, it calls the eighth function in the dynamic library corresponding to the sixth function to replace the file path parameter of the function call return result from the path of the second operating system to the path of the first operating system.

6. The method according to any one of claims 1 to 5, characterized in that: After the first operating system is initially started, the method further includes: In response to a first startup instruction for the first operating system, after initializing the device driver and data structure of the first operating system, the user-level program process is started, the system service and software framework-related services of the first operating system are started, and the first operating system is started.

7. The method according to claim 6, characterized in that Providing the first operating system with a capability of accessing a peripheral device includes: The second process provides a corresponding virtual device for the first operating system, reads peripheral device information corresponding to the virtual device according to an application program interface (API) of the second operating system, and configures the virtual device based on the peripheral device information; When determining that the virtual device receives the access request sent by the first operating system, send the access request to the second process; The second process calls the corresponding peripheral device through the corresponding API of the second operating system based on the access request and according to the identification information of the virtual device in the access request.

8. The method according to claim 6, characterized in that Providing the first operating system with a capability of accessing a peripheral device includes: After receiving the access request for the graphics library, the first operating system sends the access request to the second process; The second process obtains the application binary interface ABI for calling the graphics function in the access request, converts the ABI into a Java API of the second operating system through a Java native interface, calls the peripheral device through the Java API, responds to the first operating system, and implements access to the peripheral device.

9. An operating system running device, characterized in that: The device comprises: A first startup unit, configured to respond to an initial startup instruction for the first operating system, and enable the second operating system to load system resources and system classes to start a first process; the first operating system is installed in the second operating system; A first generating unit, configured to enable the first process to generate a second process in response to a request for generating a second process; a second generating unit, configured to generate, in response to the second process, an operating environment of the first operating system on the second operating system, and provide the first operating system with a capability of accessing peripherals; A deriving unit, used for triggering the second process to derive a second child process; A second starting unit, configured to call a file system of the first operating system in response to the second sub-process and start the first operating system; The second startup unit is also used to send the access request sent by the first operating system to the second process when receiving the access request; the second process calls the peripheral device corresponding to the virtual device through the corresponding interface of the second operating system based on the identification information of the virtual device in the access request.

10. The device according to claim 9, characterized in that The first starting unit is further used for: Obtain permission to use the chroot instruction of the second operating system, call and execute the chroot instruction, switch from the second operating system to the file system of the first operating system, and start the first operating system.

11. The device according to claim 9, characterized in that The first starting unit is further used for: The Proot instruction of the second operating system is called and executed, the second operating system is switched to the file system of the first operating system, and the first operating system is started.

12. The device according to claim 9, characterized in that The first starting unit is further used for: A third process is started to read the environment configuration information required to modify the root directory; a shared file is created through the third process, and the environment configuration information is written into the shared file; a third child process is derived through the third process, and environment variables are set in the third child process; a first function is called through the third child process, and a file path parameter passed in by the function call is replaced by the path of the second operating system with the path of the first operating system, and a file path parameter returned by the function call is replaced by the path of the second operating system with the path of the first operating system.

13. The device according to claim 12, characterized in that The first starting unit is further used for: The dynamic library is loaded through a linker, so that the dynamic library calls a fourth function to obtain the environment configuration information through the environment variable, and saves the functions related to the file path, wherein the functions related to the file path include: a fifth function whose input parameters include the file path and a sixth function whose return results include the file path; when the third child process needs to call the fifth function, the seventh function corresponding to the fifth function in the dynamic library is called to replace the file path parameter passed in by the function call from the path of the second operating system to the path of the first operating system; when the third child process needs to call the sixth function, the eighth function corresponding to the sixth function in the dynamic library is called to replace the file path parameter of the function call return result from the path of the second operating system to the path of the first operating system.

14. The device according to any one of claims 9 to 13, characterized in that The device also includes: The third startup unit is used to respond to the first startup instruction for the first operating system after the initial startup of the first operating system, initialize the device driver and data structure of the first operating system, start the user-level program process, start the system service and software framework-related services of the first operating system, and start the first operating system.

15. The device according to claim 14, characterized in that The second generating unit is further used for: Triggering the second process to provide a corresponding virtual device for the first operating system, and reading peripheral device information corresponding to the virtual device according to the application program interface API of the second operating system, and configuring the virtual device based on the peripheral device information; When it is determined that the virtual device receives an access request sent by the first operating system, the access request is sent to the second process; the second process calls the corresponding peripheral device through the corresponding API of the second operating system based on the access request and the identification information of the virtual device in the access request.

16. The device according to claim 14, characterized in that The second generating unit is further used for: After the first operating system receives an access request for the graphics library, the access request is sent to the second process; the second process obtains the ABI for calling the graphics function in the access request, converts the ABI into a Java API of the second operating system through a Java native interface, calls the peripheral device through the Java API, responds to the first operating system, and implements access to the peripheral device.

17. An electronic device, characterized in that: The method comprises a processor, a memory, and a program or instruction stored in the memory and executable on the processor, wherein the program or instruction, when executed by the processor, implements the steps of the operating system running method described in any one of claims 1 to 8.

18. A readable non-transitory storage medium, characterized in that: The storage medium stores programs or instructions, and when the programs or instructions are executed by the processor, the steps of the operating system running method described in any one of claims 1 to 8 are implemented.

Images