System loading method and device, electronic equipment and readable storage medium

Abstract

The embodiment of the invention provides a system loading method and device, electronic equipment and a readable storage medium, and the method comprises the steps: distributing a corresponding hardware resource partition for each operation system when computer equipment is started; the number of the operating systems is greater than 1; in each hardware resource partition, respectively loading and starting an operating system kernel of the operating system; monitoring a triggered system selection instruction, taking a first operating system corresponding to the system selection instruction as a main operating system, and stopping running operating system kernels of other operating systems; and running the main operating system by using the hardware resource partition corresponding to the main operating system. According to the embodiment of the invention, operation system switching can be quickly realized in the operation process of the computer equipment, and the working efficiency of a user is improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a system loading method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] As computer applications become increasingly complex, users' demands for diverse operating systems are constantly growing. Installing multiple operating systems on the same computer device has become a common solution to meet different work, entertainment, and development needs. For example, developers may need to develop code on one operating system while using specific office software on another; or enterprise users may need to run a work operating system and a personal entertainment operating system with security isolation on a single computer.

[0003] In related technologies, if a user needs to switch operating systems, they must restart the computer, select a new operating system during the boot process, and then wait for the computer to complete initialization based on the new operating system before the switch is finalized. This entire process is time-consuming and significantly reduces switching efficiency. Summary of the Invention

[0004] In view of the above problems, embodiments of the present invention are proposed to provide a system loading method that overcomes or at least partially solves the above problems, enabling rapid switching to different operating systems while the computer device is running, thereby improving the user experience.

[0005] Accordingly, embodiments of the present invention also provide a system loading device, an electronic device, and a readable storage medium to ensure the implementation and application of the above methods.

[0006] In a first aspect, embodiments of the present invention disclose a system loading method applied to a computer device, the method comprising: When a computer device starts up, a corresponding hardware resource partition is allocated to each operating system; the number of operating systems is greater than one. In each hardware resource partition, the operating system kernel of the operating system is loaded and started respectively; Monitor the triggered system selection command, select the first operating system corresponding to the system selection command as the main operating system, and stop running the operating system kernels of other operating systems; The main operating system is run using the hardware resource partition corresponding to the main operating system.

[0007] Secondly, embodiments of the present invention disclose a system loading device, the system loading device comprising: The resource allocation module allocates a corresponding hardware resource partition to each operating system when the computer device starts up; the number of operating systems is greater than 1. The kernel loading module is used to load and start the operating system kernel of the operating system in each hardware resource partition, respectively. The system determination module is used to monitor the triggered system selection command, select the first operating system corresponding to the system selection command as the main operating system, and stop running the operating system kernels of other operating systems. The system operation module is used to run the main operating system by utilizing the hardware resource partitions corresponding to the main operating system.

[0008] Thirdly, embodiments of the present invention disclose an electronic device, including: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; the memory is used to store at least one executable instruction, wherein the executable instruction causes the processor to perform the steps of any of the system loading methods described above.

[0009] Fourthly, embodiments of the present invention disclose a readable storage medium storing a program or instructions, which, when executed by a processor, can implement any of the system loading methods described above.

[0010] Fifthly, embodiments of the present invention disclose a computer program product, including a computer program, wherein when the computer program is executed by a processor, the steps of the system loading method described in any of the foregoing are as follows.

[0011] The system loading method, apparatus, electronic device, and readable storage medium of this invention divide the hardware resources of a computer device. Upon startup, multiple operating system kernels can be loaded and started in parallel across multiple different hardware resource partitions. Then, one of these kernels can be selected as the primary operating system based on system selection instructions. Because multiple operating system kernels are pre-loaded, when switching operating systems during computer operation as needed by the user, the currently running operating system kernel can be disabled while another pre-loaded operating system kernel is enabled, quickly achieving system switching without requiring a device reboot or other methods to reload a new operating system, thus accelerating the operating system switching speed. Attached Figure Description

[0012] Figure 1 This is a flowchart illustrating the steps of an embodiment of a system loading method according to this application; Figure 2 This is a schematic diagram of CPU hardware resource allocation provided in an embodiment of this application; Figure 3This is a schematic diagram of memory hardware resource allocation provided in an embodiment of this application; Figure 4 This is a schematic diagram of a computer startup process provided in an embodiment of this application; Figure 5 This is a schematic diagram of a hardware resource partitioning provided in an embodiment of this application; Figure 6 This is a schematic diagram illustrating an operating system switching method provided in an embodiment of this application; Figure 7 This is a structural block diagram of an embodiment of a system loading device according to this application; Figure 8 This is a schematic diagram of the structure of the electronic device provided in an embodiment of the present invention. Detailed Implementation

[0013] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0014] Reference Figure 1 The diagram illustrates a flowchart of an embodiment of a system loading method according to the present invention. The method is applied to a computer device and may include the following steps: Step 101: When the computer device starts up, allocate corresponding hardware resource partitions for each operating system; the number of operating systems is greater than 1. Step 102: In each hardware resource partition, load and start the operating system kernel of the operating system respectively; Step 103: Monitor the triggered system selection command, select the first operating system corresponding to the system selection command as the main operating system, and stop running the operating system kernels of other operating systems; Step 104: Run the main operating system using the hardware resource partition corresponding to the main operating system.

