A packaging method compatible with different architectures of operating systems

Abstract

A packaging method for operating systems compatible with different architectures includes the following steps: Step 1: A server generates a universal update package containing a unified data segment and multiple architecture execution segments for different architectures of domestic operating systems; Step 2: A terminal identifies the different architectures of the domestic operating system and obtains the different execution segments corresponding to the different architectures from the universal update package; Step 3: The execution segments obtain the corresponding execution data based on the unified data segment and update the operating systems of different architectures. This invention firstly reduces the maintenance cost of update packages by reducing the need for separate maintenance for each architecture to a unified maintenance of a single update package; secondly, it simplifies user operations, as users do not need to manually identify the operating system architecture, and the architecture identification and update file extraction are automatically completed; finally, it supports unified update management for multi-architecture systems, improving the efficiency and reliability of updating domestic operating systems.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically, to a packaging method for operating systems compatible with different architectures. Background Technology

[0002] Currently, when Linux systems run on CPUs with different instruction sets such as Phytium, Loongson, Shenwei, RISC-V, and x86, separate binary executable files need to be compiled and packaged for each CPU instruction set, and then deployed to separate application stores. For example, five different architectures require five application stores, involving repetitive uploading, verification, and log management tasks, resulting in high personnel costs, wasted storage space, and users having to manually select the architecture version.

[0003] The independent maintenance mode of multiple architectures leads to low development and operation efficiency; users need to manually download the corresponding installation package according to the device architecture, which raises the usage threshold; and the same data segments are stored repeatedly, wasting disk space.

[0004] Therefore, the existing technology has problems and needs further improvement and development. Summary of the Invention

[0005] (I) Purpose of the invention: In order to solve the problems existing in the prior art, the purpose of the present invention is to provide a packaging method that is compatible with operating systems of different architectures. By packaging once and achieving multi-architecture compatibility, maintenance costs are reduced and user experience is improved.

[0006] (II) Technical Solution: To solve the above-mentioned technical problems, this technical solution provides a packaging method compatible with operating systems of different architectures, including: Step 1: The server generates a general update package containing a unified data segment and multi-architecture execution segments for different architectures of domestic operating systems. The general update package has a hierarchical storage structure. The execution segments include CPU execution segments, GPU execution segments, and NPU execution segments. The CPU execution segment stores the binary code of all CPU architectures of domestic operating systems in ELF format. The GPU execution segment contains OpenCL / CUDA kernel code. The NPU execution segment stores a dedicated instruction set. The unified data segment stores configuration files and resource data shared by multiple architectures. The unified data segment includes a collaborative metadata table, which records the hardware dependencies between the execution segments. Step 2: The terminal downloads the general update package, identifies different architectures of the domestic operating system, and obtains different execution segments corresponding to different architectures from the general update package. The CPU execution segment is directly mapped to memory, preprocesses data, and passes it to the GPU execution segment and / or NPU execution segment through shared memory. The hardware dependencies in the collaborative metadata table are checked. When the hardware of the CPU execution segment, GPU execution segment, and NPU execution segment matches, the preprocessed data of the CPU execution segment is directly passed to the GPU execution segment and / or NPU execution segment. When the hardware of the CPU execution segment, GPU execution segment, and NPU execution segment does not match, incremental driver generation and updates for the mismatched hardware are triggered. Step 3: The execution segment obtains the corresponding execution data based on the unified data segment. mmap maps the unified data segment to the process address space, dynamically identifies the CPU instruction set, automatically selects the matching execution segment, and updates the operating system for different architectures.

[0007] Preferably, step 1 specifically involves: based on the domestic operating system, unifying the binary segments of multi-platform applications into a new executable file format: a universal update package through the compilation toolchain; the universal update package includes a data segment and an execution segment, the data segment is a unified data segment that includes update data for all architectures, while the execution segment corresponds to different architectures.

[0008] Preferably, the general update package includes header information and multi-architecture update files; the header information includes the update package version, creation time, and a list of supported CPU architectures; the multi-architecture update files include an architecture index table corresponding to each architecture.

