CN117873579A

CN117873579A - Operating system jump method, chip and device

Info

Publication number: CN117873579A
Application number: CN202311871778.5A
Authority: CN
Inventors: 万侃然; 毛阿利; 张嘉誉; 易倩; 敖初妍
Original assignee: XFusion Digital Technologies Co Ltd
Current assignee: XFusion Digital Technologies Co Ltd
Priority date: 2023-12-29
Filing date: 2023-12-29
Publication date: 2024-04-12

Abstract

The embodiment of the application provides an operating system jump method, a chip and equipment, and relates to the technical field of computers. In the method, when a computing device runs a container of a first operating system, if a target event is detected, the computing device judges whether a preset condition is met, if so, the computing device jumps from the container of the first operating system to a memory file system, and jumps to the container running the operating system to be started based on the memory file system. If not, reloading the kernel of the boot loader to run the container of the operating system to be started. On the one hand, by setting the preset conditions, two different operation system jump modes are provided for the user, so that different system jump modes can be adopted according to different scenes. On the other hand, by setting proper preset conditions, the matching degree of the jump mode and the current scene is improved, so that the stability and reliability of the subsequent operating system to be started after the starting are improved.

Description

Operating system jump method, chip and device

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to an operating system jump method, a chip, and a device.

Background

In the related art, when a computing device runs a current operating system, if the operating system needs to be switched, the computing device typically jumps from the current operating system to a Read Only Memory (ROM) boot program. Then, according to the partition address indicated by the ROM boot program, the boot loader, kernel, root file system, application program, etc. of the operating system to be started are sequentially operated.

Because the system jump mode in the related art is relatively single, a new operating system jump mode is needed.

Disclosure of Invention

The embodiment of the application provides an operating system jump method, a chip and equipment, which are beneficial to improving the diversity of the operating system jump modes, shortening the switching time of the operating system and improving the switching efficiency of the operating system.

In order to achieve the above purpose, the embodiments of the present application adopt the following technical solutions:

in a first aspect, an operating system jump method is provided for a computing device, the computing device including a first operating system and a second operating system, the first operating system including a container of the first operating system, the second operating system including a container of the second operating system; the boot loader, the kernel and the memory file system used by the first operating system and the second operating system are the same; the method comprises the following steps: loading a boot loader and a kernel, thereby running a container of a first operating system; when the occurrence of a target event is detected, judging whether the computing equipment meets a preset condition or not; if the preset condition is met, jumping to a memory file system from a container of the first operating system, and jumping to a container running the operating system to be started based on the memory file system; if the preset condition is not met, reloading the boot loader and the kernel, so as to run a container of the operating system to be started; the operating system to be started comprises a first operating system or a second operating system.

In the scheme, when the computing device runs the container of the first operating system, if a target event is detected, the operating system is required to be switched, based on the target event, the computing device judges whether a preset condition is met, if the preset condition is met, the computing device jumps to the memory file system from the container of the first operating system, and jumps to the container running the operating system to be started based on the memory file system. If the preset condition is not met, reloading the kernel of the boot loader to run the container of the operating system to be started. On the one hand, by setting the preset conditions, two different operation system jump modes are provided for the user, so that different system jump modes can be adopted according to different scenes. On the other hand, by setting proper preset conditions, the matching degree of the jump mode and the current scene is improved, so that the stability and the reliability of the subsequent operating system to be started after the starting are improved,

in addition, when the preset condition is met, after the computing device jumps to the running memory file system, the step of jumping to the running ROM guide program from the memory file system is omitted, so that the step of reloading the guide loading program and the kernel is avoided, and further, the container of the running operation system to be started based on the direct jump of the running memory file system is realized, and thus, the operation system to be started is facilitated to be quickly started, the time consumed by switching of the operation system is shortened, the switching efficiency of the operation system is improved, and the use experience of a user is further facilitated to be improved.

In another possible implementation, the container of the first operating system includes a plurality of applications; meeting the preset conditions includes: the closing operation of the plurality of application programs satisfies the target condition.

In the implementation manner, when the closing operation of the plurality of application programs meets the target condition, the preset condition is met, that is, the operation system can directly jump to the container of the operating system to be started based on the memory file system, so that the stability of the first operating system running currently is improved, the first operating system is prevented from being crashed due to the fact that the plurality of application programs are crashed, and the stability and the reliability of the application programs of the operating system started later are also prevented from being influenced by improper closing of the application programs of the first operating system.

In another possible implementation, the container of the first operating system includes a plurality of applications; meeting the preset conditions includes: the closing operation of the plurality of application programs meets the target conditions and the system switching type indicated by the target event is container switching; the container switch is used for indicating the container loading the operating system to be started in the system switch process.

In the implementation manner, when the closing operation of the plurality of application programs meets the target condition and the target event indicates the container switching, the preset condition is met, so that the stability of the first operating system running at present and the stability of the operating system started later can be improved by setting the proper target condition, the matching degree of the system jump mode and the target event can be improved, and the stability and the reliability of the operating system started later can be improved. In addition, the container switching is indicated by setting the target event, and the preset condition is met, so that the system jump mode can be determined according to the system switching type specified by the user, and the user experience is improved.

In another possible implementation, the closing operation of the plurality of applications satisfies the target condition, including: multiple applications were successfully closed. In this way, the method helps to avoid that the plurality of application programs of the first operating system influence the normal running of the plurality of application programs of the second operating system started later.

In another possible implementation, the closing operation of the plurality of applications satisfies the target condition, including: the order of closing the plurality of applications is opposite to the order of starting the plurality of applications. In this way, it is helpful to avoid crashing of multiple applications, resulting in a first operating system crash.

In another possible implementation, the closing operation of the plurality of applications satisfies the target condition, including: the plurality of applications are successfully closed and the closing order of the plurality of applications is reverse to the starting order of the plurality of applications. Thus, the method is not only beneficial to avoiding the first operating system from crashing caused by the crashing of a plurality of application programs, but also beneficial to avoiding the application programs of the first operating system from influencing the normal running of a plurality of application programs of a second operating system started later.

In another possible implementation manner, the preset condition is not satisfied, including: the system switching type indicated by the target event is non-container switching, and/or the closing operation of the plurality of application programs does not meet the target condition; the non-container switch is used for indicating the loading of the boot loader, the kernel and the container of the operating system to be started in the system switch process.

In the implementation manner, when the closing operation of the plurality of application programs does not meet the target condition and the target event indicates non-container switching, the preset condition is not met, so that the application program of the first operating system can be prevented from influencing the application program of the subsequently started operating system and the stability of the subsequently started operating system, the matching degree of the system jump mode and the target event can be improved, and the stability and the reliability of the subsequently started operating system can be improved. In addition, the non-container switching is indicated by setting the target event, and the fact that the preset condition is not met is determined, so that the system jump mode can be determined according to the system switching type specified by the user, and the user experience is improved.

In another possible implementation, detecting the occurrence of the target event includes: a system handoff request is detected.

In the implementation mode, when the system switching request is received, the memory file system is jumped, so that a user can trigger the computing equipment to switch the operating system by sending the system switching request to the computing equipment, the diversity of the triggering operating system switching mode is improved, and the use experience of the user is improved.

In another possible implementation, detecting the occurrence of the target event includes: and detecting that the system upgrade is finished.

In the implementation mode, after the system upgrading operation is performed, the running memory file system is automatically jumped, so that the operation system after the operation system is automatically switched and run after the operation system is upgraded is realized, and therefore, the operation system is not required to be manually triggered and switched by a user, the convenience of system switching after the operation system is upgraded is improved, and the use experience of the user is improved.

In another possible implementation, the bootloader and kernel used by the multiple operating systems are the same, including: different operating systems of the multiple operating systems share the same boot loader and kernel.

In this implementation, when the computing device is configured with multiple operating systems, different operating systems in the multiple operating systems share the same boot loader and kernel, which helps to reduce the storage space occupied by the multiple operating systems configured by the computing device.