[0015] In this embodiment, during the computer startup phase, corresponding hardware resource partitions are allocated for different operating systems, allowing different operating system kernels to be loaded into their respective partitions on the computer hardware. This means the computer device can simultaneously load and start multiple operating system kernels. After multiple operating system kernels start, a system selection command triggered by the user is received. The kernels of unselected operating systems are stopped, and only the kernel of the selected primary operating system is run (for example, when the computer device starts, multiple operating system kernels start simultaneously; upon receiving the user's system selection command, a pause signal is sent to the kernels of the unselected operating systems, causing them to stop running). Then, the computer device enters its running phase based on the primary operating system, allowing the user to achieve their operational goals through the primary operating system. Since all operating system kernels are loaded during computer startup, there is no need to reboot to load other operating system kernels during computer operation. The loaded kernels can be directly enabled and disabled, thus quickly switching between operating systems on the same computer device.

[0016] Specifically, steps 101 and 102 can be added to the computer boot process by modifying the computer boot firmware. This can be achieved, for example, by modifying or adding code segments to the computer boot firmware.

[0017] It is understandable that the number of operating systems that can be loaded onto a computer device is greater than one. This means that hardware resource partitions can be allocated for multiple operating systems, enabling the current computer to load various operating systems. Loadable operating systems include, for example, Loongnix, UOS, Windows, or macOS, and can be selected according to user needs; there is no limitation on the specific type of operating system that can be loaded.

[0018] After the hardware resource partitions are allocated, the corresponding operating system kernel is loaded into each partition. It's understood that each hardware resource partition includes at least memory and CPU hardware resources, with the operating system kernel loaded into the memory hardware resources. After loading, the operating system kernel executes its boot process. Successful boot of the operating system kernel proves that it was successfully loaded and can run normally.

[0019] When allocating hardware resource partitions, preset allocation rules can be used. These rules can be, for example, an average allocation rule, or a custom allocation rule based on different operating systems. Custom allocation rules can be, for example, pre-defined memory and CPU hardware resource sizes for different operating systems, i.e., hardware resource partition sizes.

[0020] It is understandable that hardware resource partitions include memory hardware resources and CPU hardware resources, i.e., memory areas and CPU areas in a computer device. After calculating the hardware resource partitions that need to be allocated to different operating systems, unique identifiers for each operating system are added to the memory hardware resources and CPU hardware resources within the hardware resource partitions through the memory management protocol interface and the CPU task scheduler, respectively. For example, the ID of the CPU core (1, 2, 3, 4, etc.) which is a CPU hardware resource is bound to the unique identifier of the operating system. At the same time, the starting address of each segment of the memory space which is a memory hardware resource, the size of the space after the starting address, etc., are bound to the unique identifier of the operating system to identify which operating system the hardware resource partition is allocated to. The bound correspondence is stored so that the corresponding hardware resource partition can be called by the operating system when it runs.

[0021] To ensure successful operating system switching, this application loads and starts the corresponding operating system kernel in each hardware resource partition, then verifies whether each operating system kernel can boot normally. If a kernel boots normally, the loading is considered successful. For operating system kernels that fail to boot, the loading and booting operations are re-executed to ensure that during normal computer operation, when switching operating systems by enabling or disabling the kernel, each kernel can be enabled or disabled normally. This avoids operating system switching failures due to faults during kernel loading.

[0022] In practical applications, the progress of the operating system kernel loading and booting can be obtained by reading the event notification mechanism in the UEFI (Unified Extensible Firmware Interface) firmware, thus confirming whether the operating system kernel can load and boot normally. Alternatively, information such as screen display characters, disk blinking, and memory address changes in the BIOS firmware can be analyzed to confirm whether the operating system kernel can load and boot normally. For example, if boot confirmation is performed through the UEFI event notification mechanism, the loading protocol (such as EFI_LOADED_IMAGE_PROTOCOL) will be monitored during the UEFI boot service phase. After the operating system kernel is loaded, a state change of the loading protocol will be triggered, and the value of the loading status flag (such as EFI_BOOT_PROGRESS_EVT) will be set to 0x01 and passed to the callback function. The callback function is used to analyze and record the loading status flag and perform corresponding automated processing based on the analysis results. For example, if the callback function reads the value of the loading status flag as 0x01, it records "operating system kernel loading complete" and starts the boot process; if the callback function subsequently receives 0x02, it confirms "operating system kernel boot complete normally"; if it receives 0xFF, it determines "kernel loading and boot failure".

[0023] After the operating system kernel has finished loading and booting, the computer device will receive the user's system selection command to determine the primary operating system. For example, after the operating system kernel has finished loading, the computer device will display an operating system selection interface for multiple loadable operating systems, allowing the user to select the primary operating system from the one corresponding to the loaded operating system kernel.

[0024] For example, according to the system selection instruction, the first operating system selected by the system selection instruction is designated as the primary operating system, while the operating system kernels of the operating systems not selected by the system selection instruction are stopped. This ensures that only the operating system kernel of the primary operating system runs normally on the current computer device. At this point, the initialization of the current computer device can be completed based on the operating system kernel of the primary operating system, and the current computer device can enter the running state. The stopping of the unselected operating system kernels can be due to receiving a stop instruction, which can be generated autonomously based on the system selection instruction; that is, the system selection instruction will provide the operating system kernel of the selected primary operating system, and the computer device will generate a stop instruction and send it to the other operating system kernels besides the primary operating system. It is understandable that the stopped operating system kernels can restore the running state of each process before stopping upon receiving a subsequent boot signal. For example, the running state of each process can be maintained or stored before stopping, and upon receiving a relevant boot signal, the running states of each process can be restored according to the stored process running states.

[0025] Specifically, this can be achieved by sending a SIGSTOP signal to the kernel of the unselected operating system. The SIGSTOP signal is obtained by iterating through the processes of the unselected operating system, including the process identifiers (PIDs) of all processes. Upon receiving the SIGSTOP signal, the operating system kernel sets the processes pointed to by the SIGSTOP signal (i.e., all processes corresponding to the unselected operating system) to a hibernation state. Simultaneously, the operating system kernel automatically stops running after detecting that all processes corresponding to the SIGSTOP signal are in a hibernation state. At this point, if other programs detect that all processes corresponding to this operating system are in a hibernation state, they indirectly indicate that the operating system kernel has stopped running.

[0026] Furthermore, for the main operating system, it runs through the hardware resource partition corresponding to the main operating system.

[0027] In some cases, the parameters of the main operating system are loaded only into the hardware resource partition corresponding to the main operating system and run only in that partition. For example, when the computer starts, a hardware resource partition m is allocated to the first operating system and a hardware resource partition n is allocated to the second operating system. If the first operating system is the main operating system, it runs in hardware resource partition m; if the main operating system is switched to the second operating system, it runs in hardware resource partition n. The correspondence between the first operating system and hardware resource partition n, and between the second operating system and hardware resource partition m, can remain completely unchanged during the operation of the computer. That is, different operating systems have corresponding hardware resource partitions and run only in their corresponding hardware resource partitions. There is no step of loading relevant operating parameters across hardware resource partitions, which avoids mutual contamination of relevant parameters between different operating systems and maintains the stable operation of the main operating system.

[0028] In related technologies, a computer device can only load one operating system per boot. Switching operating systems requires a shutdown and restart, followed by selecting a different operating system during the new boot phase. However, this implementation divides the computer device's hardware resources, allowing multiple operating system kernels to be loaded and started in parallel across different hardware resource partitions during boot. One of these kernels can then be selected as the primary operating system based on system selection instructions. Because multiple operating system kernels are pre-loaded, switching operating systems during operation can be achieved quickly by disabling the currently running kernel and enabling another pre-loaded kernel, eliminating the need for a device reboot to reload the operating system. This significantly speeds up the operating system switching process.

[0029] Understandably, before allocating corresponding hardware resource partitions to each operating system, the availability of the current computer's hardware resources can be identified, faulty components can be eliminated, and only available hardware resources can be allocated to each operating system. This ensures that the hardware resource partitions allocated to each operating system can support its normal operation.

[0030] Furthermore, allocating corresponding hardware resource partitions for each operating system can include: Following a pre-defined average allocation principle, hardware resources are allocated equally to each operating system, resulting in hardware resource partitions of the same size corresponding to each operating system. That is, it is possible to choose to allocate hardware resource partitions of completely equal size to each operating system. In one example, two operating systems are loaded into the computer device, designated as Operating System 1 and Operating System 2. The computer device's CPU chip has four cores (cores 1 to 4), and the memory chip has a total size of 16GB. When allocating corresponding hardware resource partitions to each operating system, two CPU cores and 8GB of memory space are allocated to each operating system.

[0031] like Figure 2 As shown, taking a certain model of quad-core CPU as an example, CPU cores 1 and 2 are assigned to the first operating system, and CPU cores 3 and 4 are assigned to the second operating system. It is understood that the CPU hardware resources assigned to the same operating system are not limited to contiguous access; therefore, cores 1 and 4, which are physically far apart, can also be assigned to the first operating system.

[0032] like Figure 3 As shown, addresses 1-8GB of the memory chip are allocated to the first operating system, and addresses 9-16GB of the memory chip are allocated to the second operating system. It is understood that the memory hardware resources allocated to the same operating system do not need to be contiguous; therefore, addresses 1-3GB, 7th, 9th, 10th, and 15-16thGB can also be allocated to the first operating system, as long as the total size is the required 8GB.

[0033] Specifically, a unique identifier for the first operating system (e.g., 0x0001 or other custom identifier) ​​can be added to CPU cores 1-2 via the CPU task scheduler, and the first operating system's unique identifier can be added to 1-8GB of the memory chip via the memory management protocol interface, thus allocating CPU cores 1-2 and 1-8GB of the memory chip to the first operating system. Adding the first operating system's identifier can involve binding the CPU core IDs (1, 2, etc.) to this identifier, and binding the starting address and size of each segment of the memory space to this identifier; the binding results can be stored as needed in flash memory (a non-volatile storage medium) or a temporary storage area. In this case, the basic hardware resources corresponding to the first operating system can be the 1GB of the memory chip (at this point, the operating system kernel of the first operating system occupies a total of 1GB of memory space), and the flexible hardware resources can be, for example, the 2nd to 8th GB of the memory chip and CPU cores 1 and 2.

[0034] In some cases, the number of operating systems a computer device can support can be determined based on the number of CPU cores and the available space in the memory chips. For example, when choosing the number of operating systems, it is ensured that the number of CPU cores is divisible by the number of operating systems, and that the available space in the memory chips is also divisible by the number of operating systems.

[0035] In this embodiment, an average allocation rule is adopted for the allocation of hardware resource partitions. This configuration rule is simple and easy to program. At the same time, the allocation logic is simple and the allocation result is not prone to errors.

[0036] In one example, the method may further include: S11, in response to the system switching command, a pause signal is sent to the operating system kernel of the first operating system to stop running the operating system kernel of the first operating system; S12, a startup signal is sent to the operating system kernel of the second operating system indicated by the system switching instruction, and the second operating system is used as the main operating system.

[0037] During normal computer operation, if a user needs to switch operating systems, the user can actively send a system switching command to the computer device, such as by directly entering a command line, which serves as the system switching command; alternatively, the computer device will provide an interface for system selection, where the user can make a choice, and the selection result can further generate a computer-readable system switching command. The system switching command includes the operating system to which the user needs to switch, i.e., the new main operating system.

[0038] Upon receiving a system switch command instructing the switching of the primary operating system from the current first operating system to the second operating system, a pause signal is first sent to the kernel of the first operating system, causing the kernel to stop running and all processes of the first operating system to enter a dormant state. Simultaneously, a start signal is sent to the kernel of the second operating system, causing it to restart, thus completing the switch of the computer device's primary operating system (i.e., the only operating system running on the computer device at any given time) from the first operating system to the second operating system.

[0039] The system switch instruction instructs the main operating system to switch from the currently running operating system (the first operating system) to another operating system; in this embodiment, the first operating system is switched to the second operating system. Based on the information contained in the system switch instruction, a pause signal is sent to the first operating system, and a start signal is sent to the second operating system. The pause and start signals can be sent via system calls such as `kill()`. Upon receiving a pause or start signal, the operating system kernel immediately returns a value to indicate whether the signal was successfully received. For example, a return value of 0 indicates that the operating system kernel has successfully received and begun processing the sent pause or start signal; a return value of -1 indicates that the operating system kernel did not receive the signal. Furthermore, upon receiving the pause instruction, the kernel of the first operating system changes the process state of all processes corresponding to the first operating system identified by the pause instruction to a dormant state.

[0040] For example, a startup signal is the SIGCONT signal. Upon receiving the SIGCONT signal, the operating system kernel begins execution and changes the process state of the relevant process based on the process identifier carried in the SIGCONT signal.

[0041] It is understandable that step 103 could also involve sending the pause signal to the operating system kernel of the unselected operating system to stop the operation of the operating system kernel of the unselected operating system.

[0042] In some cases, the kernel of the primary operating system, acting as the main operating system, immediately stops running upon receiving a pause signal. If the hardware resource partition corresponding to the primary operating system remains constant throughout the computer's operation, parameters related to its running state before stopping (such as process state or file processing state) can be stored in that hardware resource partition. After the operating system kernel restarts based on the boot signal, it can restore the running state of the primary operating system before stopping based on the parameters of the running state in that hardware resource partition. Upon receiving a boot signal, the kernel of the secondary operating system, using the process information carried by the boot signal, will run the relevant processes of the secondary operating system in the hardware resource partition corresponding to the secondary operating system, without affecting or intruding on the hardware resource partition corresponding to the primary operating system.

[0043] In this implementation, by sending pause and start signals to the operating system kernel, the switching of the operating system can be completed quickly, without the need for a shutdown and restart to load a different operating system. This speeds up the operating system switching process and improves the user experience.

[0044] In an optional embodiment of the present invention, the hardware resource partition includes basic hardware resources and flexible hardware resources, and the step of loading and starting the operating system kernel corresponding to the operating system may further include: S21, in each hardware resource partition, the operating system kernel of the corresponding operating system is loaded and started according to the basic hardware resources; Running the main operating system using the hardware resource partition corresponding to the main operating system includes: S22, the main operating system is run using the basic hardware resources and the idle elastic hardware resources in all hardware resource partitions.

[0045] In this embodiment, when a computer device selects or switches operating systems, it can also simultaneously reallocate the corresponding hardware resources. For example, for operating systems that are not the main operating system, only their operating system kernel and the hardware resources occupied by the operating system kernel (i.e., basic hardware resources) are retained, and their corresponding elastic hardware resources are no longer occupied. This allows the main operating system to obtain more hardware resources to run, improving the operating efficiency of the main operating system.

[0046] Specifically, in this example, hardware resources are partitioned into basic hardware resources and flexible hardware resources. Basic hardware resources are used to load the operating system kernel, while flexible hardware resources can work in conjunction with the operating system kernel within the basic hardware resources to enable the computer to run. The basic hardware resources include memory hardware resources, which are specifically dedicated to loading the operating system kernel; the flexible hardware resources include CPU hardware resources and memory hardware resources not used by the operating system kernel.

[0047] For example, consider the operating systems loaded onto a computer device as the first and second operating systems, and the computer device's CPU includes cores 1 to 4. The available space of the memory chip in the computer device is 16GB, and the hardware resources are partitioned according to an average allocation principle. Cores 1 and 2 of the CPU can be allocated to the first operating system, and the first 8GB of the memory chip's address space can also be allocated to the first operating system. Cores 3 and 4 of the CPU can be allocated to the second operating system, and the 9th to 16th GB of the memory chip's address space can also be allocated to the second operating system. In this case, the basic hardware resources corresponding to the first operating system can be the 1GB of the memory chip (when the operating system kernel of the first operating system occupies a total of 1GB of space), and the flexible hardware resources can be, for example, the 2nd to 8th GB of the memory chip and cores 1 and 2 of the CPU. The basic hardware resources corresponding to the second operating system can be the 9th GB of the memory chip (when the operating system kernel of the second operating system occupies a total of 1GB of space), and the flexible hardware resources can be, for example, the 10th to 16th GB of the memory chip and cores 3 and 4 of the CPU.

[0048] It is understood that the above is merely an illustrative example and does not limit the specific location of the basic hardware resources. The basic hardware resources of the first operating system can be any location within the allocated memory address range of 1 to 8GB, depending on the location where the operating system kernel is loaded. For example, if the operating system kernel of the first operating system is stored in the allocated memory address range of 5.5GB to 6.5GB, then the basic hardware resources corresponding to the first operating system are the memory chip's 5.5GB to 6.5GB range, a total of 1GB; in this case, the flexible hardware resources corresponding to the first operating system are the memory chip's 1 to 5.5GB, 6.5 to 8GB, and CPU cores 1 and 2.

[0049] After allocating hardware resource partitions to each operating system, the corresponding operating system kernel is loaded and started in the basic hardware resources. If the first operating system is selected as the primary operating system in the system selection instruction, it can utilize its corresponding basic hardware resources and all available elastic hardware resources in the computer device to run. The available elastic hardware resources include those corresponding to the first operating system, as well as those corresponding to the second and third operating systems, and other operating systems that were not selected as the primary operating system.

[0050] At this point, the basic hardware resources corresponding to the other unselected operating systems are preserved, that is, the operating system kernels corresponding to the other unselected operating systems are preserved, enabling rapid switching of the main operating system during subsequent operation. Preserving the basic hardware resources of the unselected operating systems means that after selecting one operating system as the main operating system and running its operating system kernel, the operating system kernels of other loaded but unselected operating systems are not deleted.

[0051] The data structures corresponding to the operating system kernel include: hardware resource data status, hardware structure data status, process data status, and kernel status.

[0052] In this embodiment, the hardware resource data states corresponding to the operating system kernels of unselected operating systems include: kernel reserved state (e.g., using the EfiReserved identifier) ​​and available / idle state (e.g., using the EfiConventionalMemory identifier), or runtime service state (e.g., using the EfiRuntimeServicesData identifier). The kernel reserved state corresponds to the basic hardware resource portion, indicating that the memory region is reserved by the kernel and allocation is prohibited; the available / idle state corresponds to a region that can be allocated to the main operating system; the runtime service state corresponds to a region that needs to be retained throughout system operation. Hardware structure data states include: memory chip availability identifier and hard disk availability identifier. For process data states, all processes outside the main operating system are in a dormant state. For operating system kernel states, all operating system kernels outside the main operating system are in a SUSPEND dormant state, indicating a pause in operation.

[0053] For example, if the operating systems loaded into the computer device include a first operating system, a second operating system, and a third operating system, the hardware resource partitions allocated to each of these operating systems include: basic hardware resources X1 and flexible hardware resources Y1 corresponding to the first operating system; basic hardware resources X2 and flexible hardware resources Y2 corresponding to the second operating system; and basic hardware resources X3 and flexible hardware resources Y3 corresponding to the third operating system. Specifically, basic hardware resource X1 includes memory hardware resource a, and flexible hardware resource Y1 includes memory hardware resource a' and CPU hardware resource b; basic hardware resource X2 includes memory hardware resource c, and flexible hardware resource Y2 includes memory hardware resource c' and CPU hardware resource d; basic hardware resource X3 includes memory hardware resource e, and flexible hardware resource Y3 includes memory hardware resource e' and CPU hardware resource f.

[0054] After the hardware resources are partitioned and allocated, the operating system kernel of the first operating system will be loaded in the basic hardware resource X1, the operating system kernel of the second operating system will be loaded in the basic hardware resource X2, and the operating system kernel of the third operating system will be loaded in the basic hardware resource X3.

[0055] When the system selection instruction selects the first operating system as the primary operating system, in response to the instruction, not only are the operating system kernels of the second and third operating systems stopped running, but the second and third operating systems also cease to occupy their corresponding elastic hardware resources Y2 and Y3, retaining only the basic hardware resources X2 and X3, i.e., their operating system kernels. The first operating system, as the primary operating system, will run using the basic hardware resource X1 and the elastic hardware resources Y1~Y3 (i.e., all idle elastic hardware resources).

[0056] In some specific implementations, the second operating system no longer occupies elastic hardware resources Y2 (including memory hardware resources c' and CPU hardware resources d). This can be achieved by the computer device modifying the CPU task scheduler after receiving a system selection instruction, or by calling the CPU management protocol interface provided by the UEFI firmware, to reallocate the CPU hardware resources d corresponding to the second operating system to the first operating system; alternatively, it can be achieved by reallocating memory hardware resources c' to the first operating system through the memory management protocol interface provided by UEFI. The process for handling the elastic hardware resources Y3 corresponding to the third operating system is similar.

[0057] For example, the identifier of the second operating system for CPU hardware resource d can be changed to an idle or reclaimable status using the sysfs file system interface or the cpu_down() kernel function. Then, based on the information of the first operating system (i.e., the new main operating system) carried in the status change instruction, the CPU task scheduler adds a unique identifier of the first operating system to CPU hardware resource d. Following a similar process, the identifier of the second operating system corresponding to memory hardware resource c' can be changed to the identifier of the first operating system through the memory management protocol interface.

[0058] In this implementation, hardware resources are divided into basic hardware resources and flexible hardware resources. Basic hardware resources are used to load the operating system kernel, while flexible hardware resources are used to support the operation of the operating system. After the primary operating system is determined, other operating systems not selected as the primary operating system will no longer occupy their corresponding flexible hardware resources. These resources will be available as idle resources for the primary operating system to use during runtime. This reallocation method ensures full utilization of the computer's hardware resources after startup, guaranteeing the operating efficiency of the primary operating system and improving the user experience.

[0059] Furthermore, the method may also include: releasing idle resources of the target operating system; the target operating system is the current non-main operating system; the idle resources include elastic hardware resources in the hardware resource partition corresponding to the target operating system.

[0060] Specifically, the system switching command or system selection command sent by the user specifies an operating system as the primary operating system. Upon receiving the system switching command or system selection command, the elastic hardware resources corresponding to the other operating systems not selected as the primary operating system can be released, allowing the primary operating system to utilize more hardware resources and improving its operating efficiency. Each hardware resource partition includes elastic hardware resources and basic hardware resources. The basic hardware resources are used to load the operating system kernel, while the elastic hardware resources are the space supporting the operation of the operating system.

[0061] Optionally, releasing idle resources of the target operating system can be achieved by the computer device, upon receiving a system switching or system selection command, causing all processes corresponding to the target operating system to enter a dormant state. Once the relevant programs in the computer device detect that no running processes exist in the elastic hardware resources corresponding to the target operating system, they mark the elastic hardware resources corresponding to the target operating system as released and proactively add a reclaimable or idle flag to the corresponding elastic hardware resources (e.g., allocated during computer startup), allowing the main operating system to subsequently access them.

[0062] For example, the operating systems loaded into the computer device include a first operating system, a second operating system, and a third operating system. When the computer starts, if the system selection instruction indicates that the first operating system is the primary operating system, then the elastic hardware resources Y2 and Y3 of the second and third operating systems will be released, i.e., idle resources will be released. The first operating system, as the primary operating system, can run according to its corresponding basic hardware resource X1 and elastic hardware resources Y1~Y3. At this time, the target operating systems are the second and third operating systems. It can be understood that the elastic hardware resources in non-primary operating systems are idle resources, which can be confirmed after the non-primary operating system is determined according to the system selection instruction. Furthermore, if it is detected that all processes in the elastic hardware resources corresponding to a certain operating system are in a dormant state, it indicates that the operating system has completed the release action of the elastic hardware resources. That is, when the operating system kernel changes all its corresponding processes to a dormant state according to a pause signal (such as the SIGSTOP signal), the operating system has completed the release of its corresponding elastic hardware resources.

[0063] When the computer is running, if the current primary operating system is the first operating system, and a system switch instruction is received indicating that the primary operating system will be switched to the second operating system, then the elastic hardware resources Y1~Y3 currently corresponding to the first operating system will be released. The second operating system, as the primary operating system, will then run based on its corresponding basic hardware resource X2 and elastic hardware resources Y1~Y3. At this time, the target operating systems are the first and third operating systems.

[0064] It is understandable that, while releasing idle resources of the target operating system according to the system switch command, the kernel of the original host operating system will also be paused and restarted according to the system switch command for the new host operating system, thus achieving the operating system switch. In this embodiment, during the operation of the computer device, hardware resources will also be reallocated, releasing all idle resources (i.e., their corresponding elastic hardware resources) of the non-host operating system target operating system for the host operating system to run. This not only enables rapid operating system switching but also makes fuller use of the hardware resources in the computer device, improving the operating efficiency of the host operating system.

[0065] In some cases, the system switch instruction directs the switching of the primary operating system from the first operating system to the second operating system. First, a pause signal is sent to the kernel of the first operating system. After all processes in the first operating system enter a dormant state based on this pause signal, the elastic hardware resources corresponding to the first operating system are released.

[0066] Specifically, some hardware resources can only be released by the operating system when the processes running on them enter a dormant state or terminate. If the process state is not actively changed, all the elastic hardware resources currently occupied by the operating system will not be released until the processes finish running autonomously. Therefore, in this example, actively changing the process state based on a pause signal allows for the rapid release of the original main operating system's elastic hardware resources, maintaining the efficiency of operating system switching. The pause signal, such as the SIGSTOP signal, includes the process ID (PID) of the processes to be paused (i.e., all processes not corresponding to the main operating system). Upon receiving the SIGSTOP signal, the operating system kernel changes the state of the relevant processes to a dormant state based on the process IDs it carries.

[0067] That is, by actively changing the state of processes through pause signals, the latency of releasing idle resources, i.e., elastic hardware resources, is reduced, further accelerating the operating system switching speed and improving the user experience.

[0068] Furthermore, the method may also include: S31, capture a state snapshot of the other operating system and store the state snapshot; the state snapshot includes the process state of each process in the target operating system at the current moment; S32, release the idle resources of the other operating systems.

[0069] In this implementation, the ptrace function captures a snapshot of the target operating system's state. This snapshot serves as a valid basis for restoring the operating system's state before the switch. After the primary operating system is changed back to the target operating system, the target operating system's state before the switch will be accurately restored. This refers to the idle resources of other operating systems, i.e., the elastic hardware resources corresponding to each operating system other than the primary operating system.

[0070] For example, upon receiving a system switchover command, before the release of elastic resources (i.e., idle resources) in the first operating system (which was originally the primary operating system), a snapshot of the current state of the first operating system is captured. This snapshot serves as a valid basis for subsequently restoring the current running state, accurately restoring the running state of the first operating system before it stopped running after the primary operating system is changed back to the first operating system. For instance, before the elastic hardware resources in the first operating system are released and reallocated to the second operating system (in the case where the second operating system is the newly adapted primary operating system), the process state of the first operating system before the operating system switchover is saved in the form of a snapshot. The process states include ready, running, and hibernating.

[0071] In addition, the state snapshot can also include the process IDs (PIDs) and resource usage of each process in the first operating system. If there are open files, the file processing status can also be recorded, including the file's open status and current read / write position; this file can include documents, audio files, and video files. The process ID (PID) is used to identify different processes, and resource usage is recorded, for example, recording that process p uses 500MB of RAM.

[0072] The contents of the state snapshot are used to restore the current running state of the first operating system when the operating system kernel is restarted subsequently. After generating the state snapshot of the first operating system at the current moment, the state snapshot is stored on the computer device's hard drive for use the next time the first operating system is restarted.

[0073] In some cases, all processes in the first operating system first enter a hibernation state upon receiving a pause signal, and then release the elastic hardware resources corresponding to the first operating system. Therefore, capturing a state snapshot of the first operating system before all processes in the first operating system respond to the pause signal and enter a hibernation state, including the process state of each process at the current moment (i.e., before all processes in the first operating system enter a hibernation state upon receiving the pause signal), can prevent the pause signal from affecting the process states stored in the state snapshot.

[0074] Understandably, the `ptrace` function provided by the operating system is used to capture and save the state of all processes under each operating system, resulting in a state snapshot. This state snapshot is stored in the computer hardware, for example, in binary file format, supporting long-term storage, so that the operating system can restore the process state according to the state snapshot after receiving a boot signal. Simultaneously, after the operating system corresponding to the state snapshot receives the boot signal, it first uses the `ptrace` function to read the state snapshot stored in binary file format, which includes the process's running state and related context information. Then, it compares the process running state information in the read state snapshot with the current process state of the operating system, extracts differences, and finally changes the current process state according to the differences, making the current process state consistent with the process snapshot.

[0075] In this embodiment, before releasing the idle resources of the target operating system, the current process state of the first operating system is captured and stored as a state snapshot on the hard drive of the computer device. This state snapshot can serve as evidence to restore the running state of the target operating system, allowing the main operating system to switch back to the first operating system (when the target operating system is the first operating system). That is, when the user restarts the first operating system, it can continue to operate according to the previous working state without having to start from the state when the operating system was first initialized.

[0076] In one example, after responding to a system switching command and designating the second operating system indicated by the system switching command as the primary operating system, the method may further include: S41, in response to the new system switching command, the first operating system indicated by the new system switching command is used as the main operating system; S42, send a pause signal to the operating system kernel of the second operating system to put all processes of the second operating system into a hibernation state and release the elastic hardware resources corresponding to the second operating system; S43, a startup signal is sent to the operating system kernel of the first operating system so that the first operating system restores all processes of the first operating system to the process state recorded in the state snapshot according to the state snapshot of the first operating system.

[0077] That is, during the process of changing the main operating system from the second operating system to the first operating system, since a snapshot of the state of the first operating system was stored when the main operating system was switched from the first operating system to other operating systems, when changing the main operating system to the first operating system, the running state of the first operating system before it was suspended can be restored based on the stored snapshot of the state of the first operating system.

[0078] Specifically, when a computer device is running a second operating system, if it receives a new system switch instruction that directs the switching back to the first operating system, a pause signal is sent to the kernel of the second operating system (which was the original main operating system), causing the second operating system to suspend operation. This includes putting all processes of the second operating system into a hibernation state and releasing the elastic hardware resources associated with the second operating system. Based on the new system switch instruction, a start signal is also sent to the kernel of the first operating system (which is the new main operating system), causing the first operating system to restart. Before restarting, the kernel of the first operating system checks whether a snapshot of the first operating system's state is stored on the computer device's hard drive.

[0079] If a snapshot of the first operating system is detected on the hard drive, the operating system kernel of the first operating system can restore the running state of the first operating system before it was suspended based on the process state recorded in the snapshot after receiving the boot signal, allowing the user to continue to perform related operations based on the running state before suspension.

[0080] Understandably, if the first operating system does not have a corresponding state snapshot, its kernel will start up based on the boot signal and complete basic initialization. That is, even if a state snapshot does not exist, the operation of the new main operating system will not be interrupted.

[0081] For example, the data recorded in the state snapshot of the first operating system obtained by parsing using the ptrace function includes: process PID, process state, resource usage, file open status, and current file read / write position. For instance, process PID 777 is in running state and occupies 100MB of runtime memory; process PID 778 is in running state, has opened video file 'q', and is currently playing at 6 minutes and 5 seconds; process PID 779 is in sleeping state, and so on. After switching back to the first operating system from the main operating system, the ptrace function will first analyze this state snapshot and, based on the difference between the process states stored in the snapshot and the current process states, restore the aforementioned states of processes 777, 778, and 779 for the user to continue operating.

[0082] Understandably, if the current computer device only loads two operating systems, the state snapshots of the different operating systems are all stored in the same specified location on the hard drive, because only one set of valid state snapshot data exists at any given time during the operation of the computer device; if the current computer device loads more than two operating systems, the state snapshots corresponding to the different operating systems are stored in their respective locations on the hard drive, so that they can be queried and retrieved when the operating system restarts.

[0083] Furthermore, this embodiment does not limit the recovery based on the state snapshot to only when switching back to the first operating system from the second operating system. When switching to the first operating system from any other operating system (such as the third operating system, the fourth operating system, etc.), if the first operating system has a state snapshot, the running state of the first operating system before the suspension can be restored according to the state snapshot.

[0084] In this embodiment, when switching the main operating system, if the new main operating system (e.g., the first operating system) stores a corresponding state snapshot, it can be restored to the running state recorded in the state snapshot according to the corresponding state snapshot, so that the user can continue to operate according to the original running state, ensuring the user's work efficiency and improving the user experience.

[0085] In an optional embodiment of the present invention, the method may further include: S51, obtain the configuration information of each operating system respectively; the configuration information records the location information of the operating system kernel; S52 generates a location identifier for each operating system kernel based on the location information corresponding to each operating system kernel. The process of loading and starting the operating system kernel of the operating system includes: S53, based on the location identifier of the operating system kernel, load and start the corresponding operating system kernel.

[0086] In this implementation, the location identifiers of the operating system kernels for each operating system are first generated using UEFI core service interfaces (such as SetVariable, file system protocols, etc.) and the boot configuration formats corresponding to different operating systems. These identifiers are stored in a designated location on the computer's hard drive. When loading the operating system kernel, the system searches the hard drive using these location identifiers in a traversal manner. Once the specific operating system kernel is found, the bootloader (in the case of booting the computer according to UEFI firmware) is invoked to load it. This supports complex operating environments with multiple operating systems, clearly distinguishing the locations of different operating system kernels based on their location identifiers, thus reducing the probability of errors during kernel loading. Furthermore, the kernel loading process is explicitly divided into two stages: search and load, using the location identifier generation node. The first stage searches for the operating system kernel's location and generates a location identifier based on the found location. The second stage executes the kernel loading action based on the location identifier. If loading fails, the system analyzes the runtime logs to determine whether the error occurred during the configuration information search in the first stage or during the loading action in the second stage, and quickly corrects errors for each stage.

[0087] Specifically, when a computer is not powered on, the operating system is typically stored on the computer's hard drive. When the computer starts up, the hard drive is scanned to read the configuration information of the various operating systems stored therein, and the location information of the operating system kernel is obtained from the configuration information.

[0088] The configuration information typically includes the operating system's partition location on the hard drive and the operating system kernel's load path. The partition location is stored in binary form, and the load path is stored in the boot partition according to the specific format of each operating system (e.g., text format for Linux, binary format for Windows). The operating system kernel's load path is the specific location of the operating system kernel within the operating system's partition. First, the operating system's partition location is obtained from its location on the hard drive. Then, the operating system kernel's load path (i.e., the relative path within the partition location) is converted into a byte offset within the partition location. This byte offset is then used to obtain the actual location of the operating system kernel on the hard drive. Therefore, based on the operating system's partition location and the operating system kernel's load path—that is, the operating system kernel's location information—a location identifier for the operating system kernel can be generated.

[0089] In some cases, before allocating corresponding hardware resource partitions for each operating system (i.e., step 101), a location identifier for each operating system kernel can be generated and stored in binary form on the computer hard drive. At this point, the number of hardware resource partitions to be created can also be determined based on the number of location identifiers.

[0090] For example, the correspondence between operating systems and hardware resource partitions can be constructed based on the storage order of location identifiers. For instance, the storage area corresponding to a location identifier is divided into different operating systems, such as pre-stored indexes like OS1, OS2, and OS3, each with a blank field. After generating different location identifiers for each operating system according to UEFI procedures, the location identifiers are stored in the blank fields corresponding to different indexes. Specifically, they can be stored sequentially; for example, after generating location identifiers, they can be stored first in the blank fields of OS1, and if there are no blank fields in OS1, they can be stored in OS2, etc., completing the storage of location identifiers for each operating system. After generating hardware resource partitions with the same number of location identifiers, each hardware resource partition is matched with an index to form a one-to-one correspondence. Similarly, random allocation is also possible, such as first matching a hardware resource partition for OS1, then matching a hardware resource partition for OS2, etc., ultimately ensuring that each index has a corresponding hardware resource partition. The operating system corresponding to the location identifier stored in the index field matched by each hardware resource partition is the operating system corresponding to that hardware resource partition, thus establishing the correspondence between different hardware resource partitions and operating systems.

[0091] Specifically, referring to the UEFI firmware loading process, the above actions can store the operating system's location identifier in a preset area (such as the blank field of the aforementioned index) for the improved UEFI firmware, and expose the CPU hardware resources and memory hardware resources in the hardware resource partitions divided by the intermediate layer program to the control program (such as the intermediate layer program) through the EFI (Extensible Firmware Interface) device path protocol, memory mapping table, etc. After reading the exposed resources in the relevant hardware resource partitions, the control program (such as the intermediate layer program) establishes the correspondence between the CPU hardware resources in the hardware resource partitions and the corresponding operating system through the system call interface; and establishes the correspondence between the memory hardware resources in the hardware resource partitions and the corresponding operating system through the system call interface.

[0092] Understandably, after establishing the correspondence between the operating system and the hardware resource partition, a unique identifier for the corresponding operating system is added to the hardware resource partition to identify that the hardware resource partition is assigned to a certain operating system.

[0093] When the location identifiers of each operating system kernel exist, loading the operating system kernel can be done by first identifying the location identifiers corresponding to each hardware resource partition, then further determining the location of the operating system kernel based on the location identifiers, and finally loading the corresponding operating system kernel into the hardware resource partition.

[0094] Optionally, the location identifier is stored in the hard drive of the computer device in XML format. Among them, the XML format is relatively simple and requires less storage space. Furthermore, the XML format has syntax tags, which can effectively distinguish different operating system kernels and their corresponding location identifiers, preventing parameter contamination when multiple operating system kernel location identifiers exist.

[0095] In this embodiment, since there is a pre-generated location identifier for the operating system kernel, the location of the operating system kernel to be loaded can be quickly found on the hard drive of the computer device through the location identifier, thus speeding up the process of loading the operating system kernel onto the hardware resource partition.

[0096] In one optional embodiment of this application, the location identifier of each operating system kernel is generated during the Driver Execution Environment (DXE) stage of the UEFI firmware; the hardware resource partition is allocated during the Boot Device Selection (BDS) stage and the Temporary System Load (TSL) stage of the UEFI firmware; the kernel is loaded and started during the Runtime Service (RT) stage of the UEFI firmware; and the computer device completes the boot process based on the UEFI firmware. That is, in this embodiment, the computer device boots through the UEFI firmware. Specifically, the operating system loading steps proposed in this application are implemented through improved UEFI firmware. The improvements primarily focus on the DXE (Driver Execution Environment) stage, BDS (Boot Device Selection) stage, TSL (Temporary System Load) stage, and RT (Runtime) stage of the UEFI firmware.

[0097] Specifically, in the DXE stage, the location information of the operating system kernel in the configuration information of the operating system is obtained, and the location identifier of the operating system kernel is generated based on the location information; in the BDS stage and the temporary loading TSL stage, a corresponding hardware resource partition is allocated for each operating system; in the RT stage, the corresponding operating system kernel is loaded and started in each hardware resource partition based on the location identifier of the operating system kernel.

[0098] The hardware resources include memory hardware resources and CPU hardware resources. In this embodiment, CPU hardware resources can be allocated in the BDS stage and memory hardware resources can be allocated in the TSL stage, ultimately resulting in hardware resource partitions corresponding to each operating system.

[0099] For example, the process of generating the operating system kernel location identifier during the DXE stage can be as follows: The control program (such as an intermediate layer program) opens the ESP partition (EFI SystemPartition) using the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL interface, and then uses the open instruction EFI_FILE_PROTOCOL.Open() and the read instruction EFI_FILE_PROTOCOL.Read() to read file information such as subfolders under the \EFI\ directory (e.g., \EFI\Loongnix and \EFI\UOS) in the ESP partition in a loop. The read information is then written back to the os_boot.xml text file in XML tag format by calling the formatted output instruction AsciiSPrint() provided by the UEFI firmware.

[0100] The os_boot.xml text is created in the ESP partition by the control program (such as the middleware program). One form is the OS1, OS2, OS3 index + operating system kernel location identifier mentioned in the above embodiment.

[0101] The process of allocating CPU hardware resources during the BDS phase can be summarized as follows: In the BDS phase, UEFI obtains a structure containing the CPU's status and representation information based on information acquisition instructions (such as the GetProcessorInfo() instruction). This structure includes the total number of available CPU cores, the ID of each CPU core, and other relevant information. Subsequently, the control program (such as an intermediate layer program) obtains the acquired structure through information exchange with UEFI and expands it, for example, by adding a char OS_HEADER field to each CPU core in the structure. This field identifies the operating system running on that CPU core, thus allocating the CPU core to different operating systems.

[0102] If a CPU core has the field OS_HEADER=A, it indicates that the CPU core is running operating system A. If, during computer operation, this field is changed to OS_HEADER=B, the CPU core will run operating system B. This field modification can be achieved through the CPU task scheduler. It's important to understand that the "A" in OS_HEADER=A only needs to be a unique identifier for operating system A; it's not limited to A and can also be represented in other ways, such as 0x0001.

[0103] The process of allocating memory hardware resources during the TSL phase can be as follows: The control program (such as an intermediate layer program) calls a memory mapping acquisition interface (such as the GetMemoryMap interface) to obtain the size of all available memory in the computer device. Then, it divides the memory hardware resources by calling the memory allocation function in UEFI, such as gBS->AllocatePages(). If 8GB of memory is allocated to operating system A, when running the memory allocation function, the formal parameter Pages is assigned a field such as 0x200000 (because 0x200000 pages equals 8GB). At the same time, &OsAStart is assigned a parameter of 0x000000, indicating that the memory space of 0x200000 size for operating system A is allocated starting from address 0. If memory space is allocated to operating system B, the starting address of the memory space corresponding to operating system B can be defined through &OsBStart.

[0104] It is understandable that if the location identifiers generated in the DXE stage are stored in the form of OS1, OS2, OS3, etc., then the allocation process in the BDS and TSL stages can be fine-tuned to allocate to OS1 or OS2 instead of OSA and OSB. This means that hardware resources are allocated to the operating systems corresponding to the storage order of the location identifiers. After allocation, the CPU and memory hardware resources will correspond to the operating systems corresponding to the location identifiers stored at that index (OS1, OS2, or OS3, etc.).

[0105] In this embodiment, it can be combined with current UEFI technology to realize the system operation mode proposed in this solution at different stages of UEFI, thereby reducing the implementation complexity of this solution and broadening its applicability.

[0106] For example, the system loading method proposed in this application can be edited into code and input into a computer device for execution by the computer device.

[0107] In one example, the code implementing the above system loading method is named the intermediate layer program. Taking the loading of two operating systems (Operating System A and Operating System B) onto the computer device as an example, and using an average allocation principle for hardware resource partitioning, the computer startup process in an example of this application's embodiment is described. Referring to... Figure 4 Steps S61 to S63 are shown.

[0108] Step S61: During the computer device startup process, read the configuration information of different operating systems according to the intermediate layer program.

[0109] Specifically, for example, triggering the computer device's boot process via the power button.

[0110] For example, current computer devices boot up via UEFI firmware, including power-on self-test and initialization. Therefore, after the computer device triggers the boot process, it first enters the SEC (Security) phase of the UEFI firmware. The current UEFI firmware is an improved version; during the SEC phase, it scans the computer device's hard drive to obtain the storage address of the intermediate layer program; or the UEFI firmware data in the SEC phase stores a fixed address for the intermediate layer program, allowing direct reading of this storage address.

[0111] After obtaining the storage address of the intermediate layer program, the new UEFI firmware will send the storage address of the intermediate layer program to the PEI (Pre-EFI Initialization) stage executed by the UEFI firmware. When the boot process reaches the PEI stage, the computer device will read the intermediate layer program according to the storage address obtained above, and load the intermediate layer program into the specified area of ​​the memory chip, according to the process of the new UEFI firmware.

[0112] The PEI stage was originally used to initialize the memory chip, so it reads the memory chip's hardware parameters and establishes memory mappings. In this embodiment, in addition to initializing the memory chip, the PEI stage also allocates a fixed memory address, namely the designated area of ​​the aforementioned memory chip, for loading and running the intermediate layer program. It is understood that if the intermediate layer program occupies the designated location on the memory chip, then when partitioning hardware resources later, the resources outside that designated location will be allocated.

[0113] After the intermediate layer program finishes loading, the UEFI firmware will interact with the intermediate layer program, passing the hardware information of the current computer device, including the handles of the disk devices stored on the hard drive, to the intermediate layer program.

[0114] Optionally, UEFI firmware is typically stored in flash memory. If the flash memory has sufficient space to store both the UEFI firmware and the intermediate layer program, it supports storing the intermediate layer program in the flash memory and running it entirely within it. This eliminates the need to initially store the intermediate layer program on the hard drive, then load it into the memory chip during the PEI stage, and finally run it on the memory chip. In other words, the SEC and PEI stages can be executed according to the original UEFI firmware's process. After the PEI stage is completed, the intermediate layer program in the flash memory interacts with the UEFI firmware, exchanging handles to the disk device and other relevant information.

[0115] During the DXE stage, UEFI firmware typically reads the operating system configuration information stored on the computer's hard drive. Therefore, after the intermediate layer program reads the relevant handles of the disk device, it can obtain the configuration information obtained by the UEFI firmware during the DXE stage based on these handles. At this point, due to the presence of the intermediate layer program, the UEFI firmware does not only read the configuration information of one operating system, but will read the configuration information of all operating systems to be loaded on the computer device.

[0116] UEFI firmware obtains disk device handles through standardized interfaces, typically in two ways: Method 1: Using batch retrieval functions (such as `LocateHandleBuffer()`) to retrieve disk device handles in batches. Specifically, by iterating through all registered information in the UEFI firmware, devices bound to core protocols (such as the disk I / O operation protocol `EFI_DISK_IO_PROTOCOL` or the general storage device protocol `EFI_STORAGE_DEVICE_PROTOCOL`) are selected; the handles of these matching disk devices are then stored in a buffer. Method 2: Using path retrieval functions (such as `LocateDevicePath()`) to precisely retrieve handles based on the disk device's path. Specifically, the `DevicePath` pre-stores the paths to disk devices; the corresponding disk device is read through this path, and the disk device's handle information is returned. The handle is an abstract, unique identifier assigned to each disk device by the UEFI firmware.

[0117] After obtaining the disk device handle, an operation protocol is bound to the handle, and the operating system configuration information in the disk is read through the operation protocol interface. During the UEFI boot process, the root directory of the disk device is first opened (e.g., through the FileSystemProtocol->OpenVolume() interface function call). Then, an operable interface is obtained through an open command (e.g., EFI_FILE_PROTOCOL.Open()) based on the operating system's fixed path (which can be a storage path specified in the UEFI specification or a vendor-predefined path). A read function (e.g., EFI_FILE_PROTOCOL.Read()) then reads the configuration information of each operating system based on the aforementioned operable interface, and parses it according to the storage format (text or structured binary). If stored in text format, the plaintext byte stream is read directly and can be printed or parsed by keywords. If stored in structured binary format, it can be parsed according to a preset data structure or a dedicated API (Application Programming Interface). Furthermore, it supports storing the parsed configuration information in preset formats, including XML and binary formats.

[0118] After obtaining the configuration information of all operating systems to be loaded (such as Loongnix and UOS dual systems) stored on the hard drive, the intermediate layer program describes and stores the location of the operating system kernel in XML format, generating a location identifier for the operating system kernel. The location of the operating system kernel includes key information such as the specific partition location of each operating system on the hard drive and the kernel's loading path. The loading path is the specific location of the operating system kernel within the operating system's partition location. Therefore, the overall storage location of the operating system can be determined first by the partition location, and then the actual location of the operating system kernel can be accurately determined by the loading path. The location identifier can be stored in a blank field after a pre-defined index such as OS1, OS2, OS3, etc. During the initial startup of the computer device, each hardware resource partition corresponds to a unique index, i.e., the operating system corresponding to the location identifier stored after that index.

[0119] Alternatively, complete configuration information, including the location of the operating system kernel, can be stored in XML format to generate a location identifier that can locate the operating system kernel.

[0120] Step S62: Allocate corresponding hardware resource partitions to each operating system. This includes partitioning CPU hardware resources and memory hardware resources.

[0121] Specifically, regarding the allocation of CPU hardware resources: After the UEFI firmware enters the BDS stage, the middleware program obtains the CPU topology information, i.e., the hardware parameters of the CPU in the current computer device, through information interaction with UEFI. Based on this topology information, it identifies all available CPU cores. With a total of 4 CPU cores available, the middleware program, through CPU architecture-related protocols provided by UEFI (such as the MP Services Protocol), calls core functions like GetProcessorInfo() to obtain the CPU's topology information. Then, it allocates the 4 CPU cores equally between operating system A and operating system B, assigning 2 cores to each operating system.

[0122] Alternatively, by modifying the CPU's task scheduler or calling the CPU management protocol interface provided by UEFI, 1-2 cores of the CPU can be assigned to operating system A, and 3-4 cores can be assigned to operating system B.

[0123] Regarding the allocation of memory hardware resources: After the middleware program interacts with the UEFI firmware to obtain information such as the total available storage space of the memory chip, it allocates memory hardware resources according to the pre-defined average allocation principle during the UEFI TSL phase through the memory management interface provided by the UEFI firmware. In this example, the available memory space in the computer device is 16GB, so the middleware program allocates 8GB of memory space to operating system A and operating system B respectively.

[0124] Optionally, 1-8GB of memory address space can be allocated to operating system A, and 9GB-16GB of memory address space can be allocated to operating system B, so that when different operating systems start at the same time, they run in their respective memory spaces, avoiding memory conflicts.

[0125] In some cases, the allocation results can be verified after CPU and memory hardware resource allocation to confirm whether the allocation was successful. If the allocation is successful, subsequent steps are executed; if the allocation is unsuccessful, the original allocation steps are returned to and the hardware resource allocation is performed again to ensure that both CPU and memory hardware resources are ultimately allocated successfully.

[0126] Optionally, the allocation of CPU hardware resources can be verified by comparing the actual CPU hardware resources allocated to different operating systems with the CPU hardware resources expected to be allocated to that operating system. If the actual allocated CPU hardware resources match the expected allocated CPU hardware resources, the allocation of CPU hardware resources to that operating system is considered successful. This verification method can also be used for the allocation of memory hardware resources.

[0127] Step S63: Load and start the operating system kernels of the two operating systems.

[0128] Specifically, after the intermediate layer program completes the allocation of CPU and memory hardware resources through information interaction with the UEFI firmware, it enters the RT (Release-Based) phase of the UEFI firmware. Based on the previously stored location identifiers of the operating system kernels for different operating systems, it loads the corresponding operating system kernels from the allocated CPU and memory hardware resources and begins execution. It is understandable that conventional UEFI firmware can only load one operating system per boot, but this application includes an intermediate layer program. Under the guidance of this intermediate layer program, the UEFI firmware can determine the correspondence between the allocated hardware resources and the operating system kernels.

[0129] In this example, such as Figure 5As shown, in step S62, the intermediate layer program adds a unique identifier of operating system A (e.g., 0x0001 or other custom identifier) ​​to CPU core 1-2 through the CPU task scheduler, and adds a unique identifier of operating system A to 1-8GB of memory chip through the memory management protocol interface, so that CPU core 1-2 and 1-8GB of memory chip are allocated to operating system A. At this time, the intermediate layer program will call the UEFI firmware loading interface (e.g., gBS->LoadImage()) to load the operating system kernel of operating system A into the allocated memory space for running, and start the operating system kernel of operating system A through the running interface (e.g., gBS->StartImage()), and then enter the normal boot process of operating system A. In this process, an identifier for operating system A is added, such as binding the CPU core ID (1, 2, 3, 4, etc.) to this identifier, and binding the starting address and size of each segment of memory space to this identifier. The binding result can be stored as needed in flash memory (non-volatile storage medium) or temporary storage area. CPU cores 3-4 and 9-16GB of memory chips are allocated to operating system B in a similar manner. The operating system kernel of operating system B is loaded into the allocated memory space and runs in the same way, thus entering the normal boot process of operating system B. During the boot process after the two operating system kernels are loaded, the intermediate layer program can continuously monitor their boot status and obtain progress information on the loading and initialization of the operating system kernels by constantly querying the event notification mechanism provided by the UEFI firmware, so as to confirm whether the two operating system kernels have booted successfully.

[0130] If any operating system kernel fails to boot, the computer is restarted, i.e., step S61 is executed again; or an error message is provided for the user to choose whether to restart the computer.

[0131] Step S64: System operation status monitoring and process resource management.

[0132] Once the kernels of operating systems A and B have both started successfully, the intermediate layer program will establish communication with the two operating system kernels to monitor the running status of the two operating systems. At the same time, it will continuously read the file information in the / proc directory of each operating system to obtain relevant process information of operating system A and operating system B in real time, such as process PID, running status, resource usage, etc.

[0133] Step S65: Confirm the main operating system and reallocate hardware resources to ensure stable operation of the main operating system.

[0134] In this example, during the computer device's boot process, in response to the system selection instruction, if operating system A (the first operating system) is selected as the main operating system, the intermediate layer program sends a SIGSTOP signal (i.e., a pause signal) to the operating system kernel of operating system B, causing the operating system kernel of operating system B to pause its operation, and all its processes to enter a hibernation state; or the intermediate layer program will iterate through all processes in operating system B and send a SIGSTOP signal to all processes in operating system B to uniformly set them to a hibernation state.

[0135] Simultaneously, the hardware resources occupied by operating system B (i.e., the target operating system) that do not store the operating system kernel, i.e., the idle resources, are reallocated to operating system A for operation. The idle resources only include elastic hardware resources and do not include basic hardware resources.

[0136] Specifically, after the kernel of operating system B receives the SIGSTOP signal and changes all processes corresponding to operating system B to a dormant state, the intermediate layer program detects that there are no running processes in the elastic hardware resources corresponding to operating system B. That is, when all the elastic hardware resources corresponding to operating system B are released by the kernel of operating system B, the intermediate layer program marks the elastic hardware resources corresponding to operating system B as idle or reclaimable. The intermediate layer program reclaims the hardware resources occupied by operating system B that do not store the kernel of operating system B. That is, it reclaims the idle resources of the target operating system (operating system B), which means that the intermediate layer program releases the idle resources of the target operating system (operating system B).

[0137] For example, the intermediate layer program marks the idle resources corresponding to operating system B as idle or reclaimable, making them available for use by operating system A, which will subsequently act as the main operating system. Specifically, the intermediate layer program marks CPU cores 3-4, previously allocated to operating system B, as idle or reclaimable through the sysfs file system interface or the cpu_down() kernel function, and reassigns them to operating system A by modifying the CPU task scheduler configuration. It also marks the memory hardware resources occupied by operating system B that do not store the operating system kernel as idle or reclaimable through the sysfs file system interface or the free_pages() kernel function, and reallocates them to operating system A through the memory management interface. This reallocation of hardware resources allows operating system A to maximize the utilization of the hardware resources in the current computer device, thereby improving the operating efficiency of operating system A as the main operating program.

[0138] In some cases, due to the simultaneous loading of multiple operating systems, some operating systems may not be able to fully recognize all available hardware resources of a computer device. Therefore, after the operating system releases its corresponding elastic hardware resources, the intermediate layer program marks the relevant elastic hardware resources as idle or reclaimable. This not only clarifies the real-time status of the hardware resource but also displays all currently available elastic hardware resources to the main operating system, allowing for full utilization of idle elastic hardware resources.

[0139] Step S66: During the operation of the computer equipment, change the main operating system.

[0140] Because the memory chip of the computer device in this embodiment stores the operating system kernels of both operating system A and operating system B, it can quickly switch between the main operating systems. Figure 6 As shown, one embodiment of this application provides a process for changing the main operating system based on an intermediate layer program. This includes: 66-1, The intermediate layer program receives the system switching command.

[0141] Specifically, the switching component of the intermediate layer program can receive system switching commands from users. The switching component can provide a system switching interface for users to make switching choices and automatically generate the final system switching command based on the user's selection. Alternatively, the switching component can receive system switching commands actively issued by users, such as command lines.

[0142] Optionally, a switching program can be pre-installed in the computer device. The intermediate-layer program communicates with this switching program in real time to achieve the switching of the main operating system. The intermediate-layer program transmits the received system switching instructions to the switching program, which then actually performs the switching between operating system A and operating system B. Alternatively, the switching program can be integrated into both operating systems A and B. If the switching program is integrated into both operating systems A and B, the latency for controlling the switching between them is lower. In this case, the switching program can be integrated into the operating systems after the kernels of operating systems A and B are loaded.

[0143] 66-2, The intermediate layer program sends a SIGSTOP signal to operating system A (when the main operating system before the switch is operating system A), captures and saves the process state of operating system A, and then causes all processes in operating system A to change to a hibernation state.

[0144] For example, after receiving a system switch command to switch to operating system B (the second operating system) while operating system A is running, the intermediate layer program first uses the ptrace function provided by the operating system to capture and save the state of all processes under operating system A, or it can call the parameters in the / proc directory of operating system A read in step S64 to obtain the state of all processes. In addition, if there are open files, the intermediate layer program will also use the operating system's file system interface to record information such as the file's open state and current read / write position to ensure that the main operating system can restore its running state before the switch back to operating system A.

[0145] In one example, after receiving a system switch instruction, the intermediate layer program first saves the process state of operating system A, and then sends a SIGSTOP signal to the operating system kernel of operating system A (or directly to all processes of operating system A), causing all processes in operating system A to enter a hibernation state. In another example, after receiving the system switch instruction, the intermediate layer program directly sends a SIGSTOP signal to the operating system kernel of operating system A. There are other monitoring programs that, upon detecting that the operating system kernel of operating system A has received a SIGSTOP signal, capture and store the process state of operating system A before the process state of operating system A changes.

[0146] 66-3, reallocate the CPU hardware resources occupied by operating system A and the memory hardware resources that do not store the operating system kernel to operating system B.

[0147] At this point, operating system A is the target operating system. It can be understood that the sum of the CPU hardware resources occupied by operating system A and the memory hardware resources not storing the operating system kernel constitutes the elastic hardware resources of operating system A, i.e., idle resources. This step involves reallocating the elastic hardware resources corresponding to operating system A to operating system B.

[0148] In addition, the flexible hardware resources corresponding to operating system A can be reallocated to operating system B by an intermediate layer program first releasing the idle resources of operating system A, which is the target operating system, and then reallocating the released idle resources to operating system B through the CPU task scheduler.

[0149] 66-4. The intermediate layer program sends a SIGCONT (startup signal) signal to the operating system kernel of operating system B (or directly to all processes of operating system B). Operating system B will then acquire all available resources for normal operation. Simultaneously, all processes of operating system B will change from a dormant state to their initial startup state, and operating system B will begin running.

[0150] Understandably, since operating system B hasn't actually run since the computer booted up, all processes remain in their initial startup state, and there's no process state to return to. If operating system B has a corresponding state snapshot—that is, it stores historical process states—then the recorded historical process states can be restored based on that snapshot, allowing the user to continue operating after the operating system switch, improving work efficiency. At this time, operating system B typically gains access to all CPU hardware resources of the current computer device. Furthermore, if it's necessary to switch the main operating system from operating system B to operating system A, the user only needs to send a system switch command pointing to operating system A again, and the technology and equipment will complete the switch from operating system B to operating system A according to the above process.

[0151] This implementation enables parallel loading and seamless switching between two operating systems on the same computer device, significantly improving the ease of use and efficiency of switching. It avoids the cumbersome process of frequent shutdowns and restarts required for traditional operating system switching, reducing waiting time and improving work efficiency. Simultaneously, it fully leverages the performance advantages of multi-core CPUs and large-capacity memory, avoiding resource waste and improving overall computer performance. Secondly, compared to virtual machine technology that runs multiple operating systems simultaneously, it avoids performance degradation caused by indirect management by virtual machine hypervisors, meeting the needs of application scenarios with high requirements for system performance and independence. Furthermore, the elimination of frequent power cycles during operating system switching extends the lifespan of the computer device.

[0152] Reference Figure 7 The diagram illustrates a structural block diagram of an embodiment of a system loading device according to the present invention. The system loading device may include: The resource allocation module 201 is used to allocate corresponding hardware resource partitions to each operating system when the computer device starts up; the number of operating systems is greater than 1. The kernel loading module 202 is used to load and start the operating system kernel of the operating system in each hardware resource partition respectively; The system determination module 203 is used to monitor the triggered system selection command, select the first operating system corresponding to the system selection command as the main operating system, and stop running the operating system kernels of other operating systems. The system operation module 204 is used to run the main operating system by utilizing the hardware resource partitions corresponding to the main operating system.

[0153] Optionally, the device further includes: The system pause module is used to respond to a system switching command by sending a pause signal to the operating system kernel of the first operating system to stop running the operating system kernel of the first operating system. The system restart module is used to send a startup signal to the operating system kernel of the second operating system indicated by the system switching instruction, and to make the second operating system the main operating system.

[0154] Optionally, the hardware resource partition includes basic hardware resources and elastic hardware resources, and the kernel loading module 202 is specifically used for: In each hardware resource partition, the operating system kernel of the corresponding operating system is loaded and started according to the basic hardware resources; The system operation module 204 is specifically used for: The main operating system is run using the basic hardware resources and the idle elastic hardware resources in all hardware resource partitions.

[0155] Optionally, the device further includes: A switch release module is used to release idle resources of the target operating system; the target operating system is the current non-main operating system; the idle resources include elastic hardware resources in the hardware resource partition corresponding to the target operating system.

[0156] Optionally, the computer device boots based on UEFI firmware, and the apparatus further includes: A reading module is used to read intermediate layer programs from the hard disk of the computer device; Then, the resource allocation module 201 is specifically used for: the intermediate layer program to obtain the total hardware resources of the computer device read by the UEFI firmware by interacting with the UEFI firmware, and to allocate corresponding hardware resource partitions to each operating system respectively. The kernel loading module 202 is specifically used for: the intermediate layer program calling the loading interface of the UEFI firmware to load and start the corresponding operating system kernel of the operating system in each hardware resource partition.

[0157] Optionally, the device further includes: A state capture module is used to capture state snapshots of the other operating system and store the state snapshots; the state snapshots include the process states of each process in the target operating system at the current moment; The resource release module is used to release idle resources from the other operating systems. Optionally, the device further includes: The configuration information acquisition module is used to acquire the configuration information of each operating system; the configuration information records the location information of the operating system kernel. The location identifier generation module is used to generate a location identifier for each operating system kernel based on the location information corresponding to each operating system kernel. The kernel loading module 202 is specifically used to: load and start the corresponding operating system kernel according to the location identifier of the operating system kernel.

[0158] Optionally, the location identifier is stored in the hard drive of the computer device in XML format.

[0159] Optionally, the location identifier is generated during the DXE stage of the UEFI firmware's driver execution; the hardware resource partition is allocated during the BDS stage and the TSL stage of the UEFI firmware's boot selection; and the operating system kernel is loaded and started during the RT stage of the UEFI firmware's runtime services.

[0160] This application provides a system loading device. In related technologies, a computer device can only load one operating system per boot. When switching operating systems, it is necessary to first shut down and restart, and then select a different operating system during the new boot phase to achieve the switching. This solution divides the hardware resources of the computer device, allowing multiple operating system kernels to be loaded and started in parallel across multiple different hardware resource partitions during boot. Then, one of these kernels can be selected as the primary operating system based on system selection instructions. Because multiple operating system kernels are pre-loaded, when switching operating systems during computer operation as needed by the user, the currently running operating system kernel can be disabled, and another pre-loaded operating system kernel can be enabled to quickly achieve the system switch without needing to reload a new operating system through a device restart. This speeds up the operating system switching process and improves the user experience. As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0161] Reference Figure 8 This is a schematic diagram of the structure of the electronic device provided in an embodiment of the present invention. Figure 8 As shown, the electronic device includes: a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface communicate with each other through the communication bus. The memory is used to store at least one executable instruction, which causes the processor to execute the steps of the system loading method of the aforementioned embodiment.

[0162] This invention provides a non-transitory computer-readable storage medium that, when the instructions in the storage medium are executed by a program or processor of a terminal, enables the terminal to perform the steps of the system loading method described in the foregoing embodiments. This document uses specific examples to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A system loading method, characterized in that, The method includes: When a computer device starts up, a corresponding hardware resource partition is allocated to each operating system; the number of operating systems is greater than one. In each hardware resource partition, the operating system kernel of the operating system is loaded and started respectively; Monitor the triggered system selection command, select the first operating system corresponding to the system selection command as the main operating system, and stop running the operating system kernels of other operating systems; The main operating system is run using the hardware resource partition corresponding to the main operating system.

2. The system loading method according to claim 1, characterized in that, The method further includes: In response to a system switching command, a pause signal is sent to the operating system kernel of the first operating system to stop running the operating system kernel of the first operating system; A boot signal is sent to the operating system kernel of the second operating system indicated by the system switching instruction, and the second operating system is used as the main operating system.

3. The system loading method according to claim 1, characterized in that, The hardware resource partition includes basic hardware resources and flexible hardware resources; Then, loading and starting the operating system kernel of the operating system respectively includes: In each hardware resource partition, the operating system kernel of the corresponding operating system is loaded and started according to the basic hardware resources; Then, the step of running the main operating system using the hardware resource partition corresponding to the main operating system includes: The main operating system is run using the basic hardware resources and the idle elastic hardware resources in all hardware resource partitions.

4. The system loading method according to any one of claims 1 to 3, characterized in that, The computer device boots based on UEFI firmware; the method further includes: reading an intermediate layer program from the hard disk of the computer device; Then, loading and starting the operating system kernel of the operating system respectively includes: The intermediate layer program interacts with the UEFI firmware to obtain the total hardware resources of the computer device read by the UEFI firmware, and allocates corresponding hardware resource partitions to each operating system. The intermediate layer program calls the UEFI firmware loading interface to load and start the corresponding operating system kernel in each hardware resource partition.

5. The system loading method according to claim 1, characterized in that, The method further includes: Capture and store state snapshots of the other operating systems; the state snapshots include the process states of each process in the target operating system at the current moment. Release the idle resources of the other operating systems.

6. The system loading method according to claim 1, characterized in that, The method further includes: The configuration information for each operating system is obtained separately; the configuration information contains the location information of the operating system kernel. Based on the location information corresponding to each operating system kernel, a location identifier for each operating system kernel is generated; Then, loading and starting the operating system kernel of the operating system respectively includes: Based on the location identifier of the operating system kernel, the corresponding operating system kernel is loaded and started.

7. The system loading method according to claim 6, characterized in that, The location identifier is stored in XML format on the hard drive of the computer device.

8. The system loading method according to claim 6, characterized in that, The location identifier is generated during the DXE stage of the UEFI firmware's driver execution; the hardware resource partition is allocated during the BDS stage and the TSL stage of the UEFI firmware's boot selection; and the operating system kernel is loaded and started during the RT stage of the UEFI firmware's runtime services.

9. A system loading device, characterized in that, The device includes: The resource allocation module allocates a corresponding hardware resource partition to each operating system when the computer device starts up; the number of operating systems is greater than 1. The kernel loading module is used to load and start the operating system kernel of the operating system in each hardware resource partition, respectively. The system determination module is used to monitor the triggered system selection command, select the first operating system corresponding to the system selection command as the main operating system, and stop running the operating system kernels of other operating systems. The system operation module is used to run the main operating system by utilizing the hardware resource partitions corresponding to the main operating system.

10. An electronic device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the steps of the system loading method as described in any one of claims 1 to 8.

11. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the system loading method as described in any one of claims 1 to 8.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the system loading method as described in any one of claims 1 to 8.

Images