Computing device, operating system startup method and apparatus, and operating system running method

Abstract

The present application relates to the technical field of computers. Provided in the embodiments of the present application are a computing device, an operating system startup method and apparatus, and an operating system running method. A memory of the computing device stores a plurality of operating systems, for example: a first operating system and a second operating system. The first operating system and the second operating system have a common bootloader and kernel, that is, the first operating system and the second operating system share the same bootloader and kernel, thereby reducing bootloaders and kernels of the plurality of operating systems, for example: in the case of M operating systems, at least M-1 bootloaders and M-1 kernels can be eliminated. Therefore, the architecture of the plurality of operating systems of the computing device achieves simplification of the architecture of a plurality of operating systems, and can also significantly reduce the storage space occupation by a plurality of operating systems.

Description

Computing device, operating system startup method, operation method and device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on December 29, 2023, with application number 202311871790.6 and application name “Computing device, operating system startup method, operation method and device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of computer technology, and in particular to a computing device, an operating system startup method, an operating method, and an apparatus. Background Art

[0003] In related art, when a computing device is configured with multiple operating systems, each operating system typically includes a boot loader, a kernel, a root file system, and multiple application programs, etc. The boot loader, kernel, root file system, and multiple application programs of each operating system are stored in different partitions of the memory.

[0004] Since the architecture of multiple operating systems in related technologies is relatively simple, there is an urgent need to design a new architecture of multiple operating systems.

[0005] Summary of the Invention

[0006] The embodiments of the present application provide a computing device, an operating system startup method, an operation method, and an apparatus, which not only simplify the architecture of multiple operating systems, but also reduce the storage space occupied by multiple operating systems.

[0007] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

[0008] In a first aspect, a computing device is provided, comprising a memory and a processor, the memory being used to store a first operating system and a second operating system, the first operating system comprising a container of the first operating system, and the second operating system comprising a container of the second operating system; the first operating system and the second operating system having a common boot loader and kernel; the processor being used to run the boot loader and kernel, thereby running the container of the first operating system; and the processor being further used to switch from the container of the first operating system to the container of the second operating system upon detecting a target event.

[0009] In this solution, a plurality of operating systems are stored in the memory of the computing device, such as a first operating system and a second operating system. The first operating system and the second operating system have a common boot loader and kernel. That is, the first operating system and the second operating system share the same boot loader and kernel, thereby reducing the boot programs and kernels of multiple operating systems. For example, when there are M operating systems, at least M-1 boot loaders and M-1 kernels can be reduced. Therefore, the architecture of the multiple operating systems of the computing device, compared with the architecture form in the related art, can not only simplify the architecture of the multiple operating systems, but also significantly reduce the storage space occupied by the multiple operating systems.

[0010] In addition, since the first operating system and the second operating system have a common boot loader and kernel, if the second operating system needs to be started during the running of the first operating system, the processor does not need to repeatedly run the boot loader and kernel, but can directly run the container of the second operating system. This can significantly shorten the time consumed by restarting the operating system, thereby helping to improve the operating system startup efficiency, and further helping to improve the user experience.

[0011] In one possible implementation, the processor is further configured to generate a memory file system during kernel execution, the memory file system being configured to provide operating system switching, operating system upgrade, and jump functions; the first operating system and the second operating system have a common memory file system.

[0012] Since the memory file system is a system used to manage files during the operation of the operating system, it is in operation throughout the life cycle of the operating system. That is, as long as the operating system is not restarted or shut down, the memory file system will always exist. Based on this, by setting up the memory file system, it is possible to provide operating system switching functions, operating system upgrade functions, jump functions, switching configuration functions, jump functions, etc., so that operating system switching functions, operating system upgrade functions, jump functions, switching configuration functions, jump functions, etc. can be provided during the operation of the first operating system. This helps to improve the functional diversity of the operating system and thus helps to improve the user experience.

[0013] In another possible implementation, the processor is further configured to switch from a container of the first operating system to a container of the second operating system when a target event is detected, including: the processor is further configured to jump from a container of the first operating system to a memory file system when the detected target event indicates switching operating systems; the processor is further configured to determine the container to switch to the second operating system; and the processor is further configured to switch from the memory file system to the container of the second operating system.

[0014] In this implementation, since the first operating system and the second operating system share the same memory file system, and the memory file system provides an operating system switching function, the processor jumps from the container of the first operating system to the container of the second operating system through the memory file system. On the one hand, there is no need to restart the memory file system for the second operating system. On the other hand, the operating system switching function provided by the memory file system is fully utilized.

[0015] In another possible implementation, the processor is configured to switch from the memory file system to the container of the second operating system, including: the processor is configured to switch from the memory file system to the container of the second operating system when a first preset condition is met.

[0016] In this implementation, by setting a first preset condition to be met, the system directly switches to the container of the second operating system. In this way, by setting an appropriate first preset condition, the operating stability and reliability of the second operating system after switching to the container of the second operating system are improved.

[0017] In another possible implementation, the processor is further configured to re-run the boot loader and the kernel, thereby running the container of the second operating system, when the first preset condition is not met.

[0018] In this implementation, when the first preset condition is not met, the boot loader and the kernel are re-run to run the container of the second operating system. In this way, by setting an appropriate first preset condition, not only can a variety of different operating system switching methods be provided to the user, but it also helps to improve the operating stability and reliability of the second operating system after switching to the container of the second operating system.

[0019] In another possible implementation, the processor is further used to determine the container to switch to the second operating system, including: the processor is further used to obtain startup configuration parameters from the storage medium of the computing device; the startup configuration parameters are used to indicate the container of the operating system to be switched; the processor is further used to determine the container to switch to the second operating system based on the startup configuration parameters.

[0020] In this implementation, the processor determines the container of the operating system to be switched through the startup configuration parameters in the storage medium. This not only helps to improve the convenience of determining the container of the operating system to be switched, but also reduces the user's workload and does not need to be specified by the user, thereby helping to improve the user's experience.

[0021] In another possible implementation, the processor is further configured to, when a target event is detected, determine startup configuration parameters based on an identifier of the container of the first operating system; and the processor is further configured to write the startup configuration parameters into a storage medium of the computing device.

[0022] In this implementation, when the processor detects the target event, it writes the startup configuration parameters to the storage medium. In this way, when it is necessary to determine the container of the operating system to be switched later, the processor can directly read the startup configuration parameters from the storage medium, which helps to improve the convenience of determining the container of the operating system to be switched.

[0023] In another possible implementation, the storage medium includes a volatile storage medium; the processor is also used to write the startup configuration parameters into the storage medium of the computing device, including: the processor is also used to write the startup configuration parameters into the volatile storage medium when a first preset condition is met.

[0024] In this implementation, when the first preset condition is met, the computing device will not continue to jump to run the ROM boot program after jumping to the memory file system. Therefore, the computing device will not be powered off. Based on this, the startup configuration parameters are stored in a volatile storage medium, which not only ensures that the startup configuration parameters can be obtained, but also automatically clears the startup configuration parameters during the subsequent power-off process of the computing device, avoiding the startup configuration parameters occupying storage space for a long time and affecting the normal system startup process.

[0025] In another possible implementation, the storage medium also includes a non-volatile storage medium; the processor is also used to write the startup configuration parameters into the storage medium of the computing device, including: the processor is also used to write the startup configuration parameters into the non-volatile storage medium when the first preset condition is not met.

[0026] In this embodiment, when the first preset condition is not met, the startup configuration parameters are stored in a non-volatile storage medium. This helps avoid the loss of the startup configuration parameters when jumping to run the ROM boot program, thereby helping to ensure the smooth execution of the operating system switching process.

[0027] In another possible implementation, the non-volatile storage medium includes a raw partition or a user flash memory (UFM) of the computing device, which helps to fully utilize the storage space on different storage media on the computing device.

[0028] In another possible implementation, the processor is further configured to, upon detecting a target event, determine startup configuration parameters based on the identifier of the first operating system's container. This includes: Upon detecting a target event, the processor is further configured to, upon detecting a target event, determine the identifier of the first operating system's container as a startup configuration parameter based on the identifier of the first operating system's container. This helps improve the efficiency of writing startup configuration parameters.

[0029] In another possible implementation, the processor is further configured to, upon detecting a target event, determine startup configuration parameters based on the identifier of the first operating system's container. This includes: Upon detecting a target event, the processor is further configured to, upon detecting a target event, determine the identifier of the second operating system's container based on the identifier of the first operating system's container as the startup configuration parameter. This helps improve the efficiency of operating system switching based on startup configuration parameters.

[0030] In another possible implementation, satisfying the first preset condition includes: the target event indicating a container switch, and / or the closing operations of multiple applications in the container of the first operating system satisfying the target condition; the container switch is used to indicate a switch to a container of the operating system to be switched during a system switch;

[0031] In this implementation, by setting the closing operations of multiple applications to meet the target conditions, the first preset condition is met. In this way, by setting appropriate target conditions, it not only helps to improve the stability of the currently running first operating system and avoid the crash of the first operating system due to the crash of multiple applications, but also helps to avoid the stability and reliability of multiple applications of the second operating system that are subsequently started due to improper closing of multiple applications of the first operating system.

[0032] In addition, by setting the target event to indicate the container switch, it is determined that the preset conditions are met, thereby determining the system jump method according to the user-specified system switch type, which helps to improve the user experience.

[0033] In another possible implementation, the closing operations of the multiple applications meet the target condition, including: the multiple applications are closed successfully, and / or the closing order of the multiple applications is opposite to the starting order of the multiple applications.

[0034] This not only helps prevent the crash of multiple applications and the resulting crash of the first operating system, but also helps prevent multiple applications of the first operating system from affecting the normal operation of multiple applications of the subsequently started second operating system.

[0035] In another possible implementation, the computing device is further configured to re-run the boot loader and kernel when a target event is currently detected, thereby running a container of the second operating system. In this way, the completed operating system can be restarted, thereby helping to ensure the integrity of the operating system startup process, as well as the stability and reliability of the operating system after restart. In another possible implementation, the processor is configured to run the boot loader and kernel, including: the processor is configured to, when the processor is powered on, instruct the boot loader based on the ROM boot program of the computing device, run the boot loader and kernel, and generate a memory file system; the processor is further configured to determine to start a container of the first operating system, and to switch from the memory file system to the container of the first operating system.

[0036] In this implementation, the process of starting the operating system when the processor is powered on is the same as the system switching process when returning to the ROM boot program when switching the operating system. This helps to simplify the startup operation procedure.

[0037] In another possible implementation, the processor is further configured to, when the detected target event indicates an operating system upgrade, determine a container of the operating system to be upgraded; the processor is further configured to perform an upgrade operation on the container of the operating system to be upgraded, and not perform an upgrade operation on the boot loader and / or kernel of the operating system to be upgraded.

[0038] In this implementation, since the upgrade operation is no longer performed on the boot loader and / or kernel of the upgraded operating system, the number of partitions performing the upgrade operation is reduced, thereby shortening the time consumed by the system upgrade, improving the efficiency of the system upgrade, and thus improving the user experience.

[0039] In another possible implementation, the processor is further used to determine the container of the operating system to be upgraded when the detected target event indicates upgrading the operating system, including: the processor is further used to obtain the root directory path when the detected target event indicates upgrading the operating system; the root directory path is used to indicate the container currently in running state, and the root directory path indicates the container of the first operating system; the processor is also used to determine that the container of the second operating system is the container of the operating system to be upgraded based on the root directory path indicating the container of the first operating system.

[0040] In this implementation, when performing a system upgrade, the processor determines the container of the operating system to be upgraded based on the root directory path. This not only helps to improve the convenience of determining the container of the operating system to be started, but also reduces the user's workload. The user no longer needs to specify the container of the operating system to be started, which helps to improve the user experience.

[0041] In another possible implementation, the processor is further used to determine the container of the operating system to be upgraded when the detected target event indicates upgrading the operating system, including: the processor is further used to obtain the root directory path when the detected target event indicates upgrading the operating system; the root directory path is used to indicate the container currently in the running state, and the root directory path indicates the container of the first operating system; the processor is also used to determine that the container of the first operating system is the container of the operating system to be upgraded based on the root directory path indicating the container of the first operating system.

[0042] In another possible implementation, the processor is further used to determine the container of the operating system to be upgraded when the detected target event indicates upgrading the operating system, including: the processor is further used to determine the container of the operating system to be upgraded according to the container identifier indicated by the target event when the detected target event indicates upgrading the operating system.

[0043] In this implementation, when performing a system upgrade, the container of the operating system to be upgraded is determined based on the container identifier indicated by the target event. This not only increases the diversity of methods for determining the container of the operating system to be upgraded, but also helps to improve the correlation between the container of the operating system to be upgraded and the target event, thereby facilitating the accuracy of determining the container of the operating system to be upgraded.

[0044] In another possible implementation, the processor is further used to determine the container of the operating system to be upgraded when the detected target event indicates upgrading the operating system, including: the processor is further used to determine the container of the operating system to be upgraded when the detected target event indicates upgrading the operating system and a second preset condition is met.

[0045] In this implementation, the container of the operating system to be upgraded is determined only when the second preset condition is met, so that only the container of the operating system is upgraded. In this way, by setting an appropriate second preset condition, the stability and reliability of the upgraded operating system can be improved after only the container is upgraded.

[0046] In another possible implementation, the processor is also used to determine the operating system to be upgraded when the detected target event indicates upgrading the operating system and the second preset condition is not met; the processor is also used to perform upgrade operations on the boot loader, kernel and container of the operating system to be upgraded.