[0009] Preferably, the architecture index table records the execution data of different execution segments corresponding to different CPU architectures; the execution data includes label address, entry address, program table header offset, table header offset, and flag bits.

[0010] Preferably, the CPU architecture includes one or more of x86_64, arm64, loongarch64, SW64, and RISC V64.

[0011] Preferably, the domestically developed operating system is an operating system based on the Linux kernel.

[0012] Preferably, step 2 includes: Step 201: The terminal downloads the general update package and automatically identifies the CPU architecture of the domestic operating system corresponding to the current terminal; Step 202: Based on the identification results, obtain the execution data corresponding to the execution segment of the current CPU architecture from the architecture index table through the loader.

[0013] Preferably, the terminal includes a hardware detection unit that detects the CPU, GPU, and NPU hardware information of the terminal in real time through a system interface.

[0014] Preferably, step 3 specifically involves: initializing the execution environment, dynamically loading and executing native code, obtaining the data segment data corresponding to the execution segment, and performing an update, thereby enabling the native program to run directly on the CPU architecture of the current domestic operating system.

[0015] Preferably, when there are multiple terminals and multiple terminals correspond to multiple different CPU architectures, each terminal identifies each CPU architecture, obtains the execution data of all relevant CPU architectures from the general update package, and allocates the corresponding execution data for each CPU architecture; by reading and executing the data segment through the execution data, the update of the domestic operating system is completed.

[0016] Preferably, when there are multiple terminals and the multiple terminals correspond to the same CPU architecture, the terminals of the same architecture are sorted according to the remaining memory, and the terminal with the largest memory is selected as the representative terminal; the representative terminal loads the corresponding execution segment in the virtual machine monitor isolation environment to perform simulated updates, records the system call branch sequence in real time, and generates a full memory rewrite mapping table covering all physical memory rewrite addresses. The system call branch sequence and the full memory rewrite mapping table are encapsulated into a globally unique trust benchmark, and the globally unique trust benchmark and the update instruction are sent to other non-representative terminals of the same architecture; When the non-representative terminal is actually updating, the local virtual machine monitor intercepts the system call branch sequence of the update process in real time and compares it with the system call branch sequence in the globally unique trust benchmark. If any item in the system call branch sequence of the update process intercepted in real time is different from any item in the system call branch sequence in the globally unique trust benchmark, the process is immediately suspended and an alarm is issued. At the same time, by monitoring the extended page table, it is verified whether the target address of each physical memory write is within the full memory rewrite mapping table. If it exceeds the range of the full memory rewrite mapping table, it is blocked and rolled back in real time.

[0017] (III) Beneficial Effects: This invention packages multi-architecture execution segments and a unified data segment into a universal update package. Compared to the existing technology that maintains application stores separately for each architecture, this firstly reduces the number of update packages to maintain from N architecture types to 1, significantly reducing storage costs, workload for operations and maintenance personnel, and maintenance costs. Secondly, it simplifies user operations; users no longer need to manually identify the operating system architecture, as architecture identification and update file extraction are automatically completed. Finally, it supports unified update management for multi-architecture systems, improving the efficiency and reliability of domestic operating system updates. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating the steps of a packaging method compatible with operating systems of different architectures according to the present invention. Detailed Implementation

[0019] The present invention will be further described in detail below with reference to preferred embodiments. More details are set forth in the following description in order to provide a full understanding of the present invention. However, the present invention can obviously be implemented in many other ways different from those described herein. Those skilled in the art can make similar extensions and derivations based on actual application situations without departing from the spirit of the present invention. Therefore, the scope of protection of the present invention should not be limited by the content of this specific embodiment.

[0020] The accompanying drawings are schematic diagrams of embodiments of the present invention. It should be noted that these drawings are for illustrative purposes only and are not drawn to scale, and should not be construed as limiting the actual scope of protection of the present invention.