In another possible implementation, the bootloader and kernel used by the multiple operating systems are the same, including: the code of the boot program of different operating systems is the same and the code of the kernel of different operating systems is the same in the plurality of operating systems.

In the implementation manner, the codes of the bootstrap programs and the codes of the kernel of different operating systems are set to be the same, so that each operating system can use the bootstrap programs and the kernel of other operating systems, and the integrity of each operating system is guaranteed.

In a second aspect, there is provided an operating system jumping apparatus, comprising: the functional units for executing any of the methods provided in the first aspect, and actions executed by the respective functional units are implemented by hardware or implemented by hardware executing corresponding software. For example, the operating system jumping device may include a run module, a judge module, a first jumping module, and a second jumping module; the running module is used for loading the boot loader and the kernel so as to run the container of the first operating system; the judging module is used for judging whether the computing equipment meets the preset condition or not when the occurrence of the target event is detected; the first jump module is used for jumping from a container of the first operating system to the memory file system if the preset condition is met, and jumping to the container running the operating system to be started based on the memory file system; the second jump module is used for reloading the boot loader and the kernel if the preset condition is not met, so that a container of the operating system to be started is operated; the operating system to be started comprises a first operating system or a second operating system.

In a third aspect, a chip is provided, the chip comprising: the device comprises a processor and a memory, wherein the processor is connected with the memory; the memory is configured to store computer-executable instructions, and the processor executes the computer-executable instructions stored in the memory, so that the chip implements any one of the methods provided in the first aspect.

In a fourth aspect, there is provided a chip comprising: a processor and interface circuit; the interface circuit is used for receiving the code instruction and transmitting the code instruction to the processor; a processor for executing code instructions to perform any of the methods provided in the first aspect above.

In a fifth aspect, there is provided a computer device comprising: a power supply for supplying power to a chip for implementing any one of the methods provided in the first aspect, and a chip provided in the third or fourth aspect.

In a sixth aspect, there is provided a computer readable storage medium storing computer executable instructions that when run on a computer cause the computer to perform any one of the methods provided in the first aspect above.

In a seventh aspect, there is provided a computer program product comprising: computer-executable instructions that, when executed on a computer, cause the computer to perform any of the methods provided in the first aspect above.

The technical effects caused by any implementation manner of the second aspect to the seventh aspect may refer to the technical effects caused by different implementation manners of the first aspect, and are not repeated here.

Drawings

FIG. 1 is a schematic diagram of a computing device provided in an embodiment of the present application;

fig. 2 is a schematic level diagram of a BMC unit according to an embodiment of the present application;

FIG. 3 is a flowchart of an operating system jump method according to an embodiment of the present disclosure;

fig. 4 is a schematic diagram of starting an application according to an embodiment of the present application;

FIG. 5 is a schematic view of an interface according to an embodiment of the present disclosure;

FIG. 6 is a schematic diagram of an operating system jump procedure according to an embodiment of the present disclosure;

fig. 7 is a schematic diagram of an operating system jumping device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application.

Wherein, in the description of the present application, "/" means that the related objects are in a "or" relationship, unless otherwise specified, for example, a/B may mean a or B; the term "and/or" in this application is merely an association relation describing an association object, and means that three kinds of relations may exist, for example, a and/or B may mean: there are three cases, a alone, a and B together, and B alone, wherein a, B may be singular or plural.

Also, in the description of the present application, unless otherwise indicated, "a plurality" means two or more than two. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b, or c may represent: a, b, c, a-b, a-c, b-c, or a-b-c, wherein a, b, c may be single or plural.

In addition, in order to clearly describe the technical solutions of the embodiments of the present application, in the embodiments of the present application, the words "first", "second", and the like are used to distinguish the same item or similar items having substantially the same function and effect. It will be appreciated by those of skill in the art that the words "first," "second," and the like do not limit the amount and order of execution, and that the words "first," "second," and the like do not necessarily differ. Meanwhile, in the embodiments of the present application, words such as "exemplary" or "such as" are used to mean serving as examples, illustrations, or descriptions. Any embodiment or design described herein as "exemplary" or "for example" should not be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion that may be readily understood.

Hereinafter, related terms related to the embodiments of the present application will be briefly described.

A container: a virtualization technology in a computer operating system can be used for packaging and isolating running environments of different application programs so as to isolate the application programs from the operating system, so that the application programs can only access temporarily assigned resources and cannot access files and folders actually existing on the operating system.

In embodiments of the present application, the container may include a root file system, a system daemon, an application program, and the like.

Partitioning: the term "partition of an operating System" or "System partition" refers to dividing a storage space of a storage device into different sections. The storage device for storing the operating system may be divided into different partitions according to the functional characteristics of the operating system, for example: partitions of a boot loader (e.g., uboot), partitions of a kernel (e.g., kernel), partitions of a root file system (e.g., rootfs), and partitions of an application, etc.

In the embodiment of the application, the partition may include a partition of a boot loader, a partition of a kernel, a partition of a container, and the like.

Root file system (e.g., rootfs): is used for managing and storing files.

Memory file system (ramfs): is the basic file system that is pulled up by the kernel of the operating system for switching containers, mounting/dismounting partitions, restarting the system, interacting with the processor, etc.

change root (color) command: for changing the root directory to the specified directory, i.e., switching the program execution environment to the specified directory. After the switch, the old root directory structure and files will not be accessed in the new running environment. Illustratively, the color command may switch from the ramfs environment to the root directory environment of the specified container.

System daemon (system daemon, system d): is a process for starting an application program and restricting the dependency relationship between the application program before and after the start.

Application program: may also be referred to as a service, for implementing relatively independent functions, and different applications may communicate by way of inter-process communication.

In the following, an application scenario of the embodiment of the present application is described exemplarily.

In the related art, when the operating system needs to be switched during the running process of the current operating system, the computing device typically jumps from the current operating system to the ROM boot program. Then, according to the partition address indicated by the ROM boot program, the boot loader, kernel, root file system, application program, etc. of the operating system to be started are sequentially operated.

In view of this, the embodiment of the present application provides a system jump method, which is used for a computing device, when the computing device runs a container of a first operating system, if a target event is detected to occur, which indicates that the operating system needs to be switched, based on this, the computing device determines whether a preset condition is met, if the preset condition is met, jumps from the container of the first operating system to a memory file system, and jumps to the container running the operating system to be started based on the memory file system. If the preset condition is not met, reloading the kernel of the boot loader to run the container of the operating system to be started. On the one hand, by setting the preset conditions, two different operation system jump modes are provided for the user, so that different system jump modes can be adopted according to different scenes. On the other hand, by setting proper preset conditions, the matching degree of the jump mode and the current scene is improved, so that the stability and the reliability of the subsequent operating system to be started after the starting are improved,

The system architecture of the embodiments of the present application is described below as an example.

The system jump method provided by the embodiment of the application is suitable for the computing equipment, and the computing equipment comprises at least one management unit. Each of the at least one management unit may include a processor, memory, storage device, and the like. The storage device stores at least one operating system therein, and the processor can run the at least one operating system in the storage device through the memory.

In an embodiment of the present application, each of the at least one operating system may include a boot loader, a kernel, a container, and the like. The container for each operating system may include a root file system, a system daemon, and at least one application program, etc.

It should be noted that at least one of the embodiments of the present application may be one or may be plural. The number of the plurality may be two, or may be more than two, which will not be described in detail later.

The operating system jump method provided by the embodiment of the application is suitable for each management unit of the computing device, and each management unit can execute different jump modes according to whether the management unit meets the preset condition when the target event is detected, for example: after jumping to the memory file system, the boot loader and the kernel are reloaded based on the memory file system jumping to a container that is to be started to cause the system, or after jumping to the memory file system.

In this embodiment, each management unit may further include a read-only memory. The ROM stores a ROM boot program. The ROM boot program indicates a partition address of the boot loader in the storage device, based on which, when the operating system is started, the management unit can jump to the boot loader of the operating system based on the partition address indicated by the ROM boot program and jump to the kernel based on the partition address of the kernel indicated by the boot loader, thereby realizing restarting the boot loader and the kernel of the operating system.

