Updating method and system of domestic operating system compatible with different architectures

Abstract

The invention discloses an updating method and system of a domestic operating system compatible with different architectures. The updating method comprises the following steps: step 1, generating a universal updating package containing a unified data segment and a multi-architecture execution segment of different architectures of the domestic operating system; 2, identifying different architectures of the domestic operating system, and obtaining different execution segments corresponding to the different architectures from the universal update package; and step 3, the execution segment obtains corresponding execution data according to the unified data segment, and updates the operating systems of different architectures. According to the method, the original independent maintenance of each framework is reduced to unified maintenance of one update package, so that the maintenance cost of the update package is reduced; secondly, user operation is simplified, a user does not need to manually recognize an operating system framework, and framework recognition and updating file extraction are automatically completed; and finally, unified updating management of a multi-architecture system is supported, and the updating efficiency and reliability of the domestic operating system are improved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and more specifically, to a method for updating a domestic operating system compatible with different architectures. Background Art

[0002] Currently, when Linux systems run on CPUs with different instruction sets, such as Phytium, Loongson, Sunway, RISCV, and x86, they must be compiled separately for each CPU, packaged into binary executable files, and deployed to separate app stores. For example, maintaining five app stores for five different architectures involves repeated uploading, verification, and log management, resulting in high labor costs, wasted storage space, and the need for users to manually select architecture versions.

[0003] The independent maintenance model for multiple architectures leads to low development and operation efficiency; users need to manually download the corresponding installation package based on the device architecture, which has a high usage threshold; the same data segments are repeatedly stored, wasting disk space.

[0004] Therefore, the problems existing in the prior art need to be further improved and developed. Summary of the Invention

[0005] (1) Purpose of the invention: To solve the problems existing in the above-mentioned prior art, the purpose of the present invention is to provide an update method for domestic operating systems that are compatible with different architectures. By one-time packaging and multi-architecture compatibility, maintenance costs can be reduced and user experience can be improved.

[0006] (II) Technical Solution: To solve the above technical problems, this technical solution provides an update method for domestic operating systems compatible with different architectures, including: Step 1: Generate a universal update package containing unified data segments and multi-architecture execution segments for different architectures of the domestic operating system; Step 2: Identify the different architectures of the domestic operating system and obtain the different execution segments corresponding to the different architectures from the universal update package; Step 3: The execution segment obtains the corresponding execution data according to the unified data segment and updates the operating systems of different architectures.

[0007] Preferably, the specific operation of step 1 is: 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 a compilation tool chain; the universal update package includes a data segment and an execution segment, the data segment is a unified data segment, including update data for all architectures, and the execution segment corresponds to different execution segments for different architectures.

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

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

[0010] Preferably, the domestic operating system is a Linux operating system.

[0011] Preferably, the CPU architecture includes x86_64, arm64, loongarch64, SW64, and RISCV64.

[0012] Preferably, the step 2 comprises: Step 201: The terminal downloads the universal update package and automatically identifies the CPU architecture of the domestic operating system corresponding to the current terminal; Step 202: According to the recognition result, the loader obtains the execution data corresponding to the execution segment of the current CPU architecture from the architecture index table.

[0013] Preferably, step 3 is specifically as follows: initializing the execution environment, dynamically loading and executing native code, executing data to obtain data segment data corresponding to the execution segment, and performing updates to enable the direct running of the native program on the CPU architecture of the current domestic operating system.

[0014] Preferably, when there are multiple terminals and multiple terminals correspond to multiple different CPU architectures, each CPU architecture is identified separately, the execution data of all relevant CPU architectures is obtained from the universal update package, and the corresponding execution data is allocated to each CPU architecture; the update is performed by reading the execution data and executing the data of the data segment, thereby completing the update of the domestic operating system.

[0015] An update system for a domestic operating system compatible with different architectures, applicable to the update method for a domestic operating system compatible with different architectures, comprising a packaging module, an identification module, and an execution module; the packaging module generates a universal update package containing unified data segments for different architectures of the domestic operating system and multi-architecture execution segments; The identification module identifies different architectures of the domestic operating system and obtains different execution segments corresponding to different architectures from the universal update package; The execution segment of the execution module obtains corresponding execution data according to the unified data segment and updates the operating systems of different architectures.