[0021] With the deepening of educational informatization, computer-based teaching, experiments, and paperless examinations have become increasingly common. The number of computers and computer labs is growing, and the hardware is becoming increasingly sophisticated. However, different computer labs may have different CPU architectures due to variations in teaching scope and installation time. Therefore, traditional computer management and maintenance methods severely limit the maximum efficiency of these devices and place enormous pressure on management and maintenance personnel. Changing this situation and achieving centralized and unified management of large-scale, multi-laboratory systems can reduce the workload and pressure of management and maintenance, improve laboratory management efficiency and service quality, and ensure terminal operating efficiency and security, thereby enhancing user satisfaction. This is a fundamental requirement for IT operations and maintenance in information-based education.

[0022] Therefore, this invention proposes a packaging method compatible with operating systems of different architectures, such as... Figure 1 As shown, the specific steps include: Step 1: The server generates a universal update package containing a unified data segment for different architectures of domestic operating systems and a multi-architecture execution segment.

[0023] Step 2: The terminal downloads the general update package, identifies the different architectures of the domestic operating system, and obtains the different execution segments corresponding to the different architectures from the general update package.

[0024] Step 3: The execution segment obtains the corresponding execution data based on the unified data segment and updates the operating system for different architectures.

[0025] Step 1 is generated and saved on the server before the user downloads the update package. Steps 2 and 3, on the other hand, occur after the user downloads the update package. Once the user downloads the universal update package from the server / app store, different terminals will automatically update and optimize according to their own CPU architecture.

[0026] The following is a description with reference to specific embodiments: Example 1, the specific operation of step 1 is as follows: Based on the domestically developed operating system, a new executable file format, the universal update package, is generated by unifying the binary segments of multi-platform applications into a single file using a compilation toolchain. This universal update package includes a data segment and an execution segment. Different execution segments are derived based on the CPU architecture of the domestically developed operating system, while the data segment is integrated with update data for different CPU architectures to obtain a unified data segment. Therefore, the universal update package includes a data segment and an execution segment. The data segment is a unified segment containing update data for all architectures, while the execution segments correspond to different architectures.

[0027] The compilation toolchain includes, but is not limited to, GCC, LLVM, etc., and there are no specific restrictions.

[0028] Preferably, the general update package has a hierarchical storage structure. The execution segment includes a CPU execution segment, a GPU execution segment, and an NPU execution segment; the CPU execution segment stores the binary code of the CPU architecture of all domestic operating systems in ELF format. The GPU execution segment contains OpenCL / CUDA kernel code (.cl / .ptx files), supporting mainstream GPU manufacturers (NVIDIA / AMD / domestic accelerator cards). The NPU execution segment stores a dedicated instruction set, supporting TensorRT and ONNX execution.

[0029] The unified data segment is used to store configuration files and resource data (such as model weights, font libraries, etc.) shared by multiple architectures. The unified data segment also includes a collaborative metadata table, which records the hardware dependencies between the execution segments (e.g., GPU kernel V2 requires NPU driver ≥1.5) to ensure compatibility requirements are met during updates.

[0030] Available hardware is detected in real time via system interfaces. These system interfaces include, but are not limited to, LSPCI and NVIDIA-SMI.

[0031] For example, an AI application might rely on GPU kernel version V2 for model acceleration and NPU driver version ≥1.5 for heterogeneous computing. The collaborative metadata table explicitly records the mapping relationship between the CPU, GPU, and NPU versions. Therefore, this mapping relationship needs to be built based on industry-standard practices: NPU driver v2.1 requires GPU kernel ≥v3.0; GPU kernel v3.0 requires the CPU to support the AVX-512 instruction set.

[0032] As shown in Table 1, the general update package includes header information and multi-architecture update files; the header information includes metadata such as update package version, creation time, and a list of supported CPU architectures; the multi-architecture update files include architecture index tables corresponding to each architecture, where Table 1, Table 2, ..., Table n represent architecture index tables for different CPU architectures.

[0033] The packaging module is used to classify and integrate the binary segments of the application according to different instruction set CPU architectures, merge the same data segments, and store the execution segments and common data segments under each CPU architecture respectively, forming a universal update package with a unified format.

[0034] Table 1. Format Codes for General Update Packages The universal update package is in universal format. The domestic operating system is a Linux kernel-based operating system, including all mainstream Linux distributions such as Ubuntu and CentOS. The CPU architecture includes, but is not limited to, x86_64, arm64, loongarch64, SW64, and RISC V64.