By way of example, ROM may be embedded in a processor. The codes in the ROM may be identical for the same model of processor.

In the embodiment of the application, the at least one management unit may include an in-band management unit and an out-band management unit.

By way of example, an in-band management unit refers to a unit for implementing in-band management, such as: central management unit, etc., in-band management means that management data of the computing device and service data of the user are transmitted using the same physical channel.

By way of example, an out-of-band management unit refers to a unit for implementing out-of-band management, such as: baseboard management controller (board management controller, BMC) unit, etc., out-of-band management refers to the transmission of management data of a computing device and traffic data of a user using different physical channels.

It should be noted that different computing devices may be referred to as BMCs differently, for example, some computing devices may be referred to as BMCs, some computing devices may be referred to as iLO, and another computing device may be referred to as iDRAC. Either called BMC or iLO or iracc may be understood as BMC in embodiments of the present invention.

Alternatively, the computing device may comprise a network device or a terminal device.

The network device may include a server or the like. The server may be one physical or logical server, or may be two or more physical or logical servers sharing different responsibilities, and cooperate to implement various functions of the server. By way of example, the server may be a blade server, a high-density server, a rack server, a tower server, or the like.

The terminal devices may include augmented reality (augmented reality, AR) devices, virtual Reality (VR) devices, personal digital assistants (personal digital assistant, PDAs), ultra-mobile personal computers (UMPC), tablet computers, notebook computers, netbooks, desktop computers, all-in-one machines, and the like.

It should be noted that the embodiments of the present application do not limit the form of the computing device, and the foregoing is merely exemplary.

Fig. 1 is a schematic diagram of a computing device according to an embodiment of the present application.

For example, referring to fig. 1, a computing device may include a first management unit and a second management unit. The first management unit may be an out-band management unit, and the out-band management unit may include a processor 1, a ROM1, a memory 1, a storage device 1, and the like. The second management unit may be an in-band management unit, which may include a processor 2, a ROM2, a memory 2, a storage device 2, and the like.

It should be noted that the computing device shown in fig. 1 is merely a schematic structural diagram of one computing device applicable to the embodiments of the present application, and is not limited to the computing device applicable to the embodiments of the present application.

Hereinafter, an embodiment of the present application will be exemplarily described by taking an out-of-band management unit as a BMC unit.

In an embodiment of the present application, the BMC unit may include at least one operating system. Wherein each of the at least one operating system may include a bootloader, a kernel, and a container.

Where the BMC unit includes one operating system, the one operating system may include a bootloader, a kernel, and a container. Wherein the container includes a root file system, a system daemon (system), and at least one application.

On this basis, an operating system is stored in a plurality of partitions of the storage device 1. Such as: the plurality of partitions includes partition 1, partition 2, and partition 3, wherein partition 1 stores a boot loader, partition 2 stores a kernel, and partition 3 stores a container.

It should be noted that, the number of applications in the container is not limited in the embodiments of the present application.

When the BMC unit includes multiple operating systems, the bootloader and kernel used by different operating systems in the multiple operating systems are the same. Because the memory file system is based on kernel pull, the memory file systems used by different operating systems are the same under the condition that the kernels used by different operating systems are the same.

It should be noted that, the bootloader and the kernel used by different operating systems are the same, and it may be considered that one operating system may be compatible with the bootloader and the kernel of other operating systems.

Hereinafter, the same boot loader and kernel are used and exemplarily described in modes 1 to 2.

Mode 1: different operating systems in the multiple operating systems share the same boot loader and kernel.

Wherein different operating systems have different containers.

The BMC unit includes M operating systems, that is, M operating systems are stored in a plurality of partitions of the storage device 1, where M is a positive integer greater than 1. Since different operating systems use the same bootloader and kernel, i.e., share the same bootloader and kernel, the M operating systems may include one bootloader, one kernel, and M containers. Wherein one container belongs to one operating system, in other words, different containers belong to different operating systems. A container of an operating system may include a root file system, a system daemon (system) and applications of an operating system.

In this way, the same boot loader and the same kernel are used by different operating systems, which is helpful to reduce the storage space occupied by a plurality of operating systems and further to save storage resources.

By way of example, the plurality of partitions of storage device 1 may include m+2 partitions, where m+2 partitions may comprise partition 1, partition 2, partition 3, and/or partition m+2, where partition 1 may be used to store a bootloader, partition 2 may be used to store a kernel, partition 3, and/or partition m+2 may be used to store M containers.

It should be noted that the application programs in different containers may be the same or may be different, which is not limited in this embodiment of the present application.

Mode 2: the code of the boot loader used by different operating systems is the same in the multiple operating systems, and the code of the kernel used by different operating systems is the same. Wherein different operating systems have different containers.

That is, multiple operating systems all have separate bootloaders and kernels, but the code of the bootloader used by different operating systems is the same and the code of the kernel used by different operating systems is the same. In this case, one operating system may also use the boot loader and kernel of another operating system.

In this way, by setting that different operating systems include independent boot loader, kernel and container, and the code of the boot loader used by different operating systems is the same as the code of the kernel, it is not only helpful to ensure the integrity of each operating system, but also to improve the interoperability in switching between different operating systems, and further to help the container of the operating system to be started to be directly jumped to run by the container of the operating system currently running in system switching, and further to help to improve the efficiency of system switching.

The description of the container in mode 2 may refer to mode 1, and will not be repeated here.

Hereinafter, an embodiment of the present application will be exemplarily described by taking the above-described mode 1 as an example.

As shown in fig. 2, a hierarchical schematic diagram of a BMC unit is provided in an embodiment of the present application.

Referring to fig. 2, the bmc unit includes a hardware layer and a software layer, which is program code running on the hardware layer.

The hardware layer comprises a processor, a memory, a ROM, a storage device and the like. The software layer includes an operating system (e.g., a boot loader, kernel, etc.). The user side may use applications running on the computing device through a file system in the software layer.

In the following, an exemplary description is given of an operating system boot process of the BMC unit in connection with fig. 2.

The BMC unit, for example, includes a first operating system including a first container and a second operating system including a second container, the first operating system and the second operating system sharing the same boot loader and kernel.

In fig. 3, the first container is shown as a solid line to represent the container in the operating state. The second container is a dashed line to characterize the container in the non-operational state, or alternatively, in the dormant state.

When the BMC unit is powered up, the processor of the BMC unit first runs a ROM boot, such as: and loading the ROM boot program into the memory of the BMC unit. The processor then runs the operating system in the storage device based on the partition address in the ROM boot (i.e., the partition address of the boot loader).

Wherein running the operating system in the storage device may comprise the steps of:

1) A boot loader running an operating system: according to the partition address indicated by the ROM boot program, switching to the partition where the boot loader is located, loading the boot loader into a specified memory address for operation, wherein the specified memory address can be set when leaving the factory, and in the process of operating the boot loader, basic Input Output (IO) configuration and the like can be performed.

2) The running kernel: based on the partition address indicated by the boot loader, switching to the partition where the kernel is located, and loading the kernel into the specified memory address for operation. When the kernel is operated, the configuration and loading of the driving device, the pulling of the memory file system and the like can be performed.

Wherein, the kernel includes a jumper, and the jumper can be used for realizing at least part of functions in the operating system jump method, such as: jumps from a container of the first operating system to the line memory file system, etc. When the memory file system is pulled up, the memory file system can be pulled up by using the jumping machine, so that the memory file system can comprise the jumping machine, and the memory file system can be used for realizing the jumping method of the operating system.

The kernel includes a switcher, which can be used to implement at least part of the functions in the operating system jump method, such as: and jumping from the memory file system to a container of the operating system to be started, and the like. When the memory file system is pulled up, the memory file system can be pulled up by using the jumping machine and the switcher, so that the memory file system can comprise the jumping machine and the switcher, and the memory file system can be used for realizing the operating system jumping method provided by the embodiment of the application.