[0016] (III) Beneficial Effects: The present invention provides an update method for domestic operating systems compatible with different architectures. First, it reduces the maintenance of each architecture separately to a unified update package, thus reducing update package maintenance costs. Second, it simplifies user operations, eliminating the need for users to manually identify the operating system architecture; architecture identification and update file extraction are automatically completed. Finally, it supports unified update management for systems with multiple architectures, improving the efficiency and reliability of domestic operating system updates. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a flowchart of the steps of an update method for domestic operating systems compatible with different architectures of the present invention; Figure 2 It is a structural diagram of an update system of the present invention that is compatible with domestic operating systems of different architectures. DETAILED DESCRIPTION

[0018] The present invention is further described in detail below in conjunction with preferred embodiments. More details are set forth in the following description to facilitate a full understanding of the present invention. However, the present invention can obviously be implemented in a variety of other ways different from the description. Those skilled in the art can make similar generalizations and deductions based on actual application situations without violating the connotation of the present invention. Therefore, the scope of protection of the present invention should not be limited by the content of this specific embodiment.

[0019] The accompanying drawings are schematic diagrams of embodiments of the present invention. It should be noted that the drawings are merely examples and are not drawn to scale, and should not be used to limit the actual scope of protection claimed in the present invention.

[0020] With the continuous advancement of educational informatization, computer-based teaching and experimentation, as well as paperless exams, have become increasingly popular. The number of computers and computer classrooms is increasing, and the hardware equipment is improving. However, different computer classrooms may have different CPU architectures, depending on the scope of their teaching and the time of installation. Therefore, traditional computer management and maintenance methods severely restrict the maximum effectiveness 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-computer rooms can not only reduce the workload and pressure of management and maintenance, but also improve laboratory management efficiency and service quality. It can also ensure the operational efficiency and security of terminals and enhance user satisfaction, which are the fundamental requirements of IT operations and maintenance in informatized education.

[0021] Therefore, the present invention proposes an update method for domestic operating systems compatible with different architectures, such as Figure 1 As shown, the specific steps include: Step 1: Generate a universal update package that includes unified data segments and multi-architecture execution segments for different architectures of the domestic operating system.

[0022] Step 2: Identify the different architectures of the domestic operating system and obtain the different execution segments corresponding to the different architectures from the universal update package.

[0023] Step 3: The execution segment obtains the corresponding execution data according to the unified data segment and updates the operating systems of different architectures.

[0024] Step 1 is saved on the server before the user downloads the update package. Steps 2 and 3 are performed after the user downloads the update package. After the customer downloads the universal update package from the server / app store, different terminals will automatically update and optimize according to their own CPU architecture.

[0025] An update system compatible with domestic operating systems of different architectures, applicable to an update method compatible with domestic operating systems of different architectures, such as Figure 2 As shown, the system includes a packaging module, an identification module, and an execution module. The packaging module generates a universal update package containing unified data segments and multi-architecture execution segments for different architectures of the domestic operating system. The identification module identifies different architectures of the domestic operating system and obtains different execution segments corresponding to different architectures from the universal update package. The execution segment of the execution module obtains corresponding execution data based on the unified data segments and updates the operating systems of different architectures.

[0026] The following is an explanation with reference to specific embodiments: In Example 1, the specific operations of the packaging module in step 1 are as follows: According to the domestic operating system, the binary segments of multi-platform applications are unified into one file through the compilation tool chain to generate a new executable file format: a universal update package. The universal update package includes a data segment and an execution segment. Different execution segments are obtained according to the different CPU architectures of the domestic operating system, and the data segment is integrated according to the update data of 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 data segment that includes update data for all architectures, and the execution segment corresponds to different execution segments for different architectures.

[0027] The compilation tool chain includes but is not limited to GCC, LLVM, etc., and is not specifically limited.