[0035] More specifically, the data segment and execution segment are integrated through a compilation toolchain to generate a universal executable file (Universal format) containing a unified data segment (Data) and multi-architecture executable segments (Bin / Lib). For applications running the Linux operating system, these are generally divided into bin, lib, and data. The data segment is the same across different CPU architectures, while the execution segment is divided into bin and lib based on the execution type. The execution segment varies depending on the CPU architecture's instruction set. Therefore, compared to previous methods, this packaging technology can reduce issues related to user download and execution, while also reducing the space required by application stores.

[0036] The general update package embeds an architecture index table, which records the execution data of different execution segments corresponding to different CPU architectures. The execution data includes a table header: Architecture type, tablesize, entry address, Program Header Table offset, Section Header Table offset, and flags, as shown in Table 2. The architecture type declares the supported instruction set types; the Program Header Table offset and Section Header Table offset are used to locate the execution and data segments; the tablesize, entry address, and flags represent the execution and data segments of different CPU architectures.

[0037] Table 2. Example of a Schema Index The architecture index table provides corresponding addresses and offsets for various CPU architectures, such as x86_64, arm64, loongarch64, SW64, RISC V64, etc.

[0038] Specifically, step 2 includes the following operations: Step 201: The terminal downloads the general update package and automatically identifies the CPU architecture of the domestic operating system corresponding to the current terminal.

[0039] The terminal includes a hardware detection unit that detects the CPU, GPU, and NPU hardware information of the terminal in real time through system interfaces such as LSPCI and NVIDIA-SMI.

[0040] Step 202: Based on the identification results, obtain the execution data corresponding to the execution segment of the current CPU architecture from the architecture index table through the loader.

[0041] The loader is preferably a launcher loader, a lightweight loader written in C or C++. The loader parses the architecture index table and dynamically loads the corresponding execution segments and data segments.

[0042] More specifically, the CPU execution segment directly maps to memory via memfd_create, avoiding errors caused by disk I / O. It then loads the ELF file matching the architecture using the dynamic linker (dlopen). The GPU execution segment dynamically loads the PTX kernel by calling the vendor's SDK (such as the NVIDIA CUDA Driver API). The NPU execution segment loads offline models through a heterogeneous computing framework (such as Huawei ACL).

[0043] The preprocessed data from the CPU execution segment is transferred to the GPU execution segment and / or NPU execution segment via shared memory. By checking the hardware dependencies in the collaborative metadata table, when the hardware of the CPU execution segment, GPU execution segment, and NPU execution segment matches, the preprocessed data from the CPU execution segment is directly transferred to the GPU execution segment and / or NPU execution segment; when the hardware of the CPU execution segment, GPU execution segment, and NPU execution segment does not match, incremental driver generation and updates for the mismatched hardware are triggered.

[0044] The incremental generation uses a block-based difference algorithm for large files on GPU / NPU. By combining hardware dynamic detection, direct memory loading, and heterogeneous collaborative updates, it achieves seamless full-stack updates from CPU to GPU / NPU, overcoming three core pain points: cross-architecture resource scheduling, security verification, and performance loss.

[0045] The aforementioned hardware dynamic detection refers to a technology that monitors anomalies, vulnerabilities, or security threats in real time during system operation. It identifies potential risks (such as malicious code execution, data tampering, and abnormal resource consumption) by continuously analyzing dynamic information such as data flow, process behavior, and memory status. In this invention, the hardware dynamic detection monitors abnormal conditions such as gradient explosion and hardware overheating of the CPU / GPU / NPU during training.

[0046] Direct memory loading is a technique that bypasses the CPU and loads data directly into memory (similar to Direct Memory Access (DMA)). It allows hardware devices (such as GPUs, FPGAs, and network cards) to directly read from or write to system memory, reducing CPU intervention and improving data transfer efficiency. In this invention, direct memory loading allows the data preprocessing module to directly load training data into the GPU's video memory, reducing CPU latency.