3) The operation container comprises: after the memory file system is pulled up, switching to a partition where the first container is located, mounting the partition where the first container is located, and mounting the initial directory of the first container as a root directory, namely loading the content in the first container into a specified memory address for operation.

4) Running an application program: an application in the first container is started by a system daemon in the first container.

It should be noted that, the system architecture and the application scenario described in the embodiments of the present application are for more clearly describing the technical solution of the embodiments of the present application, and do not constitute a limitation on the technical solution provided in the embodiments of the present application, and those skilled in the art can know that, with the evolution of the system architecture and the appearance of the new application scenario, the technical solution provided in the embodiments of the present application is also applicable to similar technical problems.

For easy understanding, the operating system jump method provided in the embodiments of the present application is described below by way of example with reference to the above system architecture and the accompanying drawings.

FIG. 3 is a flowchart illustrating an operating system jump method according to an exemplary embodiment. By way of example, the operating system jump method may include the following S301-S304.

An operating system jump method will be described below by taking an operating system of a BMC unit of a computing device as an example. The following processor, storage device, memory, ROM, and operating system all belong to the BMC unit, and will not be described later.

The embodiment shown in fig. 3 will be exemplarily described below by taking an example in which the BMC unit includes a first operating system and a second operating system.

The boot loader, the kernel and the memory file system used by the first operating system and the second operating system are the same. The container of the first operating system may be named a first container and the container of the second operating system may be named a second container.

The first container, the second container may include a root file system, a system daemon, and at least one application.

It should be noted that, in the embodiment of the present application, the number of applications in the first container and the second container is not limited, and the applications in the first container and the second container may be all the same, partially the same, or may also be all different. Hereinafter, the embodiments of the present application will be exemplarily described by taking an example in which the first container and the second container include a plurality of application programs.

For example, one of the first operating system and the second operating system may be an operating system of a BMC architecture (abbreviated as BMC system), and the other operating system may be an operating system of an OpenBMC architecture (abbreviated as OpenBMC system).

In the following, an operating system currently running in the BMC unit is taken as an example of a first operating system (for example, the first operating system is a BMC system), and an operating system switching method provided in the embodiment of the present application is described in an exemplary manner.

S301: the computing device loads a boot loader and a kernel, thereby running a container of the first operating system.

In the embodiment of the application, the BMC unit loads the boot loader and the kernel in sequence, generates the memory file system based on the jump machine, the switcher and the like included in the kernel in the process of running the kernel, and then runs the container of the first operating system, so that the first operating system is run.

Because the memory system comprises a jumping machine, a switcher and the like, the operating system jumping method provided by the embodiment of the application can be realized based on the memory file system in the process of running the memory file system by the BMC unit.

It should be noted that, the container in which the BM unit runs the first operating system may be considered as a plurality of applications included in the container in which the BMC unit runs the first operating system.

In addition, the BMC unit in the embodiment of the present application may perform a certain operation (e.g., load the memory file system, the first container, etc.), which may be performed by the processor of the BMC unit, and will not be described later.

The other descriptions of S301 may refer to the descriptions of fig. 2, and are not repeated here.

S302: and when the computing equipment detects that the target event occurs, judging whether the computing equipment meets the preset condition.

If the determination is yes, S303 is executed. If the determination result is no, S304 is executed.

In the embodiment of the application, after the BMC unit of the computing device detects the target event, whether the BMC unit currently meets the preset condition is judged, so that a subsequent jump mode is determined conveniently.

The following will exemplarily illustrate the target event by cases 1 to 2

Case 1: the target event is a system switch request.

For example, when the user needs to switch the operating system running on the BMC unit, the electronic device may send a system switching request to the BMC unit of the computing device to request to switch the operating system running on the BMC unit. In the process of running the first container by the BMC unit, if a system switching request is received, the BMC unit belongs to the detection of the target event.

In this embodiment, the target event may be a system switching request, so that the user may send the system switching request to the processor of the BMC unit to implement the operation system switching triggering operation, which is not only helpful for improving the diversity of the operation system switching triggering mode, but also for improving the use experience of the user.

Case 2: the target event is the completion of the system upgrade operation.

Illustratively, in the case where the BMC unit of the computing device detects that a certain operating system (e.g., a second operating system) has performed an upgrade operation, that is, that a system upgrade has been completed, it is a detection of a target event.

In one example, the BMC unit may determine whether the preset condition is satisfied immediately after the second operating system is performed with the upgrade operation.

In another example, the BMC unit may determine whether the preset condition is satisfied after the second operating system is performed with the upgrade operation and the preset period of time has elapsed.

It should be noted that, the specific value of the preset duration is not limited in the embodiment of the present application. For example, 5 seconds, 10 seconds, etc. may be mentioned.

In yet another example, the BMC unit may determine whether the preset condition is satisfied at a designated time after the second operating system is performed with the upgrade operation.

It should be noted that, the specific time point of the specified time is not limited in the embodiment of the present application. For example, the specified time may be 0 point, 1 point, or the like of the next day.

In this embodiment, the system upgrade may be completed by setting the target event, so that after the operating system upgrade is completed, the processor may automatically trigger the operating system to switch the operating system, so that the user does not need to manually trigger the switching of the operating system, which is not only helpful to improve the convenience of system switching after the operating system upgrade, but also is helpful to improve the use experience of the user.

It should be noted that, the second operating system upgrade may be a container upgrade of the second operating system, or may also be an upgrade of an entire operating system of the second operating system, where the upgrade of the entire operating system of the second operating system refers to upgrading a boot loader, a kernel, a container, and the like of the second operating system at the same time.

Optionally, meeting the preset condition may include: the closing operation of the plurality of applications in the container of the first operating system satisfies a target condition and/or the target event indicates a container switch. The container switching is used for indicating the container to be switched to the operating system to be started in the system switching process.

In this embodiment, when the closing operation of the plurality of application programs meets the target condition, it is determined that the preset condition is met, that is, the container of the operating system to be started is directly jumped from the memory file system, so that by setting the appropriate target condition, not only is the stability of the currently running operating system affected by the crash of the plurality of application programs facilitated, but also the application programs of the operating system that are subsequently cut by the plurality of application programs of the first operating system are avoided.

In addition, when the container is indicated to be switched by setting the target event, the preset condition is confirmed to be met, so that the relevance between the target event and the system switching mode is improved, and the reliability and the accuracy of the system jump mode are guaranteed.

In the following, modes 1 to 3 will be exemplarily described as to a mode of judging whether or not a preset condition is satisfied.

Mode 1: based on the closing operation of the plurality of application programs, it is determined whether a preset condition is satisfied.

And in the process of running the container of the first operating system by the BMC unit of the computing device, if the target event is detected, executing closing operation on a plurality of application programs in the container of the first operating system so as to close the plurality of currently running application programs.

On the basis, if the closing operation of the plurality of application programs meets the target condition, the preset condition is determined to be met. If the closing operation of the plurality of application programs does not meet the target condition, determining that the preset condition is not met.

In this embodiment, by setting an appropriate target condition, it is not only helpful to avoid the first operating system from crashing due to crashing of multiple application programs, but also helps to avoid the application program of the first operating system from affecting the normal running of the application program of the second operating system that is started subsequently.

In this embodiment of the present application, the closing operation of the plurality of application programs satisfies a target condition, including: the plurality of applications may be successfully closed and/or the order of closing the plurality of applications may be reversed from the order of starting the plurality of applications.

In this embodiment, by setting that each application program in the plurality of application programs is successfully closed, it is possible to avoid that the application program of the first operating system affects the normal running of the application program of the second operating system that is started subsequently, and setting that the closing order of the plurality of application programs is opposite to the starting order of the plurality of application programs is helpful to avoid that the plurality of application programs crash to cause the first operating system crash.

The starting sequence of the plurality of application programs refers to the starting sequence of the plurality of application programs in the latest time period.