[0047] In this implementation, by setting when the second preset condition is not met, the operating system to be upgraded is determined, and the complete operating system is upgraded, that is, the boot loader, kernel and container are upgraded. On the one hand, it can provide users with a variety of different system upgrade methods. On the other hand, by setting a suitable second preset condition, it helps to improve the stability and reliability of the upgraded operating system.

[0048] In another possible implementation, satisfying the second preset condition includes: the target event indicates a container upgrade.

[0049] In this implementation, only the operating system container is upgraded when the target event indicates a container upgrade. This helps upgrade the operating system according to the system upgrade type indicated by the user, thereby improving the user experience.

[0050] In another possible implementation, satisfying the second preset condition includes: the version of the operating system to be upgraded is higher than or equal to the compatible version of the upgrade package of the operating system to be upgraded.

[0051] In this implementation, by setting the version of the operating system to be upgraded to be higher than or equal to the compatible version of the upgrade package of the operating system to be upgraded, the second preset condition is met, that is, only the container of the operating system is upgraded. This helps to ensure that the upgraded container is compatible with the non-upgraded boot loader and kernel, thereby helping to improve the stability and reliability of the upgraded operating system.

[0052] In another possible implementation, satisfying the second preset condition includes: the target event indicating a container upgrade, and / or the version of the operating system to be upgraded is higher than or equal to a compatible version of the upgrade package of the operating system to be upgraded.

[0053] In a second aspect, a method for running an operating system is provided, the method comprising: displaying an operating system selection interface, the operating system selection interface being used to indicate selection of starting a container for a first operating system or a container for a second operating system; the first operating system and the second operating system having a common boot loader and kernel; upon receiving a first user operation on the operating system selection interface, determining a container for running the first operating system; and upon receiving a second user operation on the operating system selection interface, determining a container for running the second operating system.

[0054] In this solution, the terminal device used by the user can display an operating system selection interface, which can be used to indicate the selection of starting a container for the first operating system or a container for the second operating system. When the user needs to restart the operating system, the user can perform an operation on the interface. After the terminal device receives the operation performed by the user, if it is a first user operation (that is, the user selects a container for the first operating system), the terminal device determines the container to run the first operating system; if it is a second user operation, the terminal device determines the container to run the second operating system. Since the terminal device can determine the container to run different operating systems based on different operations performed by the user, the user can determine the container of the operating system to be started. This not only helps to improve the user experience, but also allows the user to choose to run containers of different operating systems according to the different needs of actual scenarios.

[0055] In a third aspect, an operating system startup method is provided for a computing device, the computing device including a memory and a processor, the memory being used to store a first operating system and a second operating system, the first operating system including a container of the first operating system, and the second operating system including a container of the second operating system; the first operating system and the second operating system having a common boot loader and kernel; the method including: the processor being used to run the boot loader and the kernel, thereby running the container of the first operating system; the processor being further used to switch from the container of the first operating system to the container of the second operating system when a target event is detected.

[0056] In this solution, after the processor runs the boot loader and kernel stored in the memory, it runs the container of the first operating system, thereby running the first operating system. On this basis, when the processor detects a target event, the processor directly switches from the container of the first operating system to the container of the second operating system to run the container of the second operating system, thereby running the second operating system. Since the first operating system and the second operating system have a common boot loader and kernel, if the second operating system needs to be started during the operation of the first operating system, the processor does not need to repeatedly run the boot loader and kernel, but can directly run the container of the second operating system. In this way, the time consumed to restart the operating system can be significantly shortened, thereby helping to improve the efficiency of the operating system startup, and then helping to improve the user experience. In addition, the second operating system and the second operating system share the same boot loader and kernel, which simplifies the architecture of the operating system and reduces the storage space occupied by the operating system.

[0057] It should be noted that in the third aspect, the processor can also be used to execute any possible implementation method provided in the first aspect above.

[0058] In a fourth aspect, an operating system startup device is provided, which includes a functional unit for executing any one of the methods provided in the first aspect. The actions performed by each functional unit can be implemented by a computing device or by executing corresponding software on the computing device. The computing device includes a first operating system and a second operating system, the first operating system includes a container for the first operating system, and the second operating system includes a container for the second operating system; the first operating system and the second operating system have a common boot loader and the kernel. For example, the operating system startup device can run a module and a switching module. The running module is used to run the boot loader and the kernel, thereby running the container of the first operating system; the switching module is used to switch from the container of the first operating system to the container of the second operating system when a target event is detected.

[0059] In a fifth aspect, a chip is provided, comprising: a processor and a memory, the processor and the memory being connected; the memory being used to store the boot loader, kernel, container of the first operating system, and container of the second operating system in the first aspect, and the processor being used to run the boot loader, kernel, container of the first operating system / container of the second operating system stored in the memory.

[0060] In a sixth aspect, a chip is provided, comprising: a processor and an interface circuit; the interface circuit is used to receive the boot loader, kernel, and container of the first operating system in the above-mentioned first aspect, or to receive the container of the second operating system in the above-mentioned first aspect and transmit it to the processor; the processor is used to run the boot loader, kernel, and container of the first operating system received by the interface circuit, or to run the container of the second operating system received by the interface circuit.

[0061] In a seventh aspect, a computing device is provided, comprising: a power supply and a chip provided by any one of the fifth to sixth aspects above, wherein the power supply is used to power the chip.

[0062] In an eighth aspect, a computing device is provided, comprising: a memory and a processor, the memory being used to store a first operating system and a second operating system, the first operating system comprising a container of the first operating system, the second operating system comprising a container of the second operating system; the first operating system and the second operating system having a common boot loader and kernel.

[0063] In a ninth aspect, a computer-readable storage medium is provided, storing the boot loader, kernel, container for a first operating system, and container for a second operating system provided in the first aspect. A computing device can run the first operating system when running the boot loader, kernel, and container for the first operating system. The computing device can also run the first operating system when switching from running the container for the first operating system to running the container for the second operating system.

[0064] In a tenth aspect, a computer program product is provided, comprising: the boot loader, kernel, container for a first operating system, and container for a second operating system provided in the first aspect. A computing device can run the first operating system when running the boot loader, kernel, and container for the first operating system. The computing device can also run the first operating system when switching from running the container for the first operating system to running the container for the second operating system.

[0065] In an eleventh aspect, an operating system is provided, comprising a boot loader, a kernel, a container for a first operating system, and a container for a second operating system; the first operating system and the second operating system have a common boot loader and kernel; when the boot loader and the kernel are used to boot a container running the first operating system, if a target event is detected, the container of the first operating system is switched to the container of the second operating system; when the boot loader and the kernel are used to boot a container running the second operating system, if a target event is detected, the container of the second operating system is switched to the container of the first operating system.

[0066] Among them, the technical effects brought about by any implementation method in the third aspect to the eleventh aspect can refer to the technical effects brought about by different implementation methods in the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0067] FIG1 is a schematic diagram of a computing device provided in an embodiment of the present application;

[0068] FIG2 is an architecture diagram of multiple operating systems provided in an embodiment of the present application;

[0069] FIG3 is a schematic diagram of the hierarchical structure of an operating system after startup according to an embodiment of the present application;

[0070] FIG4 is a schematic diagram of a file system provided in an embodiment of the present application;

[0071] FIG5 is a schematic diagram of a first interface and a second interface provided in an embodiment of the present application;

[0072] FIG6 is a schematic diagram of a storage medium provided in an embodiment of the present application;

[0073] FIG7 is a schematic diagram of closing an application according to an embodiment of the present application;

[0074] FIG8 is a schematic diagram of an operating system startup process provided by an embodiment of the present application;

[0075] FIG9 is a schematic diagram of an operating system switching method according to an embodiment of the present application;

[0076] FIG10 is a schematic diagram of an operating system switching process provided in an embodiment of the present application;

[0077] FIG11 is a schematic diagram of another file system provided in an embodiment of the present application;

[0078] FIG12 is a schematic diagram of a third interface provided in an embodiment of the present application;

[0079] FIG13 is a schematic diagram of an operating system upgrade according to an embodiment of the present application;

[0080] FIG14 is a schematic diagram of an operation upgrade path provided in an embodiment of the present application;

[0081] FIG15 is a schematic diagram of a third interface provided in an embodiment of the present application;

[0082] FIG16 is a schematic diagram of an operating system upgrade process provided in an embodiment of the present application;

[0083] FIG17 is a flowchart of an operating system startup method provided in an embodiment of the present application;

[0084] FIG18 is a flowchart of a method for operating an operating system provided in an embodiment of the present application;

[0085] Figure 19 is a schematic diagram of an operating system selection interface provided in an embodiment of the present application. DETAILED DESCRIPTION

[0086] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0087] In the description of this application, unless otherwise specified, " / " indicates that the objects associated before and after are in an "or" relationship, for example, A / B can represent A or B; "and / or" in this application is merely a description of the association relationship of associated objects, indicating that three relationships may exist, for example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural.

[0088] Furthermore, in the description of this application, unless otherwise specified, "plurality" means two or more than two. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or plural.

[0089] In addition, in order to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit differences. At the same time, in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or design schemes. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete way for easy understanding.

[0090] The following is a brief introduction to the relevant terms involved in the embodiments of this application.

[0091] Container: It is a virtualization technology in computer operating systems that can be used to encapsulate and isolate the operating environments of different applications, isolating the applications from the operating system. This allows the applications to only access temporarily granted resources and not access the files and folders actually existing on the operating system.

[0092] In an embodiment of the present application, the container may include a root file system, a system daemon process, an application program, and the like.

[0093] Partitioning: Also known as operating system partitioning (OS partition) or system partitioning, it refers to dividing the memory space into different areas. The memory storing the operating system can be divided into different partitions according to the functional characteristics of the operating system, such as the partition for the boot loader (such as uboot), the partition for the kernel (such as kernel), the partition for the root file system (such as rootfs), and the partition for applications.

[0094] In an embodiment of the present application, partitions may include partitions for boot loader, partitions for kernel, and partitions for containers, etc.

[0095] Root file system (such as: rootfs): used to manage and store files.

[0096] Memory file system (ramfs): It is the basic file system pulled up by the operating system kernel and is used for mounting / unmounting partitions, system restart, and interacting with the processor.

[0097] The change root (chroot) command changes the root directory to a specified directory, essentially switching the program's execution environment to a specified directory. After the switch, the old root directory structure and files will be inaccessible in the new execution environment. For example, the chroot command can switch from a ramfs environment to the root directory of a specified container.

[0098] System daemon (systemd): A process used to start applications and constrain the dependencies between applications before and after startup.

[0099] Application: Also known as a service, it is used to implement relatively independent functions. Different applications can communicate with each other through inter-process communication.

[0100] The following is an illustrative introduction to the application scenarios of the embodiments of the present application.

[0101] In related art, when a computing device is configured with multiple operating systems, each operating system typically includes a boot loader, a kernel, a root file system, and multiple application programs, etc. The boot loader, kernel, root file system, and multiple application programs of each operating system are stored in different partitions of the memory.

[0102] Since the architecture of multiple operating systems in related technologies is relatively simple, there is an urgent need to design a new architecture of multiple operating systems.

[0103] In view of this, an embodiment of the present application provides a computing device, in which a plurality of operating systems are stored in the memory of the computing device, such as a first operating system and a second operating system, the first operating system and the second operating system having a common boot loader and kernel, that is, the first operating system and the second operating system share the same boot loader and kernel, thereby reducing the boot loader and kernel of multiple operating systems, such as when there are M operating systems, at least M-1 boot loaders and M-1 kernels can be reduced. Therefore, the architecture of the multiple operating systems of the computing device, relative to the architecture in the related art, can not only simplify the architecture of the multiple operating systems, but also significantly reduce the storage space occupied by the multiple operating systems. In addition, since the first operating system and the second operating system have a common boot loader and kernel, if the second operating system needs to be started during the operation of the first operating system, the processor does not need to repeatedly run the boot loader and kernel, but can directly run the container of the second operating system. In this way, the time consumed in restarting the operating system can be significantly shortened, thereby helping to improve the efficiency of operating system startup, and further helping to improve the user experience.

[0104] The following is an exemplary introduction to the computing device provided in the embodiments of the present application.

[0105] FIG1 is a schematic diagram of a computing device provided in an embodiment of the present application. The computing device provided in an embodiment of the present application is exemplarily introduced below with reference to FIG1 .

[0106] The computing device provided in the embodiments of the present application may include at least one management unit. Each of the at least one management unit may include a processor and a memory. The memory of each management unit may store multiple operating systems.

[0107] It should be noted that in the embodiments of the present application, multiple can be two, or more than two, which will not be further described later.

[0108] Exemplarily, as shown in Figure 1, the at least one management unit may include a first management unit and a second management unit, wherein both the first management unit and the second management unit include a processor and a memory.

[0109] Exemplarily, the first management unit may be an in-band management unit. An in-band management unit is a unit used to implement in-band management, such as a central management unit. In-band management means that management data of a computing device and service data of a user are transmitted using the same physical channel.

[0110] Exemplarily, the second management unit may be an out-of-band management unit. An out-of-band management unit is a unit used to implement out-of-band management, such as a baseboard management controller (BMC). Out-of-band management refers to the transmission of management data of a computing device and business data of a user using different physical channels.

[0111] It should be noted that different computing devices have different names for BMC. For example, some computing devices call it BMC, some computing devices call it iLO, and others call it iDRAC. Regardless of whether it is called BMC, iLO, or iDRAC, it can be understood as the BMC in the embodiments of the present invention.