[0047] The heterogeneous collaborative update described herein is a mechanism designed for collaborative updates of data and state in heterogeneous computing environments, ensuring data consistency and task synchronization among different architectural components. In this invention, the heterogeneous collaborative update ensures the consistency of parameter updates during multi-GPU training.

[0048] More specifically, step 3 involves the following steps: The system initializes the execution environment, dynamically loads and executes native code, retrieves the data segment corresponding to the execution segment, and performs updates, enabling native programs to run directly on the CPU architecture of current domestic operating systems without the need for virtual machines or dynamic translation.

[0049] Specifically, the operations for loading the corresponding execution segment and data segment using dlopen and memory mapping methods are as follows: Step 301: Memory-mapped data segment.

[0050] In this embodiment, mmap is used to map a unified data segment to the process address space. After mapping, the data segment content can be accessed directly through the memory address, without the need for disk input / output.

[0051] mmap is a memory-mapped file method that maps a file or other object into memory. The file is mapped across multiple pages, and if the file size is not the sum of the sizes of all the pages, the unused space on the last page will be zeroed out.

[0052] Step 302: Dynamically load the execution segment.

[0053] Extract the execution segment of the target CPU architecture (such as libxxx.so) into a temporary shared library file, locate the position of the execution segment in the file according to the offset of the program table header, and write the contents of the segment to a temporary file (such as / tmp / libxxx_arch.so).

[0054] The temporary shared library file is dynamically loaded using dlopen, and delayed binding is performed using RTLD_LAZY, resolving symbols only when the function is actually called. RTLD_DEEPBIND prioritizes the use of local symbols to avoid conflicts with symbols in the main program.

[0055] The dlopen is a computer function that opens a specified dynamic link library file in a specified mode and returns a handle to the calling process of dlsym.

[0056] Step 303: Execute the entry function.

[0057] The entry point address (e.g., main) is obtained via dlsym. The entry function is then called, passing the address of the data segment as a parameter. When the program exits, the corresponding read data segment and execution segment data are released.

[0058] The corresponding execution and data segments are loaded using dlopen and memory mapping methods. First, mmap directly maps data segments to memory, avoiding repeated disk reads and writes. dlopen loads execution segments on demand, reducing resource consumption at startup and achieving efficient loading. Second, it dynamically identifies the CPU instruction set and automatically selects the matching execution segment without the user's awareness, enabling seamless switching between multiple architectures.

[0059] Specifically, the execution module directly executes native machine code, avoiding virtual machine performance loss.

[0060] The execution module includes a launcher component. When the application starts, the launcher can accurately locate and load the corresponding executable segments (bin and lib) from the universal update package according to the CPU architecture of the current terminal. At the same time, it uses a unified data segment (data) for initialization and execution operations, ensuring that the application can run stably and efficiently on domestic operating systems with different CPU architectures. This achieves the convenience of adapting to multiple CPU instruction set architectures with a single package, reduces the packaging and maintenance costs for software vendors, improves user experience, and ensures the native running efficiency of the program without the need for complex means such as virtual machines.

[0061] More preferably, when multiple computer classrooms have multiple terminals, and these terminals correspond to multiple different CPU architectures, each terminal identifies each CPU architecture, retrieves the execution data for all relevant CPU architectures from the universal update package, and allocates corresponding execution data to each CPU architecture. The update of the domestic operating system is completed by reading and executing the data segments through the execution data.

[0062] The data segments have the same structure, and merging them into a single universal update package reduces disk space usage. However, when the launcher loads the application, different CPU architectures will select the appropriate execution segment to execute based on the data segment structure, thus adapting to different CPU architecture systems. For example, the executable file contains both data and execution segments. During installation, different CPU architectures read different data formats, so the execution segment will select the appropriate data format from the data segments for execution.

[0063] Example 2: The difference from Embodiment 1 is that the universal update package does not use the universal format, but retains the original execution format, such as PE, ELF, etc., storing the binary parts of different architectures separately. Various data formats are stored separately to form corresponding small folders, and then all the small folders are packaged into a large folder to store the data.