For example, at a first time, the starting sequence of the plurality of application programs is sequence 1, at a second time, the starting sequence of the plurality of application programs is sequence 2, and the second time is later than the first time, the sequence 1 is different from the sequence 2, and then the sequence 2 is the starting sequence in the latest time period.

Hereinafter, a plurality of application closing processes will be exemplarily described with reference to fig. 4.

For example, as shown in fig. 4, when the BMC unit starts the first operating system, the boot loader, the kernel, the memory file system, and the like of the first operating system are sequentially run. The BMC unit then starts to launch the plurality of applications in the first container (i.e., the container of the first operating system), and during the process of launching the plurality of applications in the first container, the BMC unit records a launch sequence of the plurality of applications, where the launch sequence may be used to indicate a dependency relationship between different applications.

For example, the BMC unit may start application 1, application 2, and application N in that order. After that, the BMC unit may close part of the applications or restart part of the applications during the process of running the plurality of applications. During the process of restarting a portion of the applications, the BMC unit may update the previously recorded starting sequence of the plurality of applications. For example, the start-up order in the most recent period of time of the plurality of applications is 1, 3, and.

On the basis, after the BMC unit detects the target event, closing operation is performed on the plurality of application programs so as to close the plurality of application programs in the running state. When executing the shutdown operation for the plurality of applications, if the shutdown order of the BMC unit for the plurality of applications is 2, N, the.once., 3, 1, the order of closing the plurality of applications is reverse to the order of starting the plurality of applications.

For example, after the BMC unit performs a shutdown operation on one application, a return value may be received, which may be used to indicate whether the one application was successfully shutdown. Thus, the BMC unit can determine whether the application program is successfully closed according to the returned value.

In this embodiment of the present application, when the BMC unit starts to run a plurality of applications, the BMC unit may start sequentially from inside to outside according to a dependency relationship between the plurality of applications. For example, the running of the application 1 depends on the application 2, that is, the application 1 cannot run alone, and the application 1 can run normally only when the application 2 is running, which is called that the application 1 has a dependency relationship with the application 2, and the application 1 depends on the application 2, where the application 2 is in the dependency relationship, and the application 1 is out of the application relationship.

Based on this, when application 1 and application 2 need to be started, the BMC unit starts application 2 first and then starts application 1. When the application 1 and the application 2 are closed, the application 1 is closed first, and then the application 2 is closed, so that the application 1 is prevented from crashing.

On the basis, when the BMC unit executes the closing operation on the plurality of application programs, if the closing order of the plurality of application programs is opposite to the starting order of the plurality of application programs, the closing operation is sequentially closed from outside to inside according to the dependency relationship among the plurality of application programs, and therefore the closed application programs are prevented from being crashed.

In the embodiment of the present application, in the process of executing the closing operation on the plurality of application programs, the interval time of the closing operation of the adjacent two application programs is greater than 0. In this way, it is helpful to ensure that different applications can be turned off in series and in sequence.

The application program closing sequence includes an application program 1 and an application program 2, based on which the BMC unit performs a closing operation on the application program 1 at a time 1 and performs a closing operation on the application program 2 at a time 2, wherein a difference between the time 1 and the time 2 is greater than 0.

Mode 2: and determining whether a preset condition is met or not based on the system switching type indicated by the target event and closing operation of the plurality of application programs.

If the system switching type indicated by the target event is container switching and the closing operation of the plurality of application programs meets the target condition, determining that the preset condition is met. If the system switching type indicated by the target event is non-container switching or the closing operation of the plurality of application programs does not meet the target condition, determining that the preset condition is not met.

In the embodiment of the application, the system switching type may include container switching or non-container switching. Wherein, container switching may also be referred to as fast switching, and non-container switching may also be referred to as full-scale switching or full-scale partition switching.

Wherein, the container switch is used for indicating the container loading the operating system to be started in the system switch process, in other words, the boot loader, the kernel and the like are not loaded. Illustratively, the path of the container switch is: container of the current operating system, memory file system of the current operating system, and container of the operating system to be started.

The non-container switching is used for indicating a container for loading a boot loader, a kernel and an operating system to be started in the system switching process. Exemplary, non-container switched paths are: the method comprises the steps of a container of a current operating system, a memory file system of the current operating system, a ROM boot program, a boot loader, a kernel, a memory file system and a container of an operating system to be started.

In the following, an exemplary description is given of how to determine the system switch type when the target event is a system switch request.

For example, the system switch request indicates a switch type, and the BMC unit may determine whether the system switch type indicated by the target event is a container switch through the system switch type indicated by the system switch request. Therefore, whether the system switching type indicated by the user is container switching or not can be achieved, and the user experience can be improved.

The system switch request includes a switch identifier, where the switch identifier indicates a switch type, and if the switch identifier indicates a container switch, the system switch type is determined to be a container switch, and if the switch identifier indicates a non-container switch, the system switch type is determined to be a non-container switch.

In the following, an exemplary description is given of how to determine the system handoff type when the target event is that the system upgrade is completed.

In one example, if the system upgrade type is a container upgrade, then the system switch type is determined to be a container switch. Wherein a container upgrade is used to instruct a single container of the operating system to be upgraded during a system upgrade, i.e., the boot loader and kernel of the operating system are not upgraded.

It should be noted that, the BMC unit may check the system upgrade type through the log, and if only the container is upgraded when the latest operating system upgrade is recorded in the log, that is, the boot loader and the kernel are not upgraded, the system upgrade type is the container upgrade. If the latest operating system upgrade is recorded in the log and the boot loader, the kernel and the memory file system are upgraded at the same time, the system upgrade type is non-container upgrade.

In another example, if the target event is that the system upgrade is complete, then the system switch type is determined to be a container switch. That is, regardless of whether the system upgrade type is a container upgrade, the system switch type is determined to be a container switch whenever the target event is that the system upgrade is complete.

In yet another example, if the target event is that the system upgrade is complete, the system switch type is determined to be a non-container switch.

For other descriptions of embodiment 2, reference may be made to embodiment 1, and details are not repeated here.

Mode 3: and determining whether a preset condition is met or not based on the system switching type indicated by the target event.

If the system switching type indicated by the target event is container switching, determining that a preset condition is met. If the system switching type indicated by the event is non-container switching, determining that the preset condition is not met.

For the description of the case c, reference may be made to the case b, which is not described herein.

S303: the computing device jumps from a container of the first operating system to the memory file system and jumps to a container running the operating system to be booted based on the memory file system. The operating system to be started comprises a first operating system or a second operating system.

It should be noted that, when the memory file system in S303 is the memory file system that is pulled up based on the kernel when the computing device performs the step of S301. In addition, the operating system to be started, the container to be started, and the like in the embodiments of the present application refer to the operating system to be started, the container to be started, and the like generally, and do not refer to a certain operating system, container, and the like.

In this embodiment of the present application, if the BMC unit currently meets the preset condition, the BMC unit jumps to the running memory file system from the container of the first operating system, and after jumping to the running memory file system, unlike in the related art, the BMC unit cuts off the path that was originally jumped to the ROM, that is, does not jump to run the ROM boot program any more, but jumps to the container running the operating system to be started based on the memory file system.

Illustratively, the container running the second operating system may include: and loading the partition of the second operating system into the memory of the BMC unit for running. The initial directory of the container of the second operating system is set to the root directory, i.e., set to the root directory of the second operating system. And then, jumping to a root directory of the second operating system through the color, and sequentially starting a plurality of application programs in a container of the second operating system through a system daemon in the container of the second operating system.

Illustratively, the BMC unit implements jumping the row memory file system from the container of the first operating system by invoking a jumping machine in the memory file system. The jump machine comprises a first jump module and a second jump module, wherein the first jump module jumps to a memory file system from a container, and the second jump module jumps to the memory file system from the container and jumps to a ROM guide program from the memory file system.