[0112] In an embodiment of the present application, each management unit may further include a read-only memory. The read-only memory stores a ROM boot program. The ROM boot program indicates the partition address of the boot loader in the memory. Based on this, when starting the operating system, the management unit can jump to running the boot loader based on the partition address indicated by the ROM boot program, and jump to running the kernel based on the partition address of the kernel indicated by the boot loader, thereby starting the boot loader and the kernel.

[0113] For example, the ROM may be embedded in the processor. The codes in the ROM may be the same for processors of the same model.

[0114] It should be noted that the computing device shown in FIG1 is only a structural diagram of a computing device applicable to the embodiment of the present application, and does not constitute a limitation on the computing device applicable to the embodiment of the present application.

[0115] Optionally, the computing device may include a network device or a terminal device.

[0116] Network devices may include servers, etc. A server may be a single physical or logical server, or may be two or more physical or logical servers sharing different responsibilities and working together to implement various server functions. For example, the server may be a blade server, a high-density server, a rack server, or a tower server.

[0117] Terminal devices may include augmented reality (AR) devices, virtual reality (VR) devices, personal digital assistants (PDAs), ultra-mobile personal computers (UMPCs), tablet computers, laptops, netbooks, desktop computers, all-in-one computers, etc.

[0118] It should be noted that the embodiments of the present application do not limit the form of the computing device, and the above is only an exemplary description.

[0119] The following is an exemplary introduction to the architecture of multiple operating systems configured on a computing device.

[0120] An embodiment of the present application provides an operating system, comprising a boot loader, a kernel, a container for a first operating system, and a container for a second operating system, wherein the first operating system and the second operating system have a common boot loader and kernel.

[0121] In this embodiment, by setting the first operating system and the second operating system to have a common boot loader and kernel, the boot programs and kernels of multiple operating systems are reduced. For example, when there are M operating systems, at least M-1 boot loaders and M-1 kernels can be reduced. Therefore, the architecture of the multiple operating systems, compared with the architecture form in the related art, not only simplifies the architecture of the multiple operating systems, but also can significantly reduce the storage space occupied by the multiple operating systems.

[0122] When the boot loader and kernel are used to boot a container running a first operating system, if a target event is detected, the container of the first operating system is switched to the container of the second operating system; when the boot loader and kernel are used to boot a container running a second operating system, if a target event is detected, the container of the second operating system is switched to the container of the first operating system.

[0123] In this embodiment, since the first operating system and the second operating system have a common boot loader and kernel, after the container of the first operating system is booted to run through the boot loader and kernel, if a target event is detected, that is, when the operating system needs to be switched, there is no need to boot the container of the operating system to be switched (that is, the container of the second operating system) through the boot loader and kernel, but it is possible to directly switch from the container of the first operating system to the container of the second operating system, thereby realizing the container of the second operating system. On this basis, in the process of running the container of the second operating system, if a target event is detected, there is still no need to boot the container of the operating system to be switched (that is, the container of the first operating system) through the boot loader and kernel, but it is possible to directly switch from the container of the second operating system to the container of the first operating system, thereby realizing the container of the first operating system. In this way, the time consumed by switching the operating system during the operation of the operating system can be significantly shortened, thereby helping to improve the efficiency of operating system switching, and then helping to improve the user experience.

[0124] FIG2 is an architectural diagram of a computing device according to an embodiment of the present application configured with the aforementioned multiple operating systems.

[0125] Exemplarily, the multiple operating systems may include a first operating system and a second operating system. The following uses the first operating system and the second operating system as examples to exemplify the architecture of the multiple operating systems.

[0126] In the embodiment of the present application, the first operating system and the second operating system have a common boot loader and kernel. In other words, the first operating system and the second operating system share the same boot loader and kernel. For example, the boot loader and kernel shown in FIG2 .

[0127] In the embodiment of the present application, the first operating system includes a container of the first operating system, such as the container of the first operating system shown in Figure 2. The second operating system includes a container of the second operating system, such as the container of the second operating system shown in Figure 2.

[0128] As shown in Figure 2, the container of the first operating system includes the root file system, system daemon process, and at least one application of the first operating system. The container of the second operating system includes the root file system, system daemon process, and at least one application of the second operating system.

[0129] It should be noted that in the embodiments of the present application, at least one can be one, or, can also be multiple, which will not be repeated later.

[0130] It should be noted that the embodiment of the present application does not limit the number of applications in each container. In addition, the applications in different containers can be the same or different, and the embodiment of the present application does not limit this.

[0131] In this embodiment, by configuring the container to include a root file system, a system daemon, and at least one application, on the one hand, by storing the container separately in a partition, the root file system, the system daemon, and the at least one application can be stored in the same partition. This helps reduce the number of memory partitions and thus the number of jumps during system startup. On the other hand, the root file system in the container can be used to implement the root directory of the device operating system. Based on this, the operating system application can be launched based on the system daemon and the at least one application, thereby enabling the operating system application to be launched through a single container.

[0132] In an embodiment of the present application, the kernel may include at least one of a switch, a switching configuration module, a jump machine, and an upgrade system.

[0133] The switcher can be used to provide operating system switching functionality, the jump machine can be used to provide jump functionality, the switch configuration module can be used to provide switch configuration functionality, and the upgrade system can be used to provide operating system upgrade functionality. The switch configuration functionality can refer to setting startup configuration parameters, which are used to indicate the container of the operating system to be switched.

[0134] FIG3 is a hierarchical diagram of an operating system after startup, provided by an embodiment of the present application.

[0135] 3 , the process of starting the operating system is exemplarily introduced by taking the BMC unit as an example.

[0136] As shown in Figure 3, the BMC unit consists of a hardware layer and a software layer. The software layer is the program code that runs on the hardware layer. The hardware layer includes the processor, ROM, and memory. The software layer includes the operating system (such as the boot loader, kernel, and file system). Users can use the file system in the software layer to access applications running on the computing device.

[0137] Note that in Figure 3, the container of the first operating system (hereinafter referred to as the first container) is represented by a solid line, indicating a running container. The container of the second operating system (hereinafter referred to as the second container) is represented by a dashed line, indicating a non-running container, or in a dormant state.

[0138] When the BMC unit is powered on, the processor of the BMC unit first runs the ROM boot program, and based on the partition address indicated by the ROM boot program (i.e., the partition address of the boot loader), runs the first operating system stored in the memory. Running the first operating system may include the following steps:

[0139] 1) Run the operating system's boot loader: Jump to the partition where the boot loader is located according to the partition address indicated by the ROM boot loader, load the boot loader into the specified memory address and run it. The specified memory address can be set at the factory. During the running of the boot loader, basic input and output (IO) configuration can be performed.

[0140] 2) Run the kernel: Based on the partition address indicated by the boot loader, jump to the partition where the kernel is located and load the kernel into the specified memory address to run. While running the kernel, you can configure and load driver devices, pull up the memory file system, etc.

[0141] Since the kernel in the embodiment of the present application includes a switch, a switching configuration module, a jump machine and an upgrade system, when a memory file system is generated based on the kernel, a memory file system can be generated through the switch, the switching configuration module, the jump machine and the upgrade system, so that the memory file system includes a switch, a switching configuration module, a jump machine and an upgrade system, and the memory file system can provide an operating system switching function, an operating system upgrade function, a jump function, a switching configuration function, a jump function, etc.

[0142] Since the memory file system is a system used to manage files during the operation of the operating system, it is in operation throughout the life cycle of the operating system. That is, as long as the operating system is not restarted or shut down, the memory file system will always exist. Based on this, by setting up the memory file system, it is possible to provide operating system switching functions, operating system upgrade functions, jump functions, switching configuration functions, jump functions, etc., so that operating system switching functions, operating system upgrade functions, jump functions, switching configuration functions, jump functions, etc. can be provided during the operation of the first operating system. This helps to improve the functional diversity of the operating system and thus helps to improve the user experience.

[0143] 3) Run the container: After pulling up the memory file system, jump to the partition where the container of the first operating system is located, mount the partition where the container of the first operating system is located, and mount the initial directory of the container of the first operating system as the root directory. That is, load the contents of the first container into the specified memory address for execution.

[0144] 4) Running an application: Starting at least one application in the container of the first operating system through the system daemon process in the container of the first operating system.

[0145] The above is an introduction to the architecture of the computing device provided in the embodiments of the present application, such as the architecture of multiple operating systems configured on the computing device. The following is an exemplary introduction to the functions that can be implemented by the computing device.

[0146] It should be noted that the following uses the BMC unit as an example to introduce the functions that can be implemented by the above computing device.

[0147] For example, one of the first operating system and the second operating system may be an operating system based on a BMC architecture (referred to as the BMC system), and the other operating system may be an operating system based on an OpenBMC architecture (referred to as the OpenBMC system). The following describes an embodiment of the present application by taking the BMC system as the first operating system and the OpenBMC system as the second operating system as an example.

[0148] In an embodiment of the present application, after the BMC unit is powered on, the processor can be used to run the boot loader based on the partition address indicated by the ROM boot program, and then run the kernel based on the partition address indicated by the boot loader. While the processor is running the kernel, the processor can generate a memory file system based on the kernel. Thereafter, the processor can also be used to run the container of the first operating system, thereby running the first operating system.

[0149] In one implementation, during the process of running a container of a first operating system, the processor can be used to switch from the container of the first operating system to the container of a second operating system when a target event is detected to run the container of the second operating system, thereby running the second operating system.

[0150] In this implementation, since the first operating system and the second operating system have a common boot loader and kernel, if the second operating system needs to be started during the operation of the first operating system, or in other words, it is necessary to switch from running the first operating system to running the second operating system, the processor does not need to repeatedly start the boot loader and kernel, but can directly run the container of the second operating system. In this way, the time consumed by restarting the operating system can be significantly shortened, thereby helping to improve the operating system startup efficiency, and further helping to improve the user experience.

[0151] In another implementation, during the process of running a container of a first operating system, the processor may be configured to re-run a boot loader and a kernel upon detecting a target event, thereby running a container of a second operating system.

[0152] In this implementation, when a target event is detected, the boot loader and kernel are re-run to switch to the container of the second operating system, thereby running the container of the second operating system. This restarts the completed operating system, helping to ensure the integrity of the operating system startup process and the stability and reliability of the operating system to be switched after startup.

[0153] The following is an exemplary introduction to the operating system switching function that can be implemented by the operating system with reference to FIG. 4 to FIG. 10 .

[0154] In an embodiment of the present application, a processor may be configured to switch from a container of a first operating system to a container of a second operating system upon detecting a target event. Specifically, the processor may be configured to jump from the container of the first operating system to an in-memory file system and determine the container to switch to the second operating system when the detected target event indicates an operating system switch. Thereafter, the processor may be configured to switch from the in-memory file system to the container of the second operating system.

[0155] It should be noted that the embodiment of the present application does not limit the execution order of "jumping from the container of the first operating system to the memory file system" and "determining to switch to the container of the second operating system".

[0156] In the embodiment of the present application, the target event may be a system switching request.

[0157] For example, when a user needs to switch the operating system running on the BMC unit, they send a system switch request to the processor via a terminal device to request the switch of the operating system running on the BMC unit. If the processor receives the system switch request while running the first operating system, it is considered that a target event has been detected, and the target event indicates that the operating system has been switched.

[0158] In this embodiment, by setting the target event to be a system switching request, the user can trigger the BMC unit to switch the operating system by sending a system switching request to the processor of the BMC unit. This not only helps to increase the diversity of the methods for triggering operating system switching, but also helps to improve the user experience.

[0159] In the embodiment of the present application, the target event may be completion of a system upgrade.

[0160] Exemplarily, when the processor of the BMC unit detects that an upgrade operation has been performed on a certain operating system (such as the second operating system), that is, when it detects that the system upgrade is completed, the processor jumps from the container running the first operating system to run the memory file system, and determines to switch to the container of the second operating system.

[0161] In one example, after the upgrade operation is completed on the second operating system, the processor may immediately jump from the container running the first operating system to the memory file system of the first operating system and determine to switch to the container of the second operating system.

[0162] In another example, the processor may jump from the first operating system container to the memory file system and determine to switch to the container of the second operating system after the upgrade operation is completed on the second operating system and a preset time has passed.

[0163] It should be noted that the embodiment of the present application does not limit the specific value of the preset duration, for example, it can be 5 seconds, 10 seconds, etc.

[0164] In yet another example, the processor may jump to running the memory file system from the container of the first operating system at a specified time after the upgrade operation is performed on the second operating system.

[0165] It should be noted that the embodiment of the present application does not limit the specific time point of the designated time. For example, the designated time can be 0:00, 1:00, etc. of the next day.

[0166] In this embodiment, the target event can be set to indicate that the system upgrade is complete. In this way, after the operating system upgrade is completed, the processor can automatically switch to the container of the upgraded operating system, thereby eliminating the need for the user to manually trigger the switching of the operating system. This not only helps to improve the convenience of system switching after the operating system upgrade, but also helps to improve the user experience.

[0167] It should be noted that the second operating system upgrade can be a container upgrade of the second operating system, or the entire operating system of the second operating system can be upgraded, wherein the entire operating system upgrade of the second operating system refers to the simultaneous upgrade of the boot record program, kernel, container, etc. of the second operating system, and the embodiments of the present application do not limit this.

[0168] For example, as shown in Figure 4, after detecting a target event, the processor can call a jumper in the in-memory file system to jump from the container of the first operating system to the in-memory file system, and call a switch configuration module in the in-memory file system to determine whether to switch to the container of the second operating system. The processor can then call a switcher in the in-memory file system to switch from the in-memory file system to the container of the second operating system, thereby running the second operating system.