[0064] When the general update package is run to update the operating system, a dynamic language or similar method is used as a loader to take over some of the launcher's work. Then, various execution segments and data segments are loaded into memory through methods such as splicing and handed over to the operating system for execution. During the update process, the execution segments read the data format using the dynamic language and select the appropriate data format.

[0065] The dynamic languages ​​mentioned include any dynamic language beyond the specified fields, such as Python, JavaScript, Ruby, PHP, Perl, Groovy, Lua, JS, etc., although theoretically JS requires underlying extensions. These dynamic languages ​​perform type checking at runtime, support dynamic modification of code structure, and are characterized by flexibility and rapid development.

[0066] Example 3: In a large-scale terminal cluster update scenario where multiple computer classrooms have multiple terminals, and these terminals correspond to the same CPU architecture, it is difficult to prevent update failures or system crashes due to differences in individual terminal environments if each terminal independently performs architecture identification and execution segment extraction. Therefore, this example sorts terminals with the same architecture by remaining memory and selects the terminal with the largest memory as the representative terminal. The representative terminal loads the corresponding execution segment in the virtual machine monitor isolation environment to simulate the update, records the system call branch sequence in real time, and generates a full memory rewrite mapping table covering all physical memory rewrite addresses. Subsequently, the system call branch sequence and the full memory rewrite mapping table are used as a globally unique trust benchmark, which is sent to other non-representative terminals with the same architecture along with the update instruction. When the non-representative terminals perform a real update, the local virtual machine monitor intercepts the update process call branch sequence and compares it with the system call branch sequence; at the same time, by monitoring the extended page table, it verifies whether the target address of each physical memory write is within the allowed range of the full memory rewrite mapping table. When it exceeds the range of the full memory rewrite mapping table, it is blocked and rolled back in real time.

[0067] Specifically, after the terminal manager issues a readiness update command, each terminal in the same CPU architecture group detects and reports its hardware status in real time through the system interface, including the remaining available physical memory capacity.

[0068] The terminal manager sorts the terminals within the CPU architecture group based on the reported local hardware status and selects the terminal with the highest remaining available physical memory capacity as the representative terminal for that CPU architecture. In the subsequent simulated update phase, it can completely map the unified data segments in the general update package to memory, avoiding disk swapping interference caused by insufficient memory, thereby extracting the purest and noise-free program execution path characteristics.

[0069] Upon receiving the update preparation instruction, the representative terminal initiates a lightweight isolated sandbox environment built by a virtual machine monitor. First, the representative terminal's loader, based on its own CPU architecture, extracts the corresponding execution and data segments from the general update package and loads them into the isolated environment. The virtual machine monitor then performs blind-spot-free observation of the CPU execution data flow and memory access data flow, thereby obtaining the representative terminal's system call branches and memory rewrite boundaries. When non-representative terminals subsequently perform updates, they only need to compare whether the CPU execution path is consistent and whether the memory rewrite address is out of bounds to perform batch updates for a large-scale terminal cluster.

[0070] More specifically, when the update process gets stuck in the kernel, the virtual machine monitor captures the current instruction pointer, system call number, and hash value of key parameters, and records the return address in the process address space, thus obtaining the system call branch sequence. This system call branch sequence reflects the actual update process under different control flow decisions, eliminating uncertainties caused by environmental noise.

[0071] Before the simulated update begins, the virtual machine monitor temporarily clears the write permission bit in the extended page table entry of the physical page to which the update process belongs. When the update process first attempts to perform a write operation to a physical memory address, the CPU triggers an EPT Violation exception due to a permission violation and is trapped in the virtual machine monitor. The local virtual machine monitor records the target physical memory address of the write operation and compares it with the full memory rewrite mapping table. Only if the target physical memory address is within the full memory rewrite mapping table is the write permission of the physical page to which the update process belongs temporarily restored to allow the write operation, and the write permission bit is cleared again immediately after the write operation is completed.

[0072] After the simulated update is completed, the virtual machine monitor aggregates all triggered physical memory address ranges, merges contiguous addresses, and generates a full memory rewrite mapping table. This full memory rewrite mapping table defines the legal scope of the update operation at the physical memory level, clarifying the memory boundaries that the update operation should theoretically only touch.