[0028] Preferably, the universal 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 binary code for all CPU architectures of domestic operating systems in ELF format. The GPU execution segment contains OpenCL / CUDA kernel code (.cl / .ptx files) and supports mainstream GPU manufacturers (NVIDIA / AMD / domestic accelerator cards). The NPU execution segment stores specialized instruction sets and supports TensorRT and ONNX execution.

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

[0030] Real-time detection of available hardware via system interfaces, including but not limited to lspci, nvidia-smi, etc.

[0031] For example, an AI application relies on GPU kernel version V2 for model acceleration and NPU driver version 1.5 or higher for heterogeneous computing. The collaborative metadata table clearly records the mapping between CPU, GPU, and NPU versions. Therefore, it is necessary to establish this mapping based on common industry practices: NPU driver v2.1 requires GPU kernel version 3.0 or higher; GPU kernel v3.0 requires the CPU to support the AVX-512 instruction set.

[0032] As shown in Table 1, the universal update package includes header information and a multi-architecture update file; the header information includes metadata such as the update package version, creation time, and a list of supported CPU architectures; the multi-architecture update file includes an architecture index table corresponding to each architecture, where Table 1, Table 2, ..., and Table n respectively 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 to form a universal update package with a unified format.

[0034] Table 1 Format codes for general update packages

[0035] The universal update package is in universal format. The domestic operating system is a Linux 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, RISCV64, etc.

[0036] More specifically, the data and execution segments 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 under the Linux operating system, these are generally divided into bin, lib, and data. The data segment is the same across different CPU architectures, and the execution segment is divided into bin and lib based on the execution type. The execution segment varies depending on the instruction set of the CPU architecture. Therefore, compared to previous methods, packaging using this technology can reduce issues related to user download and execution, while also reducing space in app stores.

[0037] The universal 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 (Architecture), label address (tablesize), entry address, program header offset (Program Header Table), table header offset (Section Header Table), and flags (Flags), as shown in Table 2. The architecture type is used to declare the supported instruction set type; the program header offset and table header offset are used to locate the execution segment and data segment; the label address, entry address, and flags are used to represent the execution segment and data segment of different CPU architectures.

[0038] Table 2 Example of a schema index table

[0039] The architecture index table provides corresponding addresses and offsets for various CPU architectures, such as x86_64, arm64, loongarch64, SW64, RISCV64, and other architectures.

[0040] Specifically, the specific operations of the identification module in step 2 include: Step 201: The terminal downloads the universal update package and automatically identifies the CPU architecture of the domestic operating system corresponding to the current terminal.

[0041] Step 202: According to the recognition result, the loader obtains the execution data corresponding to the execution segment of the current CPU architecture from the architecture index table.

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

[0043] Specifically, the CPU execution segment is directly mapped to memory using memfd_create, avoiding errors caused by disk I / O. The ELF file matching the architecture is loaded via the dynamic linker (dlopen). The GPU execution segment dynamically loads PTX kernels using a vendor SDK (such as the NVIDIA CUDA Driver API). The NPU execution segment loads offline models via a heterogeneous computing framework (such as Huawei ACL).

[0044] The CPU execution segment pre-processes data and passes it 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 between the CPU execution segment, GPU execution segment, and NPU execution segment matches each other, the data pre-processed by the CPU execution segment is directly passed to the GPU execution segment and / or NPU execution segment; when the hardware between the CPU execution segment, GPU execution segment, and NPU execution segment does not match each other, the driver is triggered to generate incremental updates.

[0045] The incremental generation uses a block difference algorithm for large GPU / NPU files, and combines hardware dynamic detection, memory direct loading, and heterogeneous collaborative updates to achieve full-stack seamless updates from CPU to GPU / NPU, overcoming the three core pain points of cross-architecture resource scheduling, security verification, and performance loss.

[0046] Dynamic hardware detection refers to real-time monitoring of anomalies, vulnerabilities, or security threats during system operation. It continuously analyzes dynamic information such as data flows, process behavior, and memory status to identify potential risks (such as malicious code execution, data tampering, and abnormal resource consumption). Dynamic hardware detection in this invention monitors the CPU / GPU / NPU for abnormal conditions such as gradient explosion and hardware overheating during training.

[0047] Direct memory loading is a technology that bypasses the CPU and directly loads data into memory (similar to direct memory access (DMA). This allows hardware devices (such as GPUs, FPGAs, and network cards) to directly read or write to system memory, reducing CPU intervention and improving data transfer efficiency. Direct memory loading in this invention allows the data preprocessing module to load training data directly into GPU memory, reducing CPU transfer latency.

[0048] The heterogeneous collaborative update is designed for heterogeneous computing environments, with a collaborative update mechanism for data and state to ensure data consistency and task synchronization between different architecture components. The heterogeneous collaborative update in the present invention ensures the consistency of parameter updates during multi-GPU training.

[0049] More specifically, the specific operations of the execution module in step 3 are as follows: Initialize the execution environment, dynamically load and execute native code, execute data to obtain the data segment data corresponding to the execution segment, and perform updates, so as to realize the direct running of native programs on the CPU architecture of the current domestic operating system without the need for a virtual machine or dynamic translation.

[0050] Specifically, the specific operations of relying on dlopen and memory mapping methods to load the corresponding execution segment and data segment are: Step 301: Memory map data segment.

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

[0052] Mmap is a memory-mapped file method that maps a file or other object into memory. The file is mapped to multiple pages. If the file size is not the sum of the sizes of all pages, the unused space on the last page is cleared to zero.

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

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

[0055] Use dlopen to dynamically load the temporary shared library file, delay binding via RTLD_LAZY, and resolve symbols only when the function is actually called. Use RTLD_DEEPBIND to give priority to local symbols to avoid conflicts with main program symbols.

[0056] 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.

[0057] Step 303: Execute the entry function.

[0058] Get the entry point address (such as main) through dlsym, call the entry point function, and pass in the data segment address as a parameter. When the program exits, the corresponding data segment and execution segment data are released.

[0059] The corresponding execution and data segments are loaded using dlopen and memory mapping. First, mmap directly maps the data segment to memory, avoiding repeated disk reads and writes. dlopen loads the execution segment on demand, reducing startup resource usage and achieving efficient loading. Secondly, the CPU instruction set is dynamically identified and the matching execution segment is automatically selected, without user awareness, enabling seamless switching between multiple architectures.

[0060] Specifically, the execution module directly executes native machine code to avoid virtual machine performance loss.

[0061] The execution module includes a launcher component. When the application is started, 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, and use 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, achieving the convenience of adapting to multiple CPU instruction set architectures with one package, reducing the packaging and maintenance costs of software vendors, improving user experience, and eliminating the need for complex means such as virtual machines, thereby ensuring the native operating efficiency of the program.

[0062] More preferably, when there are multiple terminals in multiple computer classrooms, and multiple terminals have different CPU architectures, each CPU architecture is identified separately, execution data for all relevant CPU architectures is obtained from the universal update package, and corresponding execution data is allocated to each CPU architecture. The execution data is read and the data in the execution data segment is executed to perform the update, thereby completing the update of the domestic operating system.

[0063] The data segment structure is the same, and merging the data segments into a common update package for storage reduces disk space. However, when the launcher loads the application, different CPU architectures will select the execution segment that suits their architecture to execute the data segment structure, thus adapting to different CPU architecture systems. For example, a program package .exe file contains both a data segment and an execution segment. During installation, different CPU architectures read different data formats, so the execution segment selects the appropriate data format from the data segment for installation.

[0064] Example 2

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

[0066] When running the universal update package to update the operating system, a loader, such as a dynamic language, takes over some of the launcher's tasks. Then, through methods such as splicing, various execution segments and data segments are loaded into memory and handed over to the operating system for execution. When running the update, the execution segment reads the data format using the dynamic language and selects the appropriate data format.

[0067] Dynamic languages ​​include any dynamic language with more than one field, such as Python, JavaScript, Ruby, PHP, Perl, Groovy, Lua, and JS. However, in theory, JS requires underlying extensions. These dynamic languages ​​perform type checking at runtime, support dynamic modification of code structures, and offer flexibility and rapid development.

[0068] The present invention provides an update method for domestic operating systems compatible with different architectures. First, it reduces the maintenance of each architecture separately to a unified update package, thus reducing the maintenance cost of the update package. Second, it simplifies user operations, eliminating the need for users to manually identify 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 domestic operating system updates.

[0069] The above content is an explanation of the preferred embodiments of the present invention, which can help those skilled in the art to more fully understand the technical solutions of the present invention. However, these embodiments are merely illustrative, and it cannot be determined that the specific implementation methods of the present invention are limited to the description of these embodiments. For those skilled in the art of the present invention, without departing from the concept of the present invention, several simple deductions and transformations can be made, which should be deemed to fall within the scope of protection of the present invention.

Claims

1. A method for updating domestic operating systems compatible with different architectures, characterized in that: include: Step 1: Generate a universal update package containing unified data segments and multi-architecture execution segments for different architectures of the domestic operating system; Step 2: Identify the different architectures of the domestic operating system and obtain the different execution segments corresponding to the different architectures from the universal update package; Step 3: The execution segment obtains the corresponding execution data according to the unified data segment and updates the operating systems of different architectures.

2. The updating method of a domestic operating system compatible with different architectures according to claim 1, characterized in that: The specific operation of step 1 is: 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 tool chain; the universal update package includes a data segment and an execution segment, the data segment is a unified data segment, including update data for all architectures, and the execution segment corresponds to different execution segments for different architectures.

3. The updating method of a domestic operating system compatible with different architectures according to claim 2, characterized in that: The universal update package includes header information and a multi-architecture update file; the header information includes the update package version, creation time, and a list of supported CPU architectures; the multi-architecture update file includes an architecture index table corresponding to each architecture.

4. The updating method of a domestic operating system compatible with different architectures according to claim 3, characterized in that: The architecture index table records execution data of different execution segments corresponding to different CPU architectures; the execution data includes a label address, an entry address, a program header offset, a table header offset, and a flag bit.

5. The updating method of a domestic operating system compatible with different architectures according to claim 4, characterized in that: The CPU architecture includes x86_64, arm64, loongarch64, SW64, and RISCV64.

6. The updating method of a domestic operating system compatible with different architectures according to claim 1, characterized in that: The domestic operating system is the Linux operating system.

7. The updating method of a domestic operating system compatible with different architectures according to claim 1, characterized in that: The step 2 includes: Step 201: The terminal downloads the universal update package and automatically identifies the CPU architecture of the domestic operating system corresponding to the current terminal; Step 202: According to the recognition result, the loader obtains the execution data corresponding to the execution segment of the current CPU architecture from the architecture index table.

8. The updating method of a domestic operating system compatible with different architectures according to claim 1, characterized in that: The step 3 is specifically as follows: initializing the execution environment, dynamically loading and executing the native code, executing the data to obtain the data segment data corresponding to the execution segment, and performing the update to realize the direct running of the native program on the CPU architecture of the current domestic operating system.

9. The updating method of a domestic operating system compatible with different architectures according to claim 1, characterized in that: When there are multiple terminals and multiple terminals correspond to multiple different CPU architectures, each CPU architecture is identified separately, the execution data of all relevant CPU architectures is obtained from the universal update package, and the corresponding execution data is allocated to each CPU architecture; the update is performed by reading the execution data and executing the data in the data segment, thereby completing the update of the domestic operating system.

10. An update system for domestic operating systems compatible with different architectures, applicable to the update method for domestic operating systems compatible with different architectures, characterized in that: It includes a packaging module, an identification module and an execution module; the packaging module generates a universal update package containing unified data segments and multi-architecture execution segments of different architectures of the domestic operating system; The identification module identifies different architectures of the domestic operating system and obtains different execution segments corresponding to different architectures from the universal update package; The execution segment of the execution module obtains corresponding execution data according to the unified data segment and updates the operating systems of different architectures.

Images