And under the condition that the preset condition is met, the BMC unit calls the first skip module, so that the skip from the container of the first operating system to the memory file system is realized. Since the first skip module does not include a step of skipping from the memory file system to the ROM boot program, in the case where the BMC unit calls the first skip module, after skipping from the container of the first operating system to the memory file system, the skip to the ROM boot program is not continued.

By way of example, the BMC unit may implement a jump to a container running the operating system to be started based on the memory file system by invoking a switch in the memory file system.

In this embodiment, in the process of running the memory file system by the BMC unit, the root directory of the first operating system and the partition where the container of the first operating system is located may be unloaded, so that after the BMC unit directly jumps from the memory file system to the container of the operating system to be started, the partition where the container to be started (i.e., the container of the operating system to be started) is located may be mounted, and the root directory may be mounted on the initial directory of the container to be started.

In the following, an exemplary description is given of a container of an operating system to be started, by way of the case a to the case c.

Case a: the container of the operating system to be started is the container which is currently in a non-running state.

When the currently running operating system is the first operating system, the currently running container is the container of the first operating system, and based on the fact, the currently running container is the container of the second operating system. That is, the container of the second operating system is the container of the operating system to be booted.

In case a, the BMC unit may determine the container of the second operating system as the container of the operating system to be booted.

Case b: the container of the operating system to be started is the container currently in the running state.

When the currently running operating system is the first operating system, the container currently in the running state is the container of the first operating system. That is, the container of the first operating system is the container of the operating system to be booted.

In case b, the BMC unit may determine the container of the first operating system as the container of the operating system to be booted.

Case c: the container of the operating system to be started is the container of the first operating system or the container of the second operating system.

The BMC unit is preconfigured with a system switching policy that may include switching to other operating systems than the current operating system or restarting the current operating system.

For example, the user may set the system switching policy to switch to another operating system than the current operating system or to restart the current operating system. Thus, after the BMC detects the target event, the BMC can execute subsequent operations according to the system switching strategy set by the user, such as: determining start-up configuration parameters, etc.

It should be noted that, the method for setting the system switching policy by the user is not limited in the embodiments of the present application. For example, by sending instructions to the processor, or in other ways.

In the following, taking the case a as an example, the procedure of determining the container to be started will be described in modes a to B.

Mode a: based on the boot configuration parameters, a container of the operating system to be booted is determined.

In this embodiment of the present application, the BMC unit may determine a container of the operating system to be started based on the startup configuration parameter.

For example, the BMC unit may determine a container of the operating system to be booted based on the boot configuration parameters and the boot correspondence. The starting correspondence may include a correspondence between a starting configuration parameter and an identifier of a container to be started.

In example 1, the start-up correspondence may include a correspondence to the second identifier when the start-up configuration parameter is the first identifier, that is, when the start-up configuration parameter is the first identifier, determining that the container to which the second identifier belongs is the container to be started.

In example 2, the starting correspondence may include a second identifier corresponding to the second identifier when the starting configuration parameter is the second identifier, that is, determining that the container to which the second identifier belongs is the container to be started when the starting configuration parameter is the second identifier.

In example 3, the start-up correspondence may include a corresponding first identifier when the start-up configuration parameter is empty, that is, when the start-up configuration parameter is empty, determining that the container to which the first identifier belongs is a container to be started.

In the embodiment of the present application, the startup configuration parameter is written to the storage medium when the target event occurs. That is, if the target event does not occur, the start configuration parameter is null.

Illustratively, after the BMC unit detects the occurrence of the target event, boot configuration parameters are written to a storage medium of the computing device for subsequent use in determining a container for an operating system to boot.

In an embodiment of the present application, the BMC unit includes a volatile storage medium. In case it is determined that the preset condition is satisfied, the BMC unit may write the startup configuration parameters in the volatile storage medium. In this way, the BMC unit may obtain boot configuration parameters from the volatile storage medium to determine the container of the operating system to boot.

When the preset condition is met, the BMC unit does not jump to run the ROM boot program, so that the BMC unit does not power down, and based on the startup configuration parameters stored in the volatile storage medium, the startup configuration parameters can be ensured to be acquired, and the startup configuration parameters in the volatile storage medium can be automatically cleared in the power down process after the BMC unit, so that the startup configuration parameters are prevented from occupying the storage space for a long time and affecting the normal startup flow of the operating system.

The volatile storage medium may be a memory of the BMC unit, which helps to increase the speed of reading and writing the configuration parameters, and further helps to increase the efficiency of switching the operating system.

In embodiments of the present application, the boot configuration parameters may include a container identifier, which may be used to indicate a container of the operating system to be booted. Alternatively, the boot configuration parameters may include an operating system identification that may be used to indicate the operating system to be booted, on the basis of which the processor may determine a container belonging to the operating system to be booted as the container to be booted.

It should be noted that, the embodiment of the present application does not limit the form of the startup configuration parameter, and the above is only exemplary. In the following, an exemplary embodiment of the present application will be described by taking an example in which the startup configuration parameters include a container identifier.

In the following, an exemplary description will be given of a procedure for determining a container of an operating system to be started when the startup configuration parameter is a container identifier through case a to case B.

Case a: the container identification is an identification of the first container (i.e., the container of the first operating system).

In combination with the above case a, after the BMC unit obtains the boot configuration parameter (i.e., the identifier of the first container), it may 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 booted.

Case B: the container identification is an identification of a second container (i.e., a container of a second operating system).

In combination with the above case a, after the BMC unit obtains the boot configuration parameter (i.e. the identifier of the second container), it may directly determine that the container to which the identifier of the second container belongs is the container of the operating system to be booted.

In another example, the boot configuration parameter may indicate an operating system identification,

it should be noted that, when the BMC unit configures only two operating systems, the container of the operating system to be started may be determined based on the above-described manner of the case a and the case B. When the BMC unit configures two or more operating systems, a container of the operating system to be started may be determined based on the manner in the above case B.

In the implementation manner, the container of the operating system to be started is determined by writing the starting configuration parameters of the storage medium in advance, so that the container of the operating system to be started is not required to be specified by a user, the use experience of the user is improved, and the convenience and the automation degree of switching the operating system are improved.

Mode B: based on the target event, a container of the operating system to be booted is determined.

In this embodiment, when the target event is a system handover request, the system handover request may include a container identifier. Based on this, the BMC unit may determine the container corresponding to the container identifier in the system switch request as the container to be started.

Illustratively, as shown in (a) of fig. 5, a first interface is displayed on the electronic device of the user, where the first interface includes a first control, and the first control is used to instruct the system to switch. The user selects the first control and clicks on the next control on the first interface, as shown in (b) in fig. 5, the electronic device responds to the operation of the user to display a second interface, and the second interface includes a second control, where the second control is used to indicate the container. After the user selects the second container (i.e., the container in which the operating system is to be started) on the second interface and clicks the next control on the second interface, the electronic device responds to the operation of the user and sends a system switching request to the computing device, where the system switching request includes the identifier of the second container.

It should be noted that, in the embodiment of the present application, the number of second controls is not limited, and the above is only exemplary. For example, the number of second controls may be the same as the number of operating systems configured by the BMC unit, thereby enabling the indication of a container of one operating system by one second control.

In this embodiment of the present application, when the target event is that the system upgrade is completed, the BMC unit may determine that the container performing the upgrade operation is a container of the operating system to be started. In this way, the accuracy and efficiency of determining the container for which the operating system is to be booted is facilitated.

Illustratively, the second operating system performs an upgrade operation, based on which the BMC unit may determine that the container of the second operating system is the container of the operating system to be booted.

In the implementation manner, the container of the operating system to be started is determined through the target event, so that the finally started operating system to be started is the operating system which the user wants to restart, and the use experience of the user is improved.

It should be noted that, the embodiments of the present application do not limit the execution sequence of "jump from container of the first operating system to the running memory file system" and "determine container of the operating system to be started".

S304: the computing device reloads the boot loader and kernel to run the container of the operating system to be booted.

In this embodiment, if the preset condition is not satisfied, the BMC unit of the computing device continues to jump from the memory file system to the running ROM boot program after jumping from the container of the first operating system to the running memory file system. After the BMC unit jumps to the ROM boot program, the memory file system generated based on the kernel in S501 is closed.

In an exemplary embodiment, if the preset condition is not met, the processor invokes 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. Since the second jump module includes steps of jumping from the container to the memory file system and jumping from the memory file system to the ROM boot, the ROM boot can be jumped from the memory file system in the event that the processor invokes the second jump module.

Since the ROM boot indicates the partition address of the boot loader, after jumping to the ROM boot, the BMC unit re-runs the boot loader and the kernel based on the partition address indicated by the ROM boot. In the process of running the kernel, the BMC unit regenerates the memory file system based on the kernel.

Example 1, in combination with mode 1 of the system architecture portion, the rom boot indicates a boot loader common to the first operating system and the second operating system, based on which the BMC unit runs the common boot loader, and based on the common boot loader, runs a kernel common to the first operating system and the second operating system, and then, based on the common kernel, generates the memory file system.

Example 2, in combination with mode 2 of the system architecture portion, the rom boot program may be indicated by a boot loader of the first operating system, or may be indicated by a boot loader of the second operating system, which is not limited in this embodiment of the present application.

For other descriptions of this example 2, reference may be made to the description of the above example 1, and the description is omitted here.

In the embodiment of the application, after the BMC unit regenerates the memory file system, determining the container of the operating system to be started, and jumping from the regenerated memory file system to the container of the operating system to be started, thereby realizing the operation of the operating system to be started.

The method of determining the container of the operating system to be started in S304 may refer to the method of determining the container of the operating system to be started in S303 described above by the BMC unit, which is not described herein.

In the following, only the differences between the two ways are described in detail, and the details of the same points between the two ways are not repeated.

In an embodiment of the present application, the BMC unit includes a nonvolatile storage medium. When it is determined that the preset condition is not satisfied, the BMC unit may write the startup configuration parameters into the nonvolatile storage medium. Thus, after the BMC unit regenerates the memory file system, the boot configuration parameters may be obtained from the nonvolatile storage medium to determine the container of the operating system to be booted.

In this embodiment, when the preset condition is met and when the preset condition is not met, the starting configuration parameters are written into different storage media, so that different system jump modes can use the starting configuration parameters stored in different storage media, and the accuracy of the operating system to be started is guaranteed. In addition, when the preset condition is not met, the starting configuration parameters are stored in the nonvolatile storage, so that the starting configuration parameters are prevented from being lost when the ROM boot program is returned, and further the switching reliability of the operating system is guaranteed.

In one example, the non-volatile storage medium may include a bare partition on a BMC unit. Such as: the memory device may be an embedded multimedia card (embedded multi media card, EMMC), a nand flash (NANDFLASH), a nor flash (norflast), a universal flash memory (universal flash storage, UFS), etc., and the BMC unit may divide a partial storage area of the memory device into a bare partition (which may also be referred to as a bare device (raw device) or an original partition), which may have no file system format. On this basis, the BMC unit can access the bare device through the fixed offset address of the bare device to acquire the start configuration parameters.

In another example, the non-volatile storage medium may include a user flash memory (user flash memory, UFM) on the programmable logic device. Such as: the programmable logic device may be a complex programmable logic device (Complex Programmable Logic Device, CPLD), a field programmable gate array (Field Programmable Gate Array, FPGA), or the like. The editable logic includes UFM storage space, where UFM storage space refers to flash storage space that can be used by a user. On the basis, the BMC unit can access the UFM storage space through an external access interface provided by the programmable logic device so as to acquire the starting configuration parameters.

For other descriptions of S304, reference may be made to S303, which is not described herein.

It should be noted that, the embodiments of the present application do not limit the execution sequence of "determine whether the computing device satisfies the preset condition" and "jump from the container of the first operating system to the running memory file system", which is merely illustrative. For example, the computing device may jump to the running memory file system first, then determine whether the preset condition is satisfied, and if so, jump to a container running the operating system to be started based on the memory file system. If not, reloading the boot loader and the kernel.

In the above embodiment, the computing device provides multiple jump modes, when the operating system needs to be switched, if the computing device meets the preset condition, the computing device jumps from the container of the first operating system to the memory file system, and then does not continue to jump to run the ROM boot program, but directly switches from the memory file system to the container running the operating system to be started. If the preset condition is not met, the computing device jumps to the running memory file system from the container of the first operating system, and then continues to jump to the running ROM boot program, so that the boot loader and the kernel are restarted according to the partition address indicated by the ROM boot program, the container of the operating system to be started is started, and full-quantity starting of the operating system to be started is achieved. Therefore, not only is the diversity of the jump mode improved, but also the proper jump mode is selected according to the actual scene, and further the stability and the reliability of the operation system to be started are improved after the operation system to be started subsequently.

Fig. 6 is a schematic diagram of an operating system jump according to an embodiment of the present application. An exemplary operating system jump procedure provided in the embodiments of the present application is described below with reference to fig. 6.

Illustratively, when the BMC unit runs a container (also referred to as an original container) of the first operating system, the user triggers a target event, such as: triggering system upgrade or system switching, and after detecting a target event, executing closing operation on a plurality of application programs in a container of the first operating system by the BMC unit so as to close the plurality of application programs in the container of the first operating system. And then, the BMC unit determines whether a preset condition is met, if so, the BMC unit executes a container starting flow, and if not, the BMC unit executes a non-container switching flow (namely a full starting flow).

If the BMC unit executes the container starting flow, the BMC unit jumps from the container of the first operating system to the memory file system of the first operating system, and then does not jump to the running ROM boot program, but stays in the stage of running the memory file system of the first operating system. In the process of running the memory file system of the first operating system, the BMC unit writes the starting configuration parameters into the volatile storage medium, and uninstalls the root directory of the first operating system and the partition where the container of the first operating system is located.

If the full boot flow is executed, the BMC jumps from the container of the first operating system to the memory file system of the first operating system, writes the boot configuration parameters into the nonvolatile storage medium during the running of the memory file system of the first operating system, then continues to jump to the ROM to return to the ROM boot program, and then reloads the boot loader, the kernel and the memory file system based on the partition address indicated by the ROM boot program.

On the basis, in the process of running the original memory file system or the reloaded memory file system, the BMC unit acquires the starting configuration parameters and determines a container of the operating system to be started based on the starting configuration parameters. For example, if the starting configuration parameter is the identifier of the first container or NULL (NULL), the BMC unit runs the first container, i.e. mounts the partition corresponding to the first container (i.e. the partition where the first container is located), and mounts the initial directory of the first container as the root directory. If the starting configuration parameter is the identifier of the second container, the BMC unit operates the second container, namely, mounts a partition corresponding to the second container (namely, the partition where the second container is located), and mounts the initial directory of the second container as the root directory.

The BMC unit then jumps to the root directory environment via a color, such as: and if the starting configuration parameter indicates the identification of the second container, the BMC unit jumps to a root directory corresponding to the initial directory of the second container, and starts a plurality of application programs in the second container through a system daemon in the second container.

The foregoing description of the solution provided in the embodiments of the present application has been mainly presented in terms of a method. To achieve the above functions, the system jump device includes a hardware structure and/or a software module for executing each function. Those of skill in the art will readily appreciate that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is implemented as hardware or computer software driven hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiment of the present application, according to the above method, the system jump device may be exemplarily divided into functional modules, for example, the system jump device may include each functional module corresponding to each functional division, or two or more functions may be integrated into one processing module. The integrated modules may be implemented in hardware or in software functional modules. It should be noted that, in the embodiment of the present application, the division of the modules is schematic, which is merely a logic function division, and other division manners may be implemented in actual implementation.

By way of example, fig. 7 shows a schematic diagram of one possible architecture of an operating system jump device (denoted as operating system jump device 700) as referred to in the above embodiments, where actions performed by the system jump device are implemented by a computing device or by the computing device executing corresponding software. The computing device includes a first operating system and a second operating system that use the same boot loader, kernel, and memory file system. The operating system jumping apparatus 700 may include a running module 701, a judging module 702, a first jumping module 703, and a second jumping module 704. The running module 701 is configured to load a boot loader and a kernel, thereby running a container of the first operating system. As shown in fig. 3, S301. The judging module 702 is configured to judge whether the computing device meets a preset condition when the occurrence of the target event is detected. As shown in fig. 3 at S302. The first jump module 703 is configured to jump to the memory file system from the container of the first operating system if the preset condition is met, and jump to the container running the operating system to be started based on the memory file system. As shown in fig. 3 at S303. A second skip module 704, configured to reload the boot loader and the kernel if the preset condition is not satisfied, thereby running a container of the operating system to be started; the operating system to be started comprises a first operating system or a second operating system. As shown in fig. 3 at S304.

Optionally, the container of the first operating system includes a plurality of applications; meeting the preset conditions includes: the closing operation of the plurality of application programs satisfies the target condition.

Optionally, the container of the first operating system includes a plurality of applications; meeting the preset conditions includes: the closing operation of the plurality of application programs meets the target conditions and the system switching type indicated by the target event is container switching; the container switch is used for indicating the container loading the operating system to be started in the system switch process.

Optionally, the closing operation of the plurality of applications satisfies the target condition, including: the plurality of applications may be successfully closed and/or the order of closing the plurality of applications may be reversed from the order of starting the plurality of applications.

Optionally, the preset condition is not satisfied, including: the closing operation of the plurality of application programs does not meet the target condition, and/or the system switching type indicated by the target event is non-container switching; the non-container switch is used for indicating the loading of the boot loader, the kernel and the container of the operating system to be started in the system switch process.

Optionally, detecting the occurrence of the target event includes: a system handoff request is detected.

Optionally, detecting the occurrence of the target event includes: and detecting that the system upgrade is finished.

Optionally, the bootloader used by the first operating system and the second operating system is the same as the kernel, including: the first operating system and the second operating system share the same boot loader and kernel; alternatively, the code of the boot loader of the first operating system is the same as the code of the boot loader of the second operating system, and the code of the kernel of the first operating system is the same as the code of the kernel of the second operating system.

For a specific description of the above alternative modes, reference may be made to the foregoing method embodiments, and details are not repeated here. In addition, any explanation and description of the beneficial effects of the operating system jump apparatus 700 provided above may refer to the corresponding method embodiments described above, and will not be repeated.

The embodiment of the application also provides a computing device, which comprises a processor and a memory, wherein the processor is connected with the memory, the memory stores computer execution instructions, and the system switching method in the embodiment is realized when the processor executes the computer execution instructions.

Embodiments of the present application also provide a computer-readable storage medium having a computer program stored thereon, which when run on a computing device, causes the computer to perform the method performed by any one of the computing devices provided above.

For the explanation of the relevant content and the description of the beneficial effects in any of the above-mentioned computer-readable storage media, reference may be made to the above-mentioned corresponding embodiments, and the description thereof will not be repeated here.

The embodiment of the application also provides a chip. The chip has integrated therein control circuitry and one or more ports for implementing the functions of the computer device described above. Optionally, the functions supported by the chip may be referred to above, and will not be described herein.

Those of ordinary skill in the art will appreciate that all or a portion of the steps implementing the above-described embodiments may be implemented by a program to instruct associated hardware. The program may be stored in a computer readable storage medium. The above-mentioned storage medium may be a read-only memory, a random access memory, or the like. The processing unit or processor may be a central processing unit, a general purpose processor, an application specific integrated circuit (application specific integrated circuit, ASIC), a microprocessor (digital signal processor, DSP), a field programmable gate array (field programmable gate array, FPGA) or other programmable logic device, transistor logic device, hardware components, or any combination thereof.

Embodiments of the present application also provide a computer program product comprising instructions which, when run on a computer, cause the computer to perform any of the methods of the above embodiments. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions in accordance with embodiments of the present application are produced in whole or in part. It should be noted that the above-mentioned devices for storing computer instructions or computer programs, such as, but not limited to, the above-mentioned memories, computer-readable storage media, communication chips, and the like, provided in the embodiments of the present application all have non-volatility (non-transparency).

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using a software program, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions in accordance with embodiments of the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus.

The computer instructions may be stored in or transmitted from one computer-readable storage medium to another, for example, a website, computer, server, or data center via a wired (e.g., coaxial cable, fiber optic, digital subscriber line (digital subscriber line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. Computer readable storage media can be any available media that can be accessed by a computer or data storage devices including one or more servers, data centers, etc. that can be integrated with the media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk), etc.

Although the present application has been described herein in connection with various embodiments, other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed application, from a review of the figures, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the "a" or "an" does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Although the present application has been described in connection with specific features and embodiments thereof, it will be apparent that various modifications and combinations can be made without departing from the spirit and scope of the application. Accordingly, the specification and drawings are merely exemplary illustrations of the present application as defined in the appended claims and are considered to cover any and all modifications, variations, combinations, or equivalents that fall within the scope of the present application. It will be apparent to those skilled in the art that various modifications and variations can be made in the present application without departing from the spirit or scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims and the equivalents thereof, the present application is intended to cover such modifications and variations.

Claims

1. An operating system jump method for a computing device, the computing device comprising 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 boot loader, the kernel and the memory file system used by the first operating system and the second operating system are the same; the method comprises the following steps:

Loading the boot loader and the kernel, thereby running a container of the first operating system;

when detecting that a target event occurs, judging whether the computing equipment meets a preset condition or not;

if the preset condition is met, jumping to run the memory file system from the container of the first operating system, and jumping to run the container of the operating system to be started based on the memory file system;

if the preset condition is not met, reloading the boot loader and the kernel, so as to run the container of the operating system to be started; the operating system to be started comprises the first operating system or the second operating system.

2. The method of claim 1, wherein the step of determining the position of the substrate comprises,

the container of the first operating system includes a plurality of applications; the meeting the preset condition includes: the closing operation of the plurality of application programs satisfies a target condition.

3. The method of claim 1, wherein the step of determining the position of the substrate comprises,

the container of the first operating system includes a plurality of applications; the meeting the preset condition includes: the closing operation of the plurality of application programs meets a target condition and the system switching type indicated by the target event is container switching; and the container switching is used for indicating the container loading the operating system to be started in the system switching process.

4. A method according to claim 2 or 3, characterized in that,

the closing operation of the plurality of application programs satisfies a target condition, including: the plurality of applications are successfully closed, and/or the closing sequence of the plurality of applications is opposite to the starting sequence of the plurality of applications.

5. The method according to any one of claims 1 to 4, wherein,

the failing to meet the preset condition includes: the closing operation of the plurality of application programs does not meet the target condition, and/or the system switching type indicated by the target event is non-container switching; and the non-container switching is used for indicating the loading of the boot loader, the kernel and the container of the operating system to be started in the system switching process.

6. The method of any one of claims 1-5, wherein the detecting of the occurrence of the target event comprises:

a system handoff request is detected.

7. The method of any one of claims 1-5, wherein the detecting of the occurrence of the target event comprises:

and detecting that the system upgrade is finished.

8. The method according to any one of claims 1 to 7, wherein,

The bootloader used by the first operating system and the second operating system is the same as the kernel, and the bootloader comprises:

the first operating system and the second operating system share the same boot loader and kernel; alternatively, the code of the boot loader of the first operating system is the same as the code of the boot loader of the second operating system, and the code of the kernel of the first operating system is the same as the code of the kernel of the second operating system.

9. A chip, comprising: the device comprises a processor and a memory, wherein the processor is connected with the memory; the memory is configured to store computer-executable instructions, and the processor executes the computer-executable instructions stored in the memory to cause the chip to implement the method of any one of claims 1-8.

10. A computing device, comprising: a power supply for supplying power to the chip and a chip as claimed in claim 9 for implementing the method as claimed in any of claims 1-8.