[0073] After the representative terminal completes the simulated update, it hashes and signs the system call branch sequence and the full memory rewrite mapping table, encapsulates it as a globally unique trust benchmark, and sends it along with the official update command to all non-representative terminals with the same architecture within the cluster. At this point, the non-representative terminals receive not just a simple general update package, but also the general update package and its execution behavior constraints.

[0074] The program execution path characteristics in the globally unique trust benchmark include the source address, system call number, and call order identifier corresponding to the system call branch.

[0075] Upon receiving the update command, the non-representative terminal initiates the update process in the real environment. At this point, the local virtual machine monitor intervenes, intercepting every system call branch sequence of the update process in real time. The intercepted real-time system call branch sequence is compared item by item with the system call branch sequence in the globally unique trust benchmark. If any item in the intercepted system call branch sequence of the update process differs from any item in the globally unique trust benchmark, it indicates a deviation in the system call branch sequence's direction, is judged as abnormal behavior, and the process is immediately suspended and an alarm is issued.

[0076] When an update write operation is performed on a non-representative terminal, the local virtual machine monitor uses the monitoring extended page table to intercept every physical memory write instruction triggered by the update process. The virtual machine monitor extracts the target physical memory address of the write instruction and queries the full memory rewrite map in the globally unique trust base. When the target address falls within the valid address space recorded in the full memory rewrite map, the write is allowed, and the CPU executes the update normally. When the target address falls outside the valid address space recorded in the full memory rewrite map, the virtual machine monitor determines it as an out-of-bounds attack or a sign of impending program crash, immediately blocks the write instruction, sends an abnormal signal to the operating system, and triggers an immediate rollback of the update process.

[0077] This embodiment upgrades the original single-machine update behavior to a cluster-based trusted collaborative update based on hardware-assisted virtualization. It not only solves the storage and distribution efficiency problems by utilizing a universal update package, but also achieves risk-free execution across all terminals through a single simulation representing the terminal. This is particularly suitable for domestic operating system replacement scenarios with extremely high requirements for stability and consistency.

[0078] This invention provides a packaging method for operating systems compatible with different architectures. Firstly, it reduces the maintenance cost by simplifying the process from maintaining each architecture separately to maintaining a single, unified update package. Secondly, it simplifies user operations, eliminating the need for manual identification of the operating system architecture; architecture identification and update file extraction are automatically completed. Finally, it supports unified update management for multi-architecture systems, improving the efficiency and reliability of updates for domestically developed operating systems.

[0079] The above description illustrates preferred embodiments of the present invention and helps those skilled in the art to more fully understand the technical solution of the present invention. However, these embodiments are merely illustrative and should not be construed as limiting the specific implementation of the present invention to these embodiments. For those skilled in the art, several simple deductions and modifications can be made without departing from the inventive concept, and all such modifications should be considered within the protection scope of the present invention.

Claims

1. A packaging method compatible with operating systems of different architectures, characterized in that, include: Step 1: The server generates a general update package containing a unified data segment and multi-architecture execution segments for different architectures of domestic operating systems. The general update package has a hierarchical storage structure. The execution segments include CPU execution segments, GPU execution segments, and NPU execution segments. The CPU execution segment stores the binary code of all CPU architectures of domestic operating systems in ELF format. The GPU execution segment contains OpenCL / CUDA kernel code. The NPU execution segment stores a dedicated instruction set. The unified data segment stores configuration files and resource data shared by multiple architectures. The unified data segment includes a collaborative metadata table, which records the hardware dependencies between the execution segments. Step 2: The terminal downloads the general update package, identifies different architectures of the domestic operating system, and obtains different execution segments corresponding to different architectures from the general update package. The CPU execution segment is directly mapped to memory, preprocesses data, and passes it to the GPU execution segment and / or NPU execution segment through shared memory. The hardware dependencies in the collaborative metadata table are checked. When the hardware of the CPU execution segment, GPU execution segment, and NPU execution segment matches, the preprocessed data of the CPU execution segment is directly passed to the GPU execution segment and / or NPU execution segment. When the hardware of the CPU execution segment, GPU execution segment, and NPU execution segment does not match, incremental driver generation and updates for the mismatched hardware are triggered. Step 3: The execution segment obtains the corresponding execution data based on the unified data segment. mmap maps the unified data segment to the process address space, dynamically identifies the CPU instruction set, automatically selects the matching execution segment, and updates the operating system for different architectures.

2. The packaging method for operating systems compatible with different architectures according to claim 1, characterized in that, The specific operation of step 1 is as follows: Based on the domestic operating system, the binary segments of multi-platform applications are unified into a new executable file format: a universal update package through the compilation toolchain; the universal update package includes a data segment and an execution segment, the data segment is a unified data segment that includes update data for all architectures, while the execution segment corresponds to different architectures.

3. The packaging method for operating systems compatible with different architectures according to claim 2, characterized in that, The general update package includes header information and multi-architecture update files; the header information includes the update package version, creation time, and a list of supported CPU architectures; the multi-architecture update files include an architecture index table corresponding to each architecture.

4. The packaging method for operating systems compatible with different architectures according to claim 3, characterized in that, The architecture index table records the execution data of different execution segments corresponding to different CPU architectures; the execution data includes label address, entry address, program table header offset, table header offset, and flag bits.

5. The packaging method for operating systems compatible with different architectures according to claim 4, characterized in that, The CPU architecture includes one or more of x86_64, arm64, loongarch64, SW64, and RISC V64.

6. The packaging method for operating systems compatible with different architectures according to claim 1, characterized in that, The domestically developed operating system is based on the Linux kernel.

7. The packaging method for operating systems compatible with different architectures according to claim 1, characterized in that, Step 2 includes: Step 201: The terminal downloads the general update package and automatically identifies the CPU architecture of the domestic operating system corresponding to the current terminal; Step 202: Based on the identification results, obtain the execution data corresponding to the execution segment of the current CPU architecture from the architecture index table through the loader.

8. The packaging method for operating systems compatible with different architectures according to claim 1, characterized in that, The terminal includes a hardware detection unit that detects the terminal's CPU, GPU, and NPU hardware information in real time through a system interface.

9. A packaging method for operating systems compatible with different architectures according to claim 1, characterized in that, Step 3 specifically involves: initializing the execution environment, dynamically loading and executing native code, obtaining the data segment data corresponding to the execution segment, and performing updates to enable the native program to run directly on the CPU architecture of the current domestic operating system.

10. A packaging method compatible with operating systems of different architectures according to claim 1, characterized in that, When multiple terminals exist, and each terminal corresponds to a different CPU architecture, the terminal identifies each CPU architecture, obtains the execution data of all relevant CPU architectures from the general update package, and allocates the corresponding execution data to each CPU architecture; by reading and executing the data segment through the execution data, the update of the domestic operating system is completed.

11. The packaging method for operating systems compatible with different architectures according to claim 1, characterized in that, When multiple terminals exist and they correspond to the same CPU architecture, the terminals with the same architecture are sorted by remaining memory, and the terminal with the largest memory is selected as the representative terminal. The representative terminal loads the corresponding execution segment in the virtual machine monitor isolation environment to simulate the update, records the system call branch sequence in real time, and generates a full memory rewrite mapping table covering all physical memory rewrite addresses. The system call branch sequence and the full memory rewrite mapping table are encapsulated into a globally unique trust benchmark, and the globally unique trust benchmark and the update instruction are sent to other non-representative terminals with the same architecture. When the non-representative terminal is actually updating, the local virtual machine monitor intercepts the system call branch sequence of the update process in real time and compares it with the system call branch sequence in the globally unique trust benchmark. If any item in the system call branch sequence of the update process intercepted in real time is different from any item in the system call branch sequence in the globally unique trust benchmark, the process is immediately suspended and an alarm is issued. At the same time, by monitoring the extended page table, it is verified whether the target address of each physical memory write is within the full memory rewrite mapping table. If it exceeds the range of the full memory rewrite mapping table, it is blocked and rolled back in real time.

Images