[0169] In this embodiment, since the second operating system to be switched shares the same boot loader, kernel and memory file system with the currently running first operating system, when operating system switching is required, the processor of the BMC unit can directly jump to the container running the operating system to be switched from the memory file system without having to restart the boot loader and kernel, thereby achieving rapid startup of the operating system to be switched. In this way, the time consumed in switching the operating system can be significantly shortened, the efficiency of switching the operating system can be improved, and the user experience can be improved.

[0170] In an embodiment of the present application, the processor is configured to determine startup configuration parameters when a target event is detected, and write the startup configuration parameters into a storage medium of the computing device.

[0171] The startup configuration parameter is used to indicate the container of the operating system to be switched (hereinafter referred to as the container to be switched).

[0172] It should be noted that in the embodiments of the present application, the operating system to be switched, the container to be switched, etc. generally refer to the operating system to be switched, the container to be switched, etc., and do not specifically refer to a certain operating system, container, etc.

[0173] In the embodiment of the present application, after the processor of the BMC unit jumps from the container of the first operating system to run the memory file system, unlike in the related art, it does not jump to run the ROM boot program. Instead, it determines the startup configuration parameters during the process of running the memory file system and writes the startup configuration parameters to the storage medium of the computing device, so that the container of the operating system to be switched can be determined based on the startup configuration parameters. This helps to facilitate and accurately determine the container of the operating system to be switched.

[0174] Exemplarily, the processor may call a switching configuration module in the memory file system, determine the startup configuration parameters, and write the startup configuration parameters into a storage medium of the computing device.

[0175] In an embodiment of the present application, the startup configuration parameters may include a container identifier, which may be used to indicate the container of the operating system to be switched. Alternatively, the startup configuration parameters may include an operating system identifier, which may be used to indicate the operating system to be switched. Based on this, the processor may determine the container belonging to the operating system to be switched as the container to be switched.

[0176] It should be noted that the embodiment of the present application does not limit the form of the startup configuration parameters, and the above is only an exemplary description. The following takes the startup configuration parameters including the container identifier as an example to illustrate the embodiment of the present application.

[0177] There are many situations for containers whose operating systems are to be switched. The following provides an exemplary introduction through situations a to c.

[0178] Case a: The container whose operating system is to be switched is currently in a non-running state.

[0179] If the currently running operating system is the first operating system, the currently running container is the container of the first operating system. Based on this, the currently non-running container is the container of the second operating system. In other words, the container of the operating system to be switched is the container of the second operating system.

[0180] For example, in case a, after the processor of the BMC unit detects the target event, it can determine the container of the second operating system as the container of the operating system to be switched by starting the configuration parameters.

[0181] Case b: The container whose operating system is to be switched is currently in the running state.

[0182] When the currently running operating system is the first operating system, the currently running container is the container of the first operating system. In other words, the container of the operating system to be switched is the container of the first operating system.

[0183] For example, in case b, after the processor of the BMC unit detects the target event, it can determine the container of the first operating system as the container of the operating system to be switched by starting the configuration parameters.

[0184] Case c: The container of the operating system to be switched is a container of the first operating system or a container of the second operating system.

[0185] The BMC unit is pre-configured with a system switching policy, which may include switching to another operating system other than the current operating system or restarting the current operating system.

[0186] For example, the user can set the system switching policy to switch to another operating system other than the current operating system or restart the current operating system. In this way, after the BMC detects the target event, it can perform subsequent operations according to the system switching policy set by the user, such as determining the startup configuration parameters.

[0187] It should be noted that the embodiment of the present application does not limit the manner in which the user sets the system switching policy. For example, it may be by sending an instruction to the processor, or other methods may also be used.

[0188] The following describes the process of determining startup configuration parameters by taking case a as an example through methods 1 and 2.

[0189] Method 1: Determine the startup configuration parameters based on the identifier of the container of the first operating system.

[0190] In an embodiment of the present application, the processor of the BMC unit can determine the identifier of the container of the first operating system based on the obtained root directory path. Thereafter, the processor can determine the startup configuration parameters based on the identifier of the container of the first operating system.

[0191] Exemplarily, the root directory path may be / mnt / inittramfs / rofs1, where rofs1 is used to indicate the identifier of the container of the currently running operating system (that is, the identifier of the container of the first operating system).

[0192] It is understandable that since the root directory is unique, the currently existing root directory path is also unique.

[0193] In Example 1, the processor may determine the identifier of the container of the first operating system as a startup configuration parameter. Thus, when determining the container of the operating system to be switched, the processor may determine other containers other than the container indicated by the startup configuration parameter (i.e., other than the first container) as the container of the operating system to be switched. In other words, the processor may determine containers not indicated by the startup configuration parameter as the container of the operating system to be switched.

[0194] For example, if the root directory path is / mnt / inittramfs / rofs1, the processor may determine that rofs1 is a startup configuration parameter.

[0195] In this example, since the identifier of the container of the currently running operating system, that is, the identifier of the container of the first operating system, can be directly determined as the startup configuration parameter, this helps to improve the efficiency of determining the startup configuration parameter.

[0196] In Example 2, the processor can determine the identifier of the container of the second operating system as a startup configuration parameter, and can determine other containers other than the currently running container as startup configuration parameters. In other words, the processor can directly determine the identifier of the container of the operating system to be switched as the startup configuration parameter. In this way, when it is necessary to determine the container of the operating system to be switched, the computing device can determine the container indicated by the startup configuration parameter as the container of the operating system to be switched.

[0197] For example, if the root directory path is / mnt / inittramfs / rofs1, the BMC unit may determine rofs2 (ie, the identifier of the container of the second operating system) as the startup configuration parameter.

[0198] In this example, since the container indicated by the startup configuration parameter can be directly determined to be the container of the operating system to be switched, this helps to improve the efficiency of determining the container of the operating system to be switched.

[0199] Method 2: Determine the startup configuration parameters based on the target event.

[0200] In the embodiment of the present application, after the processor detects the target event, it can determine the startup configuration parameters according to the target event.

[0201] In one example, when the target event is a system switch request, the system switch request may include a container identifier (i.e., the identifier of the container of the operating system to be switched). After receiving the system switch request, the processor may determine the startup configuration parameters based on the container identifier in the system switch request. For example, the container identifier in the system switch request may be determined as the startup configuration parameters.

[0202] For example, as shown in (a) of FIG5 , a first interface is displayed on the user's terminal device, and the first interface includes a first control, wherein the first control is used to indicate a system switch. The user selects the first control and clicks the next control on the first interface. As shown in (b) of FIG5 , the terminal device displays a second interface in response to the user's operation, and the second interface includes a second control, and the second control is used to indicate a container. After the user selects the second container (i.e., the container of the operating system to be switched) on the second interface and clicks the next control on the second interface, the terminal device sends a system switch request to the processor of the BMC unit in response to the user's operation, and the system switch request includes an identifier of the second container.

[0203] It should be noted that the embodiment of the present application does not limit the number of second controls, and the above is only an exemplary description. For example, the number of second controls can be the same as the number of operating systems configured on the computing device, so that one second control indicates a container of one operating system.

[0204] In another example, when the target event is the completion of a system upgrade, the processor may determine the startup configuration parameters based on the container on which the system upgrade operation was performed in the most recent time period. For example, if the container on which the system upgrade operation was performed in the most recent time period is a container of the second operating system, the processor may determine the identifier of the container of the second operating system as the startup configuration parameters.

[0205] It should be noted that for other related instructions of Method 2, please refer to the instructions of Method 1 above, which will not be repeated here.

[0206] In an embodiment of the present application, the storage medium includes a volatile storage medium; the processor is used to write the startup configuration parameters into the storage medium of the computing device, specifically including: the processor is used to write the startup configuration parameters into the volatile storage medium when a first preset condition is met.

[0207] In the embodiment of the present application, the volatile storage medium may be the memory of the BMC unit, which helps to increase the speed of reading and writing the startup configuration parameters, thereby helping to improve the efficiency of operating system switching.

[0208] In an embodiment of the present application, after writing the startup configuration parameters to the volatile storage medium, the processor can unmount the partition where the container of the first operating system is located and unmount the root directory of the first operating system, thereby preparing for the subsequent running of the container of the second operating system, such as: directly switching from the memory file system to the container of the second operating system.

[0209] Since the BMC unit will not continue to jump to run the ROM boot program after jumping to the memory file system when the first preset condition is met, the BMC unit will not be powered off. Based on this, the startup configuration parameters are stored in the volatile storage medium. This not only ensures that the startup configuration parameters can be obtained, but also automatically clears the startup configuration parameters during the subsequent power-off process of the BMC unit, thereby preventing the startup configuration parameters from occupying storage space for a long time and affecting the normal system startup process.

[0210] In an embodiment of the present application, the storage medium also includes a non-volatile storage medium; the processor is used to write the startup configuration parameters into the storage medium of the computing device, specifically including: the processor is used to write the startup configuration parameters into the non-volatile storage medium when the first preset condition is not met.

[0211] In the embodiment of the present application, the non-volatile storage medium may include a raw partition on a storage device of a BMC unit, or a user flash memory (UFM) on a programmable logic device.

[0212] In one example, the BMC unit includes a storage device, such as an embedded multi-media card (EMMC), NAND flash memory (NANDFLASH), or NORFLASH, or universal flash storage (UFS). The BMC unit can divide part of the storage area of ​​the storage device into a raw partition (also called a raw device or raw partition), which can have no file system format. Based on this, when it is necessary to determine the container of the operating system to be switched, the processor can access the raw device through a fixed offset address of the raw device to obtain startup configuration parameters.

[0213] For example, referring to (a) in FIG6 , after the processor determines the container of the operating system to be switched, the identifier of the container of the operating system to be switched can be recorded as a startup configuration parameter in init-options (initialization options), and init-options can be written into the raw partition.

[0214] In another example, the BMC unit may include a programmable logic device, such as a complex programmable logic device (CPLD), a field programmable gate array (FPGA), etc. The editable logic includes a UFM storage space, where the UFM storage space refers to the flash memory storage space that can be used by the user. On this basis, when it is necessary to determine the container of the operating system to be switched, the processor can access the UFM storage space through the external access interface provided by the programmable logic device to obtain the startup configuration parameters.

[0215] For example, referring to (b) in FIG6 , after the processor determines the container of the operating system to be switched, the identifier of the container of the operating system to be switched can be recorded as a startup configuration parameter in init-options (initialization options), and the init-options can be written into the UFM storage space of the programmable logic device.

[0216] In this embodiment, when the first preset condition is not met, the startup configuration parameters are stored in a non-volatile storage medium. This helps avoid the loss of the startup configuration parameters when jumping to run the ROM boot program, thereby helping to ensure the smooth execution of the operating system switching process.

[0217] In this embodiment of the present application, satisfying the first preset condition may include: the closing operation of multiple applications in the container of the first operating system meeting the target condition, and / or the target event indicating a container switch. Container switch indicates switching to the container of the operating system to be switched during a system switch.

[0218] In this embodiment, when the closing operations of multiple applications meet the target conditions, it is determined that the first preset condition is met, that is, directly switching from the currently running memory file system to the container of the second operating system. In this way, by setting appropriate target conditions, it not only helps to avoid the crash of multiple applications and affect the stability of the currently running operating system, but also helps to avoid the subsequent switching of multiple applications of the first operating system to the applications of the second operating system.

[0219] In addition, by setting the target event to indicate container switching, it is determined that the first preset condition is satisfied. This helps to improve the correlation between the target event and the system switching mode, thereby helping to ensure the reliability and accuracy of the system switching mode.

[0220] The following describes how to determine whether the first preset condition is met through cases a to c.

[0221] Case a: Based on the closing operations of multiple application programs, it is determined whether a first preset condition is satisfied.

[0222] When a target event is detected during the process of running the container of the first operating system, the processor performs a closing operation on multiple applications in the container of the first operating system to close the multiple currently running applications.

[0223] On this basis, if the closing operations of the multiple application programs meet the target condition, it is determined that the first preset condition is met. If the closing operations of the multiple application programs do not meet the target condition, it is determined that the first preset condition is not met.

[0224] In this embodiment, setting appropriate target conditions not only helps to avoid the crash of multiple applications causing the crash of the first operating system, but also helps to prevent the applications of the first operating system from affecting the normal operation of the applications of the second operating system that are subsequently started.

[0225] In an embodiment of the present application, the closing operations of multiple applications meet the target conditions, including: multiple applications are closed successfully, and / or the closing order of the multiple applications is opposite to the startup order of the multiple applications.

[0226] In this embodiment, by setting each of the multiple applications to be closed successfully, it is possible to avoid the application of the first operating system affecting the normal operation of the application of the second operating system that is subsequently started. Setting the closing order of the multiple applications to be opposite to the starting order of the multiple applications helps to avoid the crash of the first operating system caused by the crash of multiple applications.

[0227] The startup sequence of multiple applications refers to the startup sequence of multiple applications in the most recent time period.

[0228] For example, at the first moment, the startup order of multiple applications is sequence 1, and at the second moment, the startup order of multiple applications is sequence 2. The second moment is later than the first moment, and sequence 1 is different from sequence 2, then sequence 2 is the startup order in the most recent time period.

[0229] The following is an exemplary description of the process of closing multiple applications with reference to FIG7 .

[0230] For example, as shown in FIG7 , when the processor of the BMC unit starts the first operating system, it sequentially runs the boot loader, kernel, and memory file system of the first operating system. Subsequently, the processor starts launching multiple applications in the container of the first operating system. During the process of launching multiple applications in the container of the first operating system, the BMC unit records the startup order of the multiple applications. This startup order can be used to indicate the dependencies between different applications.

[0231] For example, the processor may sequentially launch application 1, application 2, ..., and application N. Subsequently, while running multiple applications, the processor may shut down or restart some of them. During the restart of some applications, the processor may update the previously recorded startup order of the multiple applications. For example, the startup order of the multiple applications in the recent period may be 1, 3, ..., N, 2.

[0232] Based on this, after detecting the target event, the processor executes a shutdown operation on the multiple applications to close the multiple running applications. When executing the shutdown operation on the multiple applications, if the processor closes the multiple applications in the order of 2, N, ..., 3, 1, the closing order of the multiple applications is the opposite of the order in which the multiple applications were started.

[0233] Exemplarily, after the processor performs a close operation on an application, it can receive a return value that can be used to indicate whether the application is successfully closed. In this way, the processor can determine whether the application is successfully closed based on the return value.

[0234] In the embodiments of the present application, when the processor starts running multiple applications, it will start them sequentially from the inside out according to the dependency relationships between the multiple applications. For example, the operation of application 1 depends on application 2. In other words, application 1 cannot run independently and can only run normally when application 2 is running. In this case, application 1 and application 2 have a dependency relationship, and application 1 depends on application 2. In this case, application 2 is in the inner position of the dependency relationship, and application 1 is in the outer position of the application relationship.

[0235] Based on this, when application 1 and application 2 need to be started, the processor starts application 2 first, and then starts application 1. When closing application 1 and application 2, application 1 is closed first, and then application 2. This helps to avoid application 1 crashing.

[0236] On this basis, when the processor performs a closing operation on multiple applications, if the closing order of multiple applications is opposite to the startup order of multiple applications, it means that the closing operation is carried out from the outside to the inside according to the dependency relationship between the multiple applications. This helps to avoid the crash of applications that have not been closed.

[0237] In the embodiment of the present application, when executing the closing operation on multiple applications, the interval between the closing operations of two adjacent applications is greater than 0. This helps to ensure that different applications can be closed serially.

[0238] Exemplarily, the closing order of the applications includes application 1 and application 2. Based on this, the processor performs a closing operation on application 1 at time 1 and performs a closing operation on application 2 at time 2, wherein the difference between time 1 and time 2 is greater than 0.

[0239] Case b: Based on the system switching type indicated by the target event and the closing operations of the multiple application programs, it is determined whether the first preset condition is met.

[0240] In the embodiment of the present application, the system switching type may include container switching or non-container switching. Container switching may also be called fast switching, and non-container switching may also be called full switching or full partition switching.

[0241] Container switching is used to indicate that the container of the operating system to be switched is running during the system switching process. In other words, the boot loader and kernel are not re-run. Exemplarily, the path of container switching is: container of the current operating system (i.e., container of the first operating system) → memory file system → container of the operating system to be switched.

[0242] Non-container switching refers to the container running the boot loader, kernel, and the operating system to be switched during the system switching process. For example, the path for non-container switching is: container of the current operating system → in-memory file system → ROM boot loader → boot loader → kernel → in-memory file system → container of the operating system to be switched.

[0243] The following is an exemplary introduction on how to determine the system switching type when the target event is a system switching request.

[0244] For example, the system switching request indicates the switching type. The BMC unit can determine whether the system switching type is a container switching based on the switching type indicated by the system switching request. In this way, whether it is a container switching can be determined based on the switching type indicated by the user, which helps to improve the user experience.

[0245] Exemplarily, the system switching request includes a switching identifier, which indicates a switching type. If the switching identifier indicates a container switching, the system switching type is determined to be a container switching; if the switching identifier indicates a non-container switching, the system switching type is determined to be a non-container switching.

[0246] The following is an exemplary introduction to how to determine the system switching type when the target event is system upgrade completion.

[0247] In one example, if the system upgrade type is container upgrade, then the system switch type is determined to be container switch. Container upgrade is used to indicate that a single container of the operating system is upgraded during the system upgrade process, that is, the boot loader and kernel are not upgraded.

[0248] The BMC can check the system upgrade type in the log. If the log records that only the container was upgraded during the most recent operating system upgrade (that is, the boot loader and kernel were not upgraded), the system upgrade type is determined to be a container upgrade. If the log records that the boot loader, kernel, and container were upgraded during the most recent operating system upgrade, the system upgrade type is determined to be a non-container upgrade.

[0249] In another example, if the target event is system upgrade completion, the system switch type is determined to be container switch. That is, regardless of whether the system upgrade type is container upgrade, as long as the target event is system upgrade completion, the system switch type is determined to be container switch.

[0250] In yet another example, if the target event is system upgrade completion, the system switch type is non-container switch.

[0251] Based on the above, in this embodiment of the present application, if the system switching type indicated by the target event is a container switching, and the closing operations of multiple applications meet the target condition, then the first preset condition is determined to be satisfied. If the system switching type indicated by the target event is not a container switching, or the closing operations of multiple applications do not meet the target condition, then the first preset condition is determined to be unsatisfied.

[0252] It should be noted that for other relevant explanations of situation b, please refer to the above situation a, which will not be repeated here.

[0253] Case c: Based on the system switching type indicated by the target event, it is determined whether a first preset condition is met.

[0254] It should be noted that for the relevant explanation of situation c, please refer to situation b, which will not be repeated here.

[0255] The following describes, through methods A and B, a process of determining a container for switching an operating system.

[0256] Method A: Determine the container to switch the operating system based on the startup configuration parameters.

[0257] In an embodiment of the present application, a processor is configured to determine a container to switch to a second operating system, including: the processor is configured to obtain startup configuration parameters from a storage medium, and determine the container to switch to the second operating system based on the startup configuration parameters. In other words, determining that the container to be switched to is a container for the second operating system.

[0258] Exemplarily, the processor may determine the container to be switched (i.e., the container of the operating system to be switched) based on the startup configuration parameters and the startup correspondence. The startup correspondence may include a correspondence between the startup configuration parameters and the identifier of the container to be switched.

[0259] In example 1, the startup correspondence relationship may include that when the startup configuration parameter is the first identifier, the second identifier corresponds to the first identifier. That is, when the startup configuration parameter is the first identifier, the container to which the second identifier belongs is determined to be the container to be switched.

[0260] Example 2: The startup correspondence relationship may include that when the startup configuration parameter is the second identifier, the second identifier corresponds to the second identifier. That is, when the startup configuration parameter is the second identifier, the container to which the second identifier belongs is determined to be the container to be switched.

[0261] Example 3: The startup correspondence relationship may include a first identifier corresponding to when the startup configuration parameter is empty. That is, when the startup configuration parameter is empty, it is determined that the container to which the first identifier belongs is the container to be switched.

[0262] In an embodiment of the present application, when it is determined that the first preset condition is met, the processor may obtain the startup configuration parameters from the volatile storage medium to determine the container of the operating system to be switched.

[0263] In the first example, the container identifier is the identifier of the first container (i.e., the container of the first operating system). After the processor obtains the startup configuration parameters (i.e., the identifier of the first container), it can determine that another container other than the first container (i.e., the container of the second operating system) is the container of the operating system to be switched.

[0264] In the second example, the container identifier is the identifier of the container to be switched (i.e., the container of the operating system to be switched). After the processor obtains the startup configuration parameter (i.e., the identifier of the second container), it can directly determine that the container to which the second container identifier belongs is the container of the operating system to be switched. In other words, it determines that the container of the second operating system is the container of the operating system to be switched.

[0265] It should be noted that when the BMC unit of the computing device is configured with only two operating systems, the container of the operating system to be switched can be determined based on the methods of the first and second examples above. When the computing device is configured with more than two operating systems, the container of the operating system to be switched can be determined based on the method of the second example above.

[0266] In this implementation, the container of the operating system to be switched is determined by pre-writing the startup configuration parameters into the storage medium. In this way, the user no longer needs to specify the container of the operating system to be switched, which helps to improve the user experience and the convenience and automation of operating system switching.

[0267] Method B: Determine the container to switch the operating system based on the target event.

[0268] In the embodiment of the present application, when the startup configuration parameters are determined according to the identifier of the first container, the container of the operating system to be switched may also be determined according to the target event.

[0269] When the target event is a system switching request, the system switching request may include a container identifier. Based on this, the processor may determine that the container corresponding to the container identifier in the system switching request is the container of the operating system to be switched.

[0270] It should be noted that for the description of determining the container of the operating system to be switched based on the container identifier in the system switching request, reference may be made to the description of FIG. 5 in the above-mentioned method 1, which will not be repeated here.

[0271] When the target event is system upgrade completion, the processor can determine that the container performing the upgrade operation is the container of the operating system to be switched. This helps improve the accuracy and efficiency of determining the container of the operating system to be switched.

[0272] Exemplarily, the second operating system performs an upgrade operation. Based on this, the BMC unit may determine that the container of the second operating system is the container of the operating system to be switched.

[0273] In this implementation, the container of the operating system to be switched is determined by the target event, which helps to improve the correlation between the operating system to be switched that is finally started and the target event, thereby helping to improve the accuracy of the switched operating system.

[0274] In an embodiment of the present application, the processor is configured to switch from the memory file system to the container of the second operating system, including: the processor is configured to switch from the memory file system to the container of the second operating system when a first preset condition is met.

[0275] Exemplarily, the processor jumps from the container of the first operating system to the memory file system by calling a jump machine in the memory file system. The jump machine includes a first jump module and a second jump module. The first jump module includes jumping from the container to the memory file system, and the second jump module includes jumping from the container to the memory file system and jumping from the memory file system to the ROM boot program.

[0276] When the first preset condition is met, the processor calls the first jump module to implement a jump from the container of the first operating system to the memory file system. Instead of continuing to jump to the ROM boot program, the processor can switch from the memory file system to the container of the second operating system by calling the switch in the memory file system.

[0277] It can be understood that since the first jump module does not include the step of jumping from the memory file system to the ROM boot program, when the processor calls the first jump module, after jumping from the container of the first operating system to the memory file system, it will not continue to jump to the ROM boot program, that is, the original jump path to the ROM is cut off.

[0278] In this embodiment, by setting the switch from the direct memory file system to the container of the operating system to be switched (i.e., the container of the second operating system) only when the first preset condition is met, by setting an appropriate first preset condition, it helps to improve the stability and reliability of the operating system to be switched after it is started.

[0279] In an embodiment of the present application, switching to the second container (i.e., the container of the second operating system) may include: mounting the partition of the second container, that is, loading the second container into the memory of the BMC unit for execution. Setting the initial directory of the second container to the root directory, that is, setting it to the root directory of the second operating system. Thereafter, jumping to the root directory of the second operating system through chroot, and sequentially starting multiple applications in the second container through the system daemon process in the second container.

[0280] In an embodiment of the present application, during the process of running a container of a second operating system, the processor can be configured to, upon detecting the occurrence of a target event, jump from the container of the second operating system to run the in-memory file system and determine that the container of the first operating system is the container of the operating system to be started. The processor can then be configured to jump from the in-memory file system to run the container of the first operating system, thereby running the first operating system.

[0281] In this embodiment, while the second operating system is running, if the processor detects the occurrence of a target event again, the computing device can perform an operating system switching operation again to switch from the second operating system container to the first operating system container, thereby continuing to run the first operating system. Because the switch from one operating system container to another can be made directly through the in-memory file system, the efficiency of operating system switching during the operation of the computing device is significantly improved.

[0282] In an embodiment of the present application, the processor can be used to re-run the boot loader and the kernel when a target event is detected, thereby running the container of the second operating system, specifically including: the processor can be used to re-run the boot loader and the kernel when a first preset condition is not met, thereby running the container of the second operating system.

[0283] After the processor detects a target event, if the first preset condition is not met, the processor writes the startup configuration parameters to a non-volatile storage medium. After jumping from the container of the first operating system to the memory file system, the processor continues to jump from the memory file system to the ROM boot program. When jumping to the ROM boot program, the memory file system previously generated based on the kernel is closed. The processor then runs the boot loader and the kernel in sequence based on the ROM boot program. While running the kernel, the processor regenerates the memory file system based on the kernel.

[0284] Exemplarily, if the first preset condition is not met, the processor calls the second jump module, thereby implementing a jump from the container of the first operating system to the memory file system, and then continuing to jump to the ROM boot program. Because the second jump module includes the steps of jumping from the container to the memory file system and jumping from the memory file system to the ROM boot program, the processor can also jump from the memory file system to the ROM boot program when calling the second jump module.

[0285] In one example, during the execution of the memory file system, the processor may obtain startup configuration parameters from the non-volatile storage medium, and determine, based on the startup configuration parameters, that the container of the operating system to be switched is a container of the second operating system.

[0286] In another example, during the running of the memory file system, the processor may determine that the container of the operating system to be switched is the container of the second operating system based on the user selecting the container of the second operating system on the operating system selection interface.

[0287] It should be noted that the operating system selection interface will be described in subsequent embodiments and will not be described in detail here.

[0288] On this basis, after determining that the container of the operating system to be switched is the container of the second operating system, the processor switches from the regenerated memory file system to the container of the second operating system to run the container of the second operating system, thereby realizing the operation of the second operating system.

[0289] In this embodiment, by setting a jump to running the ROM boot program when the first preset condition is not met, and restarting the boot loader, the kernel and the container of the operating system to be switched, a variety of different system switching methods are provided to the user. This not only helps to increase the diversity of operating system switching methods, thereby realizing the selection of a suitable operating system switching method for operating system switching according to actual scenarios, but also helps to improve the stability and reliability of the operating system to be switched after startup, thereby helping to improve the user experience.

[0290] In an embodiment of the present application, a processor is configured to run a boot loader and a kernel, including: upon power-up, the processor is configured to, based on a ROM boot program instructing the boot loader, run the boot loader and the kernel, and generate a memory file system. The processor is then configured to determine a container for starting a first operating system and to switch from the memory file system to the container for the first operating system.

[0291] 8 , the process of starting the operating system when the BMC unit is powered on is exemplarily introduced below.

[0292] As shown in Figure 8, the operating system boot process can apply to the system initialization scenario, that is, the operating system boot scenario when the BMC unit is powered on, such as the first power-on or power-on after a power outage. After the BMC unit is powered on by alternating current (AC), the processor runs the boot loader, kernel, and memory file system in sequence based on the partition address indicated by the ROM boot program, and mounts the read-write file system (RWFS) shared by different containers.

[0293] In one example, after running the memory file system, the processor may obtain startup configuration parameters from the non-volatile storage and determine the container of the operating system to be started according to the startup configuration parameters.

[0294] Exemplarily, the startup correspondence may include that when the startup configuration parameter is the identifier of the first container (i.e., the container of the first operating system) or is null (NULL), the first container is the container to be started. When the startup configuration parameter is the identifier of the second container (i.e., the container of the second operating system), the second container is the container to be started.

[0295] Because the startup configuration parameters are written to the storage medium when the target event is detected, the startup configuration parameters are not written to the storage medium when the BMC unit is powered on for the first time, or when it is powered on again after a power outage. Therefore, the startup configuration parameters obtained by the processor are empty (NULL). Therefore, the processor determines that the first container is the container of the operating system to be started.

[0296] In this example, by setting the startup configuration parameters to be obtained from the non-volatile storage medium when the operating system is started at power-on, the path for obtaining the startup configuration parameters is the same when the operating system is started at power-on and when the operating system is switched when the first preset condition is not met, thereby helping to reduce the path for obtaining the startup configuration parameters and further helping to simplify the operating system startup procedure.

[0297] In another example, after running the memory file system, the processor may determine that the default container is the container of the operating system to be started, or determine that the container selected by the user on the operating system selection interface is the container of the operating system to be started.

[0298] Afterwards, the processor can jump to the root directory environment through chroot, such as: when the startup configuration parameter is empty, jump to the root directory corresponding to the initial directory of the first container, and start multiple applications in the first container through the system daemon process in the first container.

[0299] In an embodiment of the present application, when the BMC unit is powered on, the processor determines the container of the operating system to be started after running the boot loader, the kernel, and the memory file system in sequence based on the ROM boot program. This helps to ensure the uniformity of the system startup process and the system switching process when the computing device is powered on, thereby helping to improve the scope of application of the system switching process, so that the operating system switching process is applicable to both system startup at power-on and system startup when the operating system is switched.

[0300] As shown in FIG9 , it is a schematic diagram of a principle of operating system switching provided in an embodiment of the present application.

[0301] Exemplarily, after the BMC unit is powered on, the processor runs the ROM boot program and, based on the partition address indicated by the ROM boot program, boots the loader and kernel in sequence. During the kernel execution, the memory file system is pulled up. Subsequently, the processor starts the first process, init, and runs the container of the first operating system (i.e., the first container) through chroot, as shown by the solid line with an arrow in FIG9 . For example, running the first container may include mounting the partition where the first container is located, setting the initial directory of the first container as the root directory, and running application 1, application 2, ..., application M, etc. in the first container through the first system daemon process in the first container, where M is a positive integer greater than 2.

[0302] On this basis, if the processor detects a target event and satisfies a first preset condition, the processor invokes a jumper in the memory file system to jump from the first container to the memory file system. Since the jumper interrupts the step of jumping to the ROM boot program when the first preset condition is met, the processor does not jump to run the ROM boot program, but instead determines to switch to the container of the second operating system (i.e., the second container) by invoking the switching configuration module. Afterwards, the processor invokes a switch in the memory file system to switch from the memory file system to the second container, and restarts (reboots) the first process init, and runs the second container through chroot, as shown by the dotted arrow in FIG9 . For example, running the second container may include mounting the partition where the second container is located, setting the initial directory of the second container as the root directory, and running application 1, application 2, ..., application N in the second container through the second system daemon process in the second container, where N is a positive integer greater than 2.

[0303] Based on the above, after the first operating system is started, when switching to the second operating system, the process involving the transfer of permissions to process number one may include: boot loader → kernel → init → container of the first operating system → reboot init → container of the second operating system. It can be seen that the entire operating system switching process does not require restarting the boot loader and kernel.

[0304] As shown in Figure 10, which is a schematic diagram of an operating system switching provided in an embodiment of the present application, the operating system switching process provided in an embodiment of the present application is exemplarily described below with reference to Figure 10.

[0305] For example, when the processor of the BMC unit is running a container (also called the original container) of a first operating system, a user triggers a target event, such as triggering a system upgrade or system switch. After detecting the target event, the BMC unit executes a shutdown operation on multiple applications in the container of the first operating system to close the multiple applications in the container of the first operating system. The processor then determines whether a first preset condition is met. If so, the processor executes the container startup process; if not, the processor executes the non-container startup process (i.e., the full startup process).

[0306] If the processor executes the container startup process, after jumping from the first operating system's container to run the in-memory file system, the processor does not jump to running the ROM bootloader, but instead remains at the stage of running the in-memory file system. During the in-memory file system execution, the BMC writes the startup configuration parameters to the volatile storage medium and unmounts the first operating system's root directory and the partition containing the first operating system's container.

[0307] If a full boot process is executed, the processor jumps from the first operating system container to run the in-memory file system. While running the in-memory file system, the processor writes the boot configuration parameters to the non-volatile storage medium and continues to jump to the ROM boot program. Then, based on the partition address indicated by the ROM boot program, the processor runs the boot loader, kernel, and in-memory file system.

[0308] The processor then retrieves startup configuration parameters. If the process is a container startup, the processor retrieves the startup configuration parameters from a volatile storage medium. If the process is a non-container startup, the processor retrieves the startup configuration parameters from a non-volatile storage medium. Based on the startup configuration parameters, the processor determines the container to which the operating system is to be switched.

[0309] For example, if the startup configuration parameter is the identifier of the first container or NULL, and the first container is the container of the operating system to be switched, the partition corresponding to the first container is mounted, and the initial directory of the first container is mounted as the root directory. If the startup configuration parameter is the identifier of the second container, and the second container is the container of the operating system to be switched, the partition corresponding to the second container is mounted, and the initial directory of the second container is mounted as the root directory.

[0310] Afterwards, the processor jumps to the root directory environment through chroot. For example, if the startup configuration parameter indicates the identifier of the second container, the processor jumps to the root directory corresponding to the initial directory of the second container and starts multiple applications in the second container through the system daemon process in the second container.

[0311] The following is an exemplary introduction to the operating system upgrade function that can be implemented by the operating system with reference to FIG11 to FIG16.

[0312] For example, when a user needs to upgrade the operating system of a BMC unit, they can send a system upgrade request to the processor of the BMC unit through a terminal device to request the upgrade of the operating system of the BMC unit. If the processor receives the system upgrade request while running the first operating system, it is considered that a target event has been detected, and the target event indicates that an operating system upgrade is required.

[0313] Exemplarily, the system upgrade request may be a request to upgrade the BMC operating system to the OpenBMC operating system, or a request to upgrade the current version of the BMC operating system to a new version of the BMC operating system, or a request to upgrade the current version of the OpenBMC operating system to a new version of the OpenBMC operating system. This embodiment of the present application does not limit this.

[0314] In an embodiment of the present application, the processor may be configured to, when the detected target event indicates an operating system upgrade, determine a container for the operating system to be upgraded. The processor may then be configured to perform the upgrade operation on the container for the operating system to be upgraded, without performing the upgrade operation on the boot loader and / or kernel.

[0315] It should be noted that the operating system to be upgraded can be the operating system currently running on the computing device (i.e., the first operating system), or it can be an operating system other than the operating system currently running on the computing device (i.e., the second operating system). This embodiment of the present application does not limit this.

[0316] In the embodiment of the present application, the processor performs an upgrade operation on the container of the operating system to be upgraded, and may perform an upgrade operation on the partition where the container of the operating system to be upgraded is located.

[0317] For example, performing an upgrade operation on the partition where the container of the operating system to be upgraded is located can be performed by using the upgrade package of the operating system to be upgraded to refresh the partition where the container of the operating system to be upgraded (i.e., the container to be upgraded) is located (i.e., the partition to be upgraded). For example, refreshing the root file system, system daemon, and at least one application of the container to be upgraded.

[0318] Exemplarily, as shown in FIG11 , the processor may perform an upgrade operation on the container of the operating system to be upgraded by calling an upgrade system in the memory file system.

[0319] It should be noted that regarding the method of obtaining the upgrade package of the operating system to be upgraded, reference can be made to the acquisition method in the relevant technology, and the embodiments of the present application do not limit this.

[0320] In this embodiment, since the upgrade operation is not performed on the boot loader and / or kernel of the operating system to be upgraded during the operating system upgrade process, the number of partitions performing the upgrade operation is reduced, thereby shortening the time consumed by the operating system upgrade, improving the efficiency of the system upgrade, and further improving the user experience.

[0321] In an embodiment of the present application, the processor may be configured to determine a container of the operating system to be upgraded when the detected target event indicates upgrading the operating system. Specifically, the processor may be configured to determine a container of the operating system to be upgraded when the detected target event indicates upgrading the operating system and a second preset condition is met.

[0322] In this embodiment, by setting the second preset condition to be met, the container of the operating system to be upgraded is determined, so that only the container of the operating system to be upgraded is included. In this way, by setting an appropriate second preset condition, it helps to ensure the stability and reliability of the operating system after upgrading a single container.

[0323] In an embodiment of the present application, satisfying the second preset condition may include: the target event indicates a container upgrade, the version of the operating system to be upgraded is higher than or equal to the compatible version of the upgrade package of the operating system to be upgraded, and the versions of the currently running boot loader and kernel are the latest versions.

[0324] Hereinafter, how to determine whether the second preset condition is satisfied is exemplified through methods A to C.

[0325] Method A: Based on the upgrade type indicated by the system upgrade request, determine whether the second preset condition is met.

[0326] If the system upgrade request indicates a container upgrade, the second preset condition is met. If the system upgrade request indicates a non-container upgrade, the second preset condition is not met.

[0327] In this embodiment of the present application, the system upgrade types include container upgrade and non-container upgrade. Among them, container upgrade is used to indicate that only a single container of the operating system is upgraded, and non-container upgrade is used to indicate that the boot loader, kernel, and container of the operating system are upgraded, that is, all partitions of the operating system are upgraded.

[0328] It should be noted that container upgrade can also be called fast upgrade, and non-container upgrade can also be called full upgrade or full partition upgrade.

[0329] In the embodiment of the present application, the system upgrade request may include a type identifier, which is used to indicate the upgrade type.

[0330] For example, as shown in FIG12 , a user's terminal device displays a third interface, which includes a third control for indicating an upgrade type. The user selects a system upgrade type indicated by the third control and then clicks the Next control on the third interface. In response to the user's operation, the terminal device sends a system upgrade request to the processor. The system upgrade request includes a type identifier for indicating the system upgrade type selected by the user.

[0331] For example, if the user selects a container upgrade, the system upgrade request may include a container upgrade type identifier. If the user selects a non-container upgrade, the system upgrade request may include a non-container upgrade type identifier.

[0332] It should be noted that for other related descriptions of FIG12 , reference can be made to the description of FIG5 , which will not be repeated here.

[0333] Method B: Determine whether the second preset condition is met based on the compatible versions of the operating system to be upgraded and the upgrade package of the operating system to be upgraded.

[0334] If the version of the operating system to be upgraded is higher than or equal to the compatible version, it is determined that the second preset condition is met. If the version of the operating system to be upgraded is lower than the compatible version, it is determined that the second preset condition is not met.

[0335] In an embodiment of the present application, after receiving a system upgrade request, the processor of the BMC unit determines the container of the operating system to be upgraded, and then determines the compatible version indicated by the upgrade package of the operating system to be upgraded. The compatible version indicated by the upgrade package can be considered as the operating system version with which the upgraded operating system is compatible. If the version of the operating system to be upgraded is higher than or equal to the compatible version indicated by the upgrade package, it is determined that the second preset condition is met. In this way, the upgraded operating system is compatible with the boot loader and kernel of the BMC unit, and therefore, only the operating system container can be upgraded.

[0336] For example, if the compatible version indicated by the upgrade package is version 5, and the version of the operating system to be upgraded is version 5 or higher (such as version 6, version 7, etc.), the version of the operating system to be upgraded is higher than the compatible version indicated by the upgrade package.

[0337] It should be noted that regarding how to determine the compatible version indicated by the upgrade package and the version of the currently running operating system, you can refer to the methods in the relevant technology, and the embodiments of this application do not limit this.

[0338] It should be noted that one operating system is compatible with another operating system, which can be considered as the code of one operating system including the code of the other operating system.

[0339] In this embodiment of the present application, the above-mentioned method A and method B can be used in combination. When using method A and method B in combination, if the system upgrade request indicates a container upgrade and the version of the operating system to be upgraded is higher than or equal to the compatible version indicated by the upgrade package, then it is determined that the second preset condition is met. If the system upgrade request indicates a non-container upgrade, or the version of the operating system to be upgraded is lower than the compatible version indicated by the upgrade package, then it is determined that the second preset condition is not met.

[0340] Method C: Based on the currently running boot loader and kernel, determine whether the second preset condition is met.

[0341] Example 1: If the currently running boot loader and kernel are the latest versions (also called the highest versions), it is determined that the second preset condition is met. If the currently running boot loader and / or kernel are not the latest versions, it is determined that the second preset condition is not met.

[0342] For example, the BMC unit can determine whether the currently running boot loader and kernel are the latest versions by comparing the version of the currently running operating system with the version of the upgrade package. If the version of the currently running operating system and the version of the upgrade package are the same, it can be determined that the currently running boot loader and kernel are the latest versions. Otherwise, it can be determined that the currently running boot loader and kernel are not the latest versions.

[0343] Example 2: If the versions of the currently running boot loader and kernel are higher than or equal to the version of the upgrade package, it is determined that the second preset condition is met. If the versions of the currently running boot loader and kernel are lower than the version of the upgrade package, it is determined that the second preset condition is not met.

[0344] It should be noted that for the relevant description of Example 2, please refer to the description of Example 1 above, and no further details will be given here.

[0345] In this method, when multiple operating systems share the same boot loader and kernel, by determining that the currently running boot loader and kernel are the latest versions, the second preset condition is met, so that only the container of the operating system to be upgraded is upgraded. This helps to ensure that the upgraded container is compatible with the currently running boot loader and kernel, thereby helping to ensure the stability and reliability of the upgraded operating system.

[0346] It should be noted that the above-mentioned methods A to C can be used alone or in combination, and the embodiments of the present application do not limit this.

[0347] As shown in FIG13 , it is a schematic diagram of an operating system upgrade provided in an embodiment of the present application.

[0348] Exemplarily, after the BMC unit is powered on, the processor runs the ROM boot program and, based on the partition address indicated by the ROM boot program, boots the loader and kernel in sequence. During kernel execution, the memory file system is pulled up. The BMC unit then starts process #1 (init) and runs the first container (i.e., the container of the first operating system) via chroot, as shown in the solid arrowed portion of Figure 13. For example, running the first container can include mounting the partition where the first container resides, setting the initial directory of the first container as the root directory, and running application 1, application 2, and so on, and upgrading applications in the first container through the system daemon process in the first container.

[0349] On this basis, if the user needs to upgrade the operating system, for example, the user sends a system upgrade request to the processor through the terminal device, and indicates that the system upgrade type is a container upgrade. After receiving the system upgrade request, the processor determines that the second container (i.e., the container of the second operating system) is the container of the operating system to be upgraded, and calls the upgrade system in the memory file system. Through the upgrade application in the first container, based on the container upgrade path, the upgrade operation is performed on the second container, see "①" in Figure 13.

[0350] After performing the upgrade operation on the second container, the processor may restart the upgraded second container. Specifically, the BMC unit may invoke a switch in the memory file system to directly switch from the memory file system to the container of the second operating system, restart the first init process, and run the second container through chroot (see "② and ③, and the dashed portion in the second container" in Figure 13). For example, running the second container may include mounting the partition where the second container resides, setting the initial directory of the second container as the root directory, and running application 1, application 2, ..., application N in the second container through the system daemon process in the second container, where N is a positive integer greater than 2.

[0351] Based on the above, after the operating system is booted, when upgrading the operating system, the process involving the transfer of permissions to process number one may include: boot loader → kernel → init → container for the first operating system → reboot init → container for the second operating system. It can be seen that the entire operating system upgrade and the subsequent operating system startup process do not upgrade the boot loader and kernel, nor do they restart the boot loader and kernel.

[0352] The following describes various implementations of determining a container for an operating system to be upgraded.

[0353] In an embodiment of the present application, the BMC unit can configure a first system upgrade policy or a second system upgrade policy. The first system upgrade policy includes upgrading containers that are currently in a non-running state, and the second system upgrade policy includes upgrading containers that are currently in a running state.

[0354] It should be noted that the BMC can be fixed to use the first system upgrade policy or the second system upgrade policy. Alternatively, the BMC unit can use the first system upgrade policy or the second system upgrade policy specified by the user, and this embodiment of the application does not limit this. In addition, this embodiment of the application does not limit the method of user-specified system upgrade policy, for example, it can be implemented by sending instructions to the processor of the BMC unit.

[0355] In one implementation, the processor may be configured to obtain a root directory path and determine a container of the operating system to be started based on the root directory path, wherein the root directory path is used to indicate the container currently in operation.

[0356] In this implementation, the processor can automatically determine the container of the operating system to be upgraded by using the acquired root directory path. This not only helps to improve the convenience and accuracy of determining the container to be upgraded, but also helps to improve the user experience.

[0357] For example, if the root directory path is / mnt / inittramfs / rofs1, since rofs1 indicates the identifier of the first container (i.e., the container of the first operating system), the currently running container is the first container. If the root directory path is / mnt / inittramfs / rofs2, since rofs2 indicates the identifier of the second container (i.e., the container of the second operating system), the currently running container is the second container.

[0358] It is understandable that since the root directory is unique, the root directory path is also unique.

[0359] In an example, the root directory path indicates a container of the first operating system, and the processor may be configured to determine that the container of the second operating system is the container of the operating system to be upgraded based on the fact that the root directory path indicates the container of the first operating system.

[0360] Exemplarily, the root directory path is / mnt / inittramfs / rofs1, and the processor is currently running a container of the first operating system. That is, the container currently in running state is the container of the first operating system. Based on the above-mentioned first system upgrade strategy, after the processor obtains the root directory path, it can determine that the container of the second operating system is the container of the operating system to be upgraded.

[0361] In this example, the BMC unit adopts the first strategy to upgrade the currently non-running container. This helps avoid affecting the applications in the currently running container when the operating system is upgraded, thereby helping to reduce the impact of the operating system upgrade on the currently running applications.

[0362] In another example, the root directory path indicates a container of the first operating system. The processor may be further configured to determine that the container of the first operating system is the container of the operating system to be upgraded based on the root directory path indicating the container of the first operating system. For example, the root directory path is / mnt / inittramfs / rofs1, indicating that the processor is currently running a container of the first operating system. That is, the currently running container is the container of the first operating system. Based on the second system upgrade policy described above, after obtaining the root directory path, the processor may determine that the container of the second operating system is the container of the operating system to be upgraded.

[0363] In this example, the BMC unit uses the second strategy to upgrade the currently running container. This increases the variety of operating systems to be upgraded, thereby improving the user experience. Furthermore, if the BMC unit is configured with only one operating system, the processor can also upgrade only the operating system's container.

[0364] In another implementation, the container of the operating system to be upgraded is determined according to the container identifier indicated by the target event.

[0365] Exemplarily, the processor may determine the container to which the container identifier belongs as the container of the operating system to be upgraded.

[0366] It should be noted that the container indicated by the container identifier may be a container in a running state, or may be a container in a non-running state, and this embodiment of the present application does not impose any limitation on this.

[0367] Exemplarily, as shown in (a) of FIG14 , a fourth interface is displayed on the user's terminal device. The fourth interface includes a fourth control, wherein the fourth control is used to indicate the upgrade type, for example, the upgrade type includes a container upgrade. After the user selects the container upgrade indicated by the fourth control, the user clicks the next control on the fourth interface. As shown in (b) of FIG14 , the terminal device displays a fifth interface in response to the user's operation. The fifth interface includes a fifth control, and the fifth control is used to indicate the container of the operating system to be upgraded. After the user selects the second container on the fifth interface and clicks the next control on the fifth interface, the terminal device sends a system upgrade request to the processor in response to the user's operation. The system upgrade request includes an identifier of the second container.

[0368] It should be noted that for other related descriptions of FIG14 , reference can be made to the description of FIG5 , which will not be repeated here.

[0369] On this basis, the processor detects a target event, that is, after receiving a system upgrade request, it can determine the container of the operating system to be upgraded based on the container identifier indicated by the upgrade request.

[0370] In this implementation, by setting the system upgrade request to include a container identifier, that is, including the identifier of the container of the operating system to be upgraded, after detecting the system upgrade request, the processor can determine the container of the operating system to be upgraded based on the container indicated by the container identifier. This not only helps to improve the efficiency of determining the container of the operating system to be upgraded, but also can upgrade the container specified by the user, thereby improving the user experience.

[0371] In an embodiment of the present application, the processor can be used to determine the operating system to be upgraded and perform upgrade operations on the boot loader, kernel, and container of the operating system to be upgraded if the second preset condition is not met when the detected target event indicates upgrading the operating system.

[0372] Exemplarily, the processor upgrades the boot loader, kernel, and container of the operating system to be upgraded, that is, upgrades the entire partition of the operating system to be upgraded. For example, the upgrade operation is performed on the partition where the boot loader, kernel, and container of the operating system to be upgraded are located.

[0373] Exemplarily, the memory stores a partition table of the operating system, which indicates the partitions where the operating system's boot loader, kernel, container, etc. are located. The processor can use the operating system's partition table to perform a system upgrade on all partitions of the operating system to be upgraded.

[0374] As shown in FIG15 , it is a schematic diagram of an operating system upgrade path provided in an embodiment of the present application.

[0375] Exemplarily, as shown in FIG15 , the memory file system of the BMC unit may include a first upgrade path and a second upgrade path. The first upgrade path is a container upgrade path, and the second upgrade path is a non-container upgrade path, which may also be referred to as a full upgrade path. The container upgrade path is used to indicate that only a single container of the operating system is upgraded. As shown in FIG15 , the container upgrade path only includes path (1). The full upgrade path is used to indicate that the full partition of the operating system is upgraded. As shown in FIG15 , the full upgrade path includes path ①, path ②, and path ③.

[0376] On this basis, if the processor determines that the second preset condition is met, the operating system upgrade is performed through the container upgrade path. If the processor determines that the second preset condition is not met, the operating system upgrade is performed through the full upgrade path. This provides users with multiple operating system upgrade methods, such as container upgrade and full upgrade, allowing them to choose the appropriate upgrade method based on their actual scenario, which also helps improve the stability and reliability of the upgraded operating system.

[0377] In this embodiment, by setting the second preset condition not being met, the operating system to be upgraded is determined, and the upgrade operation is performed on the boot loader, the kernel, and the container of the operating system to be upgraded. In this way, by setting a suitable second preset condition, the computing device can be guided to upgrade the entire operating system, thereby providing users with multiple operating system upgrade methods, which helps to improve the user experience.

[0378] As shown in FIG16 , it is a schematic diagram of an operating system upgrade method provided in an embodiment of the present application.

[0379] Below, a specific operating system upgrade method provided in an embodiment of the present application is exemplarily described with reference to FIG16 .

[0380] While the BMC unit's processor is running the container (i.e., the original container) of the first operating system, a user triggers an operating system upgrade. After receiving the system upgrade request, the computing device determines whether a second preset condition is met. If the determination result is yes, the processor uses the container upgrade path to upgrade the operating system to be upgraded, that is, it reads the currently existing path (i.e., the root directory path), determines the container of the operating system to be upgraded (i.e., the container to be upgraded) based on the root directory path, and then upgrades the partition where the container to be upgraded is located. If the determination result is no, the processor uses the full upgrade path to upgrade the operating system to be upgraded, that is, it upgrades the full partition of the operating system to be upgraded, in other words, it upgrades the partition where the boot loader, kernel, and container of the upgraded operating system are located.

[0381] If the processor uses the container upgrade path to upgrade the operating system, after the upgrade is completed, the processor jumps to run the memory file system and unmounts the root directory of the first operating system (i.e., the current root directory) and the partition where the container of the first operating system is located. After that, the computing device jumps to run the upgraded container to start the application in the container, thereby starting the upgraded operating system.

[0382] If the processor uses the full upgrade path to upgrade the operating system, after the upgrade is complete, the processor jumps to run the memory file system, and then continues to jump to run the ROM boot program. Based on the ROM boot program, it runs the upgraded boot loader, kernel, container, etc. in sequence, and starts the application in the container, thereby starting the upgraded operating system.

[0383] Figure 17 is a flow chart showing a method for starting an operating system according to an exemplary embodiment. Exemplarily, the method for starting an operating system may include the following steps S1701-S1702.

[0384] It should be noted that the following uses the BMC unit as an example to illustrate the operating system startup method shown in Figure 17. Among them, the processor, memory, ROM, and operating system described below all belong to the BMC unit and will not be described in detail later.

[0385] S1701: The processor runs a boot loader and a kernel, thereby running a container of a first operating system.

[0386] In the embodiment of the present application, after the BMC unit is powered on, the processor runs the boot loader and kernel based on the ROM boot program, and during the kernel execution, generates a memory file system based on the kernel. On this basis, the processor runs the container of the first operating system, thereby realizing the operation of the first operating system.

[0387] S1702: When the processor detects a target event, the processor switches from the container of the first operating system to the container of the second operating system.

[0388] In an embodiment of the present application, when a processor is running a container of a first operating system, if a target event is detected, the processor switches from the container of the first operating system to the container of the second operating system, thereby running the second operating system.

[0389] It should be noted that for other relevant instructions of S1701-S1702, please refer to the operations performed by the processor introduced in the above embodiment, which will not be repeated here.

[0390] In the above embodiment, after the processor runs the boot loader and kernel stored in the memory, it runs the container of the first operating system, thereby realizing the operation of the first operating system. On this basis, when the processor detects a target event, the processor directly switches from the container of the first operating system to the container of the second operating system to run the container of the second operating system, thereby realizing the operation of the second operating system. Since the first operating system and the second operating system have a common boot loader and kernel, if the second operating system needs to be started during the operation of the first operating system, the processor does not need to repeatedly run the boot loader and kernel, but can directly run the container of the second operating system. In this way, the time consumed by restarting the operating system can be significantly shortened, thereby helping to improve the efficiency of operating system startup, and then helping to improve the user experience.

[0391] Figure 18 is a flow chart showing a method for operating an operating system according to an exemplary embodiment. Exemplarily, the operating system operating method may include the following steps S1801-S1803.

[0392] It should be noted that the operating system operation method shown in FIG18 can be executed by a terminal device. The terminal device can communicate with the computing device described above. In this way, a user can control the operating system running on the computing device through the terminal device, such as switching from running a first operating system to running a second operating system, thereby helping to improve the user experience.

[0393] Exemplarily, the terminal device may include a mobile phone, a tablet computer, a handheld computer, a PC, a cellular phone, a personal digital assistant (PDA), a wearable device (such as a smart watch, a smart bracelet, etc.), a smart home device (such as a television, etc.), a car machine (such as a car computer, etc.), a smart screen, a game console, headphones, AI speakers, augmented reality (AR) / virtual reality (VR) devices, an ultra-mobile personal computer (UMPC), a laptop computer, a netbook, a desktop computer or an all-in-one computer, etc.

[0394] It should be noted that the embodiments of the present application do not limit the device form of the terminal device, and the above is only an exemplary description.

[0395] S1801: The terminal device displays an operating system selection interface, where the operating system selection interface is used to indicate whether to select to start a container of a first operating system or a container of a second operating system.

[0396] Exemplarily, as shown in FIG19 , the terminal device displays an operating system selection interface, which includes a sixth control and a seventh control, wherein the sixth control indicates a container of the first operating system and the seventh control indicates a container of the second operating system.

[0397] In one example, the terminal device may display an operating system selection interface when the computing device is powered on, so that the user can select a container of the operating system to start when the computing device is powered on.

[0398] In another example, the terminal device may display an operating system selection interface while the computing device is running the first operating system. In this way, the user can select the container of the restarted operating system, that is, the container of the operating system to be switched, while the computing device is running.

[0399] S1802: When the terminal device receives a second user operation on the operating system selection interface, the terminal device determines a container for running the second operating system.

[0400] As shown in Figure 19, if the user performs a second user operation on the operating system selection interface, that is, selects the container of the first operating system, the terminal device determines to run the container of the second operating system after receiving the second user operation of the user on the operating system selection interface.

[0401] In one example, if the terminal device displays an operating system selection interface when the computing device is powered on, the terminal device can send a system startup request to the computing device. The system startup request can include an identifier of the container of the second operating system. In this way, after receiving the system startup request, the computing device starts the container of the second operating system based on the container identifier in the system startup request (i.e., the identifier of the container of the second operating system).

[0402] In another example, the terminal device may display an operating system selection interface while the computing device is running the first operating system. The terminal device may then send a system switching request to the computing device. The system switching request may include an identifier of the container of the second operating system. In this way, after receiving the system switching request, the computing device starts the container of the second operating system based on the container identifier in the system switching request (i.e., the identifier of the container of the second operating system).

[0403] S1803: When the terminal device receives a first user operation on the operating system selection interface, the terminal device determines a container for running the first operating system.

[0404] It should be noted that for other related instructions of S1803, please refer to S1802 and will not be repeated here.

[0405] In the above embodiment, the terminal device used by the user can display an operating system selection interface, which can be used to indicate the selection of a container for starting the first operating system or a container for the second operating system. When the user needs to restart the operating system, the user can perform an operation on the interface. After the terminal device receives the operation performed by the user, if it is a first user operation (i.e., the user selects a container for the first operating system), the terminal device determines the container for running the first operating system; if it is a second user operation, the terminal device determines the container for running the second operating system. Since the terminal device can determine the containers for running different operating systems based on different operations performed by the user, the user can determine the container for the operating system to be started. This not only helps to improve the user experience, but also allows the user to select containers for running different operating systems based on the different needs of actual scenarios.

[0406] An embodiment of the present application also provides a chip, including: a processor and a memory, the processor and the memory are connected; the memory is used to store the boot loader, kernel, container of the first operating system, and container of the second operating system in the above-mentioned first aspect, and the processor is used to run the boot loader, kernel, container of the first operating system / container of the second operating system stored in the memory.

[0407] An embodiment of the present application also provides a chip, which includes: a processor and an interface circuit; the interface circuit is used to receive the boot loader, kernel, and container of the first operating system in the above-mentioned first aspect, or receive the container of the second operating system in the above-mentioned first aspect and transmit it to the processor; the processor is used to run the boot loader, kernel, and container of the first operating system received by the interface circuit, or run the container of the second operating system received by the interface circuit.

[0408] The embodiment of the present application further provides a chip that integrates a control circuit and one or more ports for implementing the functions of the above-mentioned computing device. Optionally, the functions supported by the chip can be referred to above and will not be repeated here.

[0409] An embodiment of the present application also provides a computing device, comprising: a power supply and a chip provided by any one of the fifth to sixth aspects above, wherein the power supply is used to power the chip.

[0410] An embodiment of the present application also provides a computing device, comprising: a memory and a processor, the memory being used to store a first operating system and a second operating system, the first operating system comprising a container of the first operating system, the second operating system comprising a container of the second operating system; the first operating system and the second operating system having a common boot loader and kernel.

[0411] The present application also provides a computer-readable storage medium storing a boot loader, a kernel, a container for a first operating system, and a container for a second operating system. A computing device can execute the boot loader, the kernel, and the container for the first operating system to execute the first operating system. The computing device can also execute the first operating system when switching from executing the container for the first operating system to executing the container for the second operating system.

[0412] For explanations of the relevant contents and descriptions of the beneficial effects of any of the computer-readable storage media provided above, reference may be made to the corresponding embodiments described above, and no further details will be given here.

[0413] An embodiment of the present application further provides a computer program product comprising: the aforementioned boot loader, kernel, container for a first operating system, and container for a second operating system. A computing device can run the first operating system when running the boot loader, kernel, and container for the first operating system. The computing device can also run the first operating system when switching from running the container for the first operating system to running the container for the second operating system.

[0414] It should be noted that the above-mentioned devices for storing the operating system provided in the embodiments of the present application, such as but not limited to the above-mentioned memory, computer-readable storage medium and communication chip, etc., are all non-transitory.

[0415] Those skilled in the art will appreciate that all or part of the steps of the above embodiments can be implemented by instructing the relevant hardware through a program. The program can be stored in a computer-readable storage medium. The storage medium mentioned above can be a read-only memory, a random access memory, etc. The processing unit or processor can be a central processing unit, a general-purpose processor, an application specific integrated circuit (ASIC), a microprocessor (digital signal processor, DSP), a field programmable gate array (FPGA) or other programmable logic device, a transistor logic device, a hardware component, or any combination thereof.

[0416] The multiple operating systems in the above embodiments can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the operating system can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive).

[0417] Although the present application has been described in conjunction with various embodiments, in the process of implementing the claimed application, those skilled in the art may understand and implement other variations of the disclosed embodiments by reviewing the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other components or steps, and "one" or "an" does not exclude multiple components. A single processor or other unit may implement several functions listed in the claims. The fact that certain measures are recorded in different dependent claims does not mean that these measures cannot be combined to produce good results.

Claims

1. A computing device, characterized in that, The computing device includes a memory and a processor. The memory is used to store a first operating system and a second operating system. The first operating system includes containers of the first operating system, and the second operating system includes containers of the second operating system; the first operating system and the second operating system have a common boot loader and kernel; The processor is used to run the boot loader and the kernel, so as to run the containers of the first operating system; The processor is further used to switch from the containers of the first operating system to the containers of the second operating system when a target event is detected.

2. The computing device according to claim 1, wherein, The processor is further used to generate a memory file system during the process of running the kernel. The memory file system is used to provide an operating system switching function, an operating system upgrade function, and a jump function; the first operating system and the second operating system have the common memory file system.

3. The computing device according to claim 2, wherein The processor is further used to switch from the containers of the first operating system to the containers of the second operating system when a target event is detected, including: The processor is further used to jump from the containers of the first operating system to the memory file system when the detected target event indicates switching the operating system; The processor is further used to determine to switch to the containers of the second operating system and switch from the memory file system to the containers of the second operating system.

4. The computing device according to claim 3, wherein The processor is further used to switch from the memory file system to the containers of the second operating system, including: The processor is further used to switch from the memory file system to the containers of the second operating system when a first preset condition is met; The processor is further used to re-run the boot loader and the kernel to run the containers of the second operating system when the first preset condition is not met.

5. The computing device according to claim 3 or 4, characterized in that The processor is further used to determine to switch to the containers of the second operating system, including: The processor is further used to obtain startup configuration parameters from the storage medium of the computing device; the startup configuration parameters are used to indicate the containers of the operating system to be switched; The processor is further used to determine to switch to the containers of the second operating system according to the startup configuration parameters.

6. The computing device according to claim 5, wherein, The processor is further used to determine the startup configuration parameters according to the identifier of the containers of the first operating system when a target event is detected; The processor is further used to write the startup configuration parameters into the storage medium of the computing device.

7. The computing device according to claim 6, wherein, The storage medium includes a volatile storage medium; The processor is further used to write the startup configuration parameters into the storage medium of the computing device, including: the processor is further used to write the startup configuration parameters into the volatile storage medium when a first preset condition is met; or, The storage medium further includes a non-volatile storage medium; the processor is further configured to write the startup configuration parameters into the storage medium of the computing device, including: when the first preset condition is not satisfied, the processor is further configured to write the startup configuration parameters into the non-volatile storage medium.

8. The computing device according to claim 2, wherein the computing device is further configured to, when a target event is currently detected, restart the boot loader and the kernel, so as to run the container of the second operating system.

9. The computing device according to claim 2, wherein the processor is further configured to, when the detected target event indicates an upgrade of the operating system, determine the container of the operating system to be upgraded; the processor is further configured to perform an upgrade operation on the container of the operating system to be upgraded, and not perform an upgrade operation on the boot loader and / or the kernel of the operating system to be upgraded.

10. The computing device according to claim 9, wherein The processor is further configured to, when the detected target event indicates an upgrade of the operating system, determine the container of the operating system to be upgraded, including: when the detected target event indicates an upgrade of the operating system, the processor is configured to obtain a root directory path; the root directory path is used to indicate the container in the current running state, and the root directory path indicates the container of the first operating system; the processor is further configured to determine the container of the second operating system as the container of the operating system to be upgraded according to the fact that the root directory path indicates the container of the first operating system; or, the processor is further configured to determine the container of the first operating system as the container of the operating system to be upgraded according to the fact that the root directory path indicates the container of the first operating system.

11. The computing device according to claim 9, wherein The processor is further configured to, when the detected target event indicates an upgrade of the operating system, determine the container of the operating system to be upgraded, including: when the detected target event indicates an upgrade of the operating system, the processor is configured to determine the container of the operating system to be upgraded according to the container identifier indicated by the target event.

12. The computing device according to any one of claims 9-11, wherein the processor is further configured to, when the detected target event indicates an upgrade of the operating system, determine the container of the operating system to be upgraded, including: when the detected target event indicates an upgrade of the operating system, and when a second preset condition is satisfied, the processor is configured to determine the container of the operating system to be upgraded; when the detected target event indicates an upgrade of the operating system, and when the second preset condition is not satisfied, the processor is configured to determine the operating system to be upgraded; the processor is further configured to perform an upgrade operation on the boot loader, the kernel, and the container of the operating system to be upgraded.

13. A method for starting an operating system, characterized in that For a computing device, the computing device includes a memory and a processor, the memory is configured to store a first operating system and a second operating system, the first operating system includes a container of the first operating system, and the second operating system includes a container of the second operating system; the first operating system and the second operating system share a common boot loader and a common kernel; the method includes: The processor runs the bootloader and the kernel, thereby running the container of the first operating system; When the processor detects a target event, the processor switches from the container of the first operating system to the container of the second operating system.

14. A method for operating an operating system, characterized in that The method includes: Displaying an operating system selection interface for indicating a selection to start the container of the first operating system or the container of the second operating system; the first operating system and the second operating system have a common bootloader and kernel; When a first user operation on the operating system selection interface is received, determining to run the container of the first operating system; When a second user operation on the operating system selection interface is received, determining to run the container of the second operating system.

15. An operating system startup device, characterized in that, It includes: A running module for running the bootloader and the kernel, thereby running the container of the first operating system; A switching module for switching from the container of the first operating system to the container of the second operating system when a target event is detected; The first operating system and the second operating system have the common bootloader and the common kernel.

16. An operating system, characterized in that, The operating system includes a bootloader, a kernel, a container of the first operating system, and a container of the second operating system; the first operating system and the second operating system have the common bootloader and kernel; When the bootloader and the kernel are used to boot and run the container of the first operating system, if a target event is detected, switch from the container of the first operating system to the container of the second operating system; When the bootloader and the kernel are used to boot and run the container of the second operating system, if a target event is detected, switch from the container of the second operating system to the container of the first operating system.

Images