Operating system containerized kernel compatible method based on mixed binary translation

Abstract

The invention discloses an operating system containerized kernel compatibility method based on mixed binary translation, which comprises the following steps of: constructing a container kernel data structure feature library containing field access frequency through static source code analysis and dynamic runtime tracking, generating a unique identifier consisting of a structure name and a high-frequency field offset sequence for a target structure, and generating a container kernel data structure feature library containing field access frequency; establishing an association graph between the system call and the target field; in a host machine, a static translation service is adopted to decompile a binary code of a container application, instrumentation is performed on a high-frequency site and a low-frequency site respectively, and an intermediate operation code sequence containing an operation code, a field name and double-end offset is pre-generated for the high-frequency site and stored in a cache; during operation, a pre-translation result is preferentially loaded from the cache for a high-frequency site, the pre-translation result is processed by the dynamic translation engine if the pre-translation result is not hit, and the pre-translation result is processed by the dynamic translation engine as required for a low-frequency site, so that efficient conversion combining field-level static preprocessing and on-demand dynamic conversion is realized.

Description

Technical Field

[0001] This invention belongs to the field of cross-platform compatibility technology, specifically relating to an operating system containerization kernel compatibility method based on hybrid binary translation. Background Technology

[0002] Containerization relies on the operating system kernel's native mechanisms for isolation and resource management. Container systems running within containers typically have different system call interfaces than the host system running on the host machine. For example, Linux relies on POSIX standard system calls, while Windows uses Win32 APIs and NT kernel objects. Their calling methods and parameter structures are completely different, causing binary files within containers to be unable to run directly across kernels. For instance, Linux container socket network calls cannot be parsed on the Windows NT kernel. Furthermore, different systems have different function libraries and data structure alignment methods, meaning even applications of the same architecture (x86_64) cannot run across systems. Even if the container system and the host system are based on the same kernel, incompatibility issues may still exist. For example, the HarmonyOS kernel is based on the Linux kernel, but to meet the needs of distributed capabilities and lightweight device adaptation, the kernel's core data structures have been deeply customized. For example, in the file management module, the HarmonyOS system's `struct file` adds a distributed file identifier `distributed_id` and an extended flag `ohm_flags` field to the Linux host structure; in the process management module, its `struct task_struct` extends the HarmonyOS scheduling priority `ohos_prio` and the application capability identifier `ability_id` field; at the data structure level, its hash list node `struct hlist_node` adjusts the pointer offset from 8 bytes to 4 bytes to adapt to the memory layout of resource-constrained devices. Therefore, when the container system runs on the host system, the differences in the kernel data structures of the two systems can cause problems such as mismatched system call parameters, access conflicts to pointer-intensive structures, and failure to adapt to underlying hardware differences.

[0003] Existing solutions primarily monitor system calls initiated by container applications, failing to achieve precise targeting based on access frequency at the data structure level. Consequently, they suffer from issues such as redundancy in full-scale conversion, high overhead in dynamic translation, and inefficient handling of complex structures, which become even more pronounced when the host system's performance is limited. Summary of the Invention

[0004] In view of this, the present invention provides a method for operating system containerization kernel compatibility based on hybrid binary translation, which achieves efficient compatibility between container systems and host systems by combining field-level static preprocessing and on-demand dynamic conversion.

[0005] This invention provides a method for operating system containerization kernel compatibility based on hybrid binary translation, specifically including the following steps:

[0006] Establish the first mapping relationship between the target structure of the container system and the standard structure of the standard system; extract the field names, types, offsets and alignment requirements of the target structure to form basic features through static source code analysis and post-compilation memory layout correction; collect the access frequency of the target fields by running the container system, and mark the high-frequency and low-frequency fields in the basic features to form the first feature library; determine the target fields related to system calls in the container application, and establish the second mapping relationship from system calls to target fields based on the first mapping relationship to form an association graph containing call number, structure, field, access type and field access ratio;

[0007] Deploy a static translation service and a dynamic translation engine on the host machine, create a first cache with the call number and the first offset of the target field as the key, save the second offset of the host field and the conversion function, and save the pre-translated intermediate opcode sequence in a second cache;

[0008] The static translation service inserts a first converter at system calls for high-frequency fields and a second converter at system calls for low-frequency fields. For high-frequency fields, an intermediate opcode sequence containing opcode, field name, container offset, and host offset is generated in advance and stored in a second cache. When the container application runs, the first converter first checks the second cache to obtain the pre-translation result. If it misses the result, it checks the first cache. If it still misses the result, it triggers the dynamic translation engine to complete the conversion. The second converter then triggers the dynamic translation engine to complete the conversion.

[0009] Furthermore, a unique identifier is generated for the target structure, consisting of a sequence of offsets for the structure name and high-frequency fields, wherein the offsets in the offset sequence are arranged in descending order of access frequency.

[0010] Furthermore, the dynamic translation engine parses the target field of the system call as a sensitive field, obtains the instructions related to the sensitive field, and ignores the instructions when the instructions are ordinary instructions; when the instructions are access instructions, the engine intercepts the instructions and verifies whether the field address operated by the instructions is the same as the sensitive field. If they are the same, when the instructions are read operations, data is read from the address corresponding to the second offset of the host field, converted, and written to the address corresponding to the first offset of the target field; when the instructions are write operations, data is read from the address corresponding to the first offset of the target field, converted, and written to the address corresponding to the second offset, thus completing the conversion; if they are different, the instructions are ignored.

[0011] Furthermore, based on the address range of the container system pointers, multiple circular pointer pools are created. Each circular pointer pool corresponds to an address segment and contains a circular buffer. The circular buffer stores multiple mapping entries, each containing a target pointer, a host pointer, an access timestamp, and a kernel object ID.

[0012] Upon receiving the target pointer, the circular pointer pool is determined based on the pointer address range. Starting from the tail pointer, the circular buffer is traversed. If a buffer is hit, the access timestamp is updated and the host pointer is returned; otherwise, a new mapping entry is created in the circular buffer. If the circular buffer is not full, the new mapping entry is written to the head pointer position and the head pointer is moved forward. If the circular buffer is full, the mapping entry with the smallest access timestamp is deleted, the pointer is moved forward, and the new mapping entry is written to the head pointer position.

[0013] Furthermore, the size of the circular buffer is a fixed value.

[0014] Furthermore, when establishing a mapping entry, the ID of the associated kernel object in the host system is recorded; when a system call related to releasing a kernel object is intercepted, the kernel object ID is obtained, and the circular pointer pool is traversed to delete valid mapping entries with the same kernel object ID.

[0015] Furthermore, based on the first feature library, the high-frequency fields and pointer-intensive data structures are divided into different verification groups. During the conversion process, a double buffer, including a main buffer and a backup buffer, is constructed for the conversion result. The conversion result is stored in the main buffer, while the backup buffer uses an independent conversion function to obtain the backup conversion result. Only the cyclic redundancy check values ​​of the high-frequency fields in the main buffer and the backup buffer are compared. If they match, the conversion is determined to be correct. If they do not match, the default value is used and an error log is recorded.

[0016] Furthermore, the information of the target structure in the first feature library is converted into binary format before being stored.

[0017] Beneficial effects:

[0018] This invention constructs a container kernel data structure feature library containing field access frequencies through static source code analysis and dynamic runtime tracing. It generates a unique identifier for the target structure, consisting of the structure name and a sequence of high-frequency field offsets, and establishes a correlation graph between system calls and target fields, clarifying the kernel structures and fields that each system call depends on. In the host machine, a static translation service decompiles the container application binary code, instrumenting high-frequency and low-frequency sites. For high-frequency sites, an intermediate opcode sequence containing opcodes, field names, and double-ended offsets is pre-generated and cached. At runtime, for high-frequency sites, pre-translated results are loaded from the cache first; if neither is found, the dynamic translation engine handles the rest. For low-frequency sites, the dynamic translation engine handles them on demand, achieving efficient conversion by combining field-level static preprocessing with on-demand dynamic conversion. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating an operating system containerization kernel compatibility method based on hybrid binary translation provided by the present invention. Detailed Implementation

[0020] The present invention will be described in detail below with reference to the accompanying drawings and embodiments.

[0021] This invention provides a method for operating system containerization kernel compatibility based on hybrid binary translation. The core idea is as follows: Through static source code analysis and dynamic runtime tracing, a container kernel data structure feature library containing field access frequencies is constructed. A unique identifier consisting of the structure name and a sequence of high-frequency field offsets is generated for the target structure. A correlation graph between system calls and target fields is established, clarifying the kernel structure and fields that each system call depends on. In the host machine, a static translation service is used to decompile the binary code of the container application, instrumenting high-frequency and low-frequency sites respectively. For high-frequency sites, an intermediate opcode sequence containing opcodes, field names, and double-ended offsets is pre-generated and stored in a cache. At runtime, for high-frequency sites, pre-translated results are loaded from the cache first; if neither is found, the dynamic translation engine handles the rest. For low-frequency sites, the dynamic translation engine handles them as needed.

[0022] This invention provides a method for operating system containerization kernel compatibility based on hybrid binary translation, the process of which is as follows: Figure 1 As shown, the specific steps include:

[0023] Step 1: Denote the containerized operating system as the container system, the operating system that has a similar inheritance relationship with the container system as the standard system, and the operating system running on the host machine that is the same as or different from the standard system as the host system; denote the kernel data structure modified in the container system compared to the standard system as the target structure, and the corresponding modified kernel data structure in the standard system as the standard structure; determine the first mapping relationship between the target structure and the standard structure, which includes name, type, offset, and conversion function;

[0024] A basic feature library is formed by extracting the basic features of the target structure through static source code parsing, including structure name, field name, field type, offset, and alignment requirements. The code containing the target structure is then compiled to obtain the target file, and the offsets in the basic feature library are corrected according to the memory layout of the target file. A container application is executed in an independently running container system, and the access frequency of the target fields related to the target structure in the basic feature library is collected. Target fields with access frequencies greater than a first threshold are marked as high-frequency fields, and target fields with access frequencies less than a second threshold are marked as low-frequency fields. The basic feature library with the access frequencies of the target fields is formed into a first feature library.

[0025] Create a unique identifier for the target structure in the first feature library. This unique identifier consists of the structure name and a sequence of offsets for all high-frequency fields. The offsets in the sequence are arranged in descending order of access frequency.

[0026] Furthermore, to facilitate retrieval, the present invention converts the information of the target structure in the first feature library into binary format before storing it.

[0027] Step 2: Identify the target fields related to system calls in the container application through static call analysis. Establish a mapping relationship between system calls and target fields based on the first mapping relationship, denoted as the second mapping relationship. Then, execute the container application in the independently running container system, dynamically track the access path of the target fields, obtain the offset of the target fields, and use the offset to update the first feature library. Based on the second mapping relationship and the first feature library, establish an association graph between system calls, target structures, and target fields, including system call name, call number, target structure, target field, access type, and field access percentage.

[0028] Step 3: On the host machine, build a static translation service and a dynamic translation engine running in user space. The static translation service is used to perform static pre-conversion based on the association graph, and the dynamic translation engine is used to perform conversion on demand based on the association graph. Create a first cache to store information related to high-frequency fields. This cache uses the call number and the offset of the target field as the key, and the offset of the converted host field and the address of the conversion function as the value. Create a second cache to store the pre-translation results based on structural features.

[0029] Step 4: The static translation service decompiles the container application, locates the system call instructions, and marks the system call instructions as high-frequency or low-frequency sites based on the first feature library and the association graph. The first converter is instrumented at the high-frequency sites, and the second converter is instrumented at the low-frequency sites. For system call instructions related to high-frequency fields in the association graph, the access instructions of the target field are identified. The first offset and type of the target field and the second offset of the host field are obtained based on the first feature library. An intermediate opcode sequence is constructed, wherein the intermediate opcode sequence contains one or more combinations consisting of an opcode, a target field name, a first offset, and a second offset. The pre-translation result is saved to the second cache with the instruction address and structure name of the system call instruction as the key and the intermediate opcode sequence as the value.

[0030] Among them, high-frequency stations are system call instructions related to high-frequency fields, and low-frequency stations are system call instructions related to low-frequency fields.

[0031] Step 5: When the container application starts, it loads the pre-translated results in the second cache. When it reaches a high-frequency site, it triggers the first converter. The first converter obtains the instruction address and structure name of the system call. If the second cache is hit, it reads the intermediate opcode sequence of the second cache to complete the conversion and generate the host machine instruction.

[0032] If the second cache is not hit, the first offset of the target field is loaded, and the first cache is searched according to the call number and the first offset. If the first cache is hit, the offset of the host field and the conversion function are obtained to complete the conversion, generate the host machine instruction, and at the same time construct the intermediate opcode sequence and write it into the second cache; if the first cache is not hit, step 6 is executed.

[0033] When the process reaches a low-frequency site, the second converter is triggered, and the second converter executes step 6.

[0034] Step 6: The dynamic translation engine parses the target fields related to the current system call, treats them as sensitive fields, and obtains the instructions related to the sensitive fields. If the instruction is a normal instruction, it is ignored.

[0035] When the instruction is an access instruction, the instruction is intercepted and the field address operated on by the instruction is verified to be the same as that of the sensitive field. If they are the same, when the instruction is a read operation, the data is read from the address corresponding to the second offset of the host field, converted, and written to the address corresponding to the first offset of the target field. When the instruction is a write operation, the data is read from the address corresponding to the first offset of the target field, converted, and written to the address corresponding to the second offset, thus completing the conversion. If they are different, the instruction is ignored.

[0036] For pointer-intensive data structures, to further improve query efficiency, this invention establishes a circular pointer pool to store the mapping relationship between target pointers and host pointers, specifically as follows:

[0037] Based on the address range of the container system pointers, multiple circular pointer pools are created. Each circular pointer pool corresponds to an address segment. Each circular pointer pool contains a circular buffer with a fixed size. The circular buffer stores multiple mapping entries. Each mapping entry contains the target pointer, the host pointer, the access timestamp, and the kernel object ID.

[0038] Upon receiving the target pointer, the circular pointer pool is determined based on the pointer address range. Starting from the tail pointer, the circular buffer is traversed. If a buffer is hit, the access timestamp is updated and the host pointer is returned; otherwise, a new mapping entry is created in the circular buffer. If the circular buffer is not full, the new mapping entry is written to the head pointer position and the head pointer is moved forward. If the circular buffer is full, the mapping entry with the smallest access timestamp is deleted, the pointer is moved forward, and the new mapping entry is written to the head pointer position.

[0039] Furthermore, to prevent the generation of dangling pointers, this invention binds the lifecycle of pointer mappings to the host system's kernel objects, automatically cleaning up the associated pointer mappings when the kernel objects are released. Specifically:

[0040] When creating a mapping entry, the ID of the associated kernel object in the host system is recorded; when a system call related to releasing a kernel object is intercepted, the kernel object ID is obtained, and the ring pointer pool is traversed to delete valid mapping entries with the same kernel object ID.

[0041] Furthermore, to improve the reliability of the conversion process, this invention verifies the conversion results, specifically as follows:

[0042] Based on the first feature library, high-frequency fields and pointer-intensive data structures are divided into different verification groups. During the conversion process, a double buffer, including a main buffer and a backup buffer, is constructed for the conversion result. The main buffer stores the field-level conversion result, while the backup buffer uses an independent conversion function to obtain the backup conversion result. Only the cyclic redundancy check values ​​of high-frequency fields in the main buffer and the backup buffer are compared. If they match, the conversion is determined to be correct. If they do not match, the default value is used and an error log is recorded.

[0043] Example:

[0044] This embodiment uses OpenHarmony as the container system and Linux as the host system as an example. It employs a hybrid binary translation-based operating system containerization kernel compatibility method provided by this invention, solving the compatibility problem between OpenHarmony and standard Linux. The specific process includes:

[0045] S1. Incompatible data structure feature anchoring and field-level dependency graph construction.

[0046] S1.1 Field-level feature anchoring for incompatible data structures.

[0047] S1.1.1 Feature Extraction Toolchain and Process.

[0048] Static source code analysis: Using the OpenHarmony official Clang cross-compilation toolchain (version 14.0.0), AST (Abstract Syntax Tree) analysis is performed on kernel data structure header files (such as fs.h, stat.h, and dirent.h) to extract basic features such as structure name, field name, field type, offset, and alignment requirements. For example, when parsing structohm_file, the AST is generated using the clang-Xclang-ast-dump-fsyntax-onlyfs.h command, and the distributed_fd field is obtained by traversing the AST nodes, showing that the field type is int and the offset is 12 bytes.

[0049] Compilation Verification: Compile the code containing the target structure into an object file (.o). Use the `objdump-sj.data` command to view the memory layout of the structure and verify the consistency between the statically resolved offset and the actual compilation result. For example, after compiling the `structohm_file` test code, the `objdump` output shows that the starting address of the `ohm_pos` field is 0x04, which perfectly matches the 4-byte offset of the statically resolved offset, ensuring the accuracy of the feature.

[0050] Dynamic access sampling: Run the target program (such as dfs_server) in the native OpenHarmony environment, and collect the access frequency of structure fields through perfrecord-emem:load / store, marking high-frequency fields (access rate ≥ 50%) and low-frequency fields (access rate < 10%). For example, sampling found that ohm_flags (access rate 90%) and ohm_pos (85%) of structohm_file are high-frequency fields, distributed_fd (30%) is a medium-frequency field, and ohm_reserved (5%) is a low-frequency field.

[0051] S1.1.2, List of field-level features of core incompatible structures.

[0052] Based on the above process, a list of field-level features for three core structures is generated (taking OpenHarmony 5.0 and Linux 5.15 as examples), as shown in the table below:

[0053] Table 1 List of Field-Level Features

[0054] Incompatible structures field name Field type OpenHarmony offset (bytes) Linux corresponding fields Linux offset (bytes) Linux type Access frequency Field Function structohm_file ohm_flags unsignedint 0 f_flags 16 unsignedint 90% File access permission flags ohm_pos __u32 4 f_pos 24 loff_t (64-bit) 85% Current file offset distributed_fd int 12 none - - 30% Distributed file identifier ohm_reserved unsignedchar 16 none - - 5% Reserved fields structohm_stat ohm_st_size __off_t (32-bit) 12 st_size 24 off_t (64-bit) 95% File size ohm_st_mode __mode_t 8 st_mode 16 mode_t 80% File types and permissions ohm_st_ino __ino_t 4 st_ino 8 ino_t (64-bit) 70% index node number structohm_dirent ohm_next structohm_dirent* 8 d_next 16 structdirent* 95% Next directory entry pointer d_ino __ino_t 0 d_ino 0 ino_t 90% Directory entry index node number d_reclen unsignedshort 6 d_reclen 10 unsignedshort 85% Directory entry record length

[0055] S1.1.3, Uniqueness Guarantee and Storage of Features.

[0056] Unique anchoring: For each incompatible structure, a combination of the structure name and the offset of high-frequency fields is used as a unique identifier. For example, the identifier of structohm_file is ohm_file_0_4, that is: structure name + ohm_flags offset 0 + ohm_pos offset 4, to avoid confusion with the native Linux structure.

[0057] Feature storage: Field-level features are converted into binary format and stored in the structure feature library ( / etc / ohm_struct_db.bin), supporting fast queries by structure name and field name (query time <100ns). An example of the format is shown below:

[0058] / / Binary storage format of the structural feature library (structure definition)

[0059] struct_feature{

[0060] char struct_name

[64] ; / / Structure name (e.g., "struct ohm_file")

[0061] char field_name

[64] ; / / Field name (e.g., "ohm_flags")

[0062] uint8_tfield_type; / / Field type (0=int, 1=uint32_t, 2=pointer, etc.)

[0063] uint32_tohm_offset; / / Offset in OpenHarmony (bytes)

[0064] uint32_tlinux_offset; / / Offset in Linux (in bytes, 0xFFFFFFFF if none)

[0065] charlinux_field

[64] ; / / Linux field name (empty if none)

[0066] uint8_taccess_freq; / / Access frequency (0 = low frequency, 1 = medium frequency, 2 = high frequency)

[0067] };

[0068] S1.2, Construction of the association map.

[0069] By analyzing static calls and tracing dynamic processes, we can identify which fields of which structures each system call will access, build a field-level relationship graph, provide a basis for subsequent on-demand conversion, and avoid full conversion.

[0070] Static call analysis: Based on the ClangAST toolchain, the ELF files of OpenHarmony programs (such as / system / bin / ls) are parsed, and system call-related functions (such as __openat and __read) are traversed. The structure fields involved in the function parameters and return values ​​are analyzed. For example, when analyzing the __openat function, it is found that it writes the flags parameter to the structohm_file.ohm_flags field and reads the ohm_pos field to initialize the file offset.

[0071] Dynamic runtime tracing: Run the program in the native OpenHarmony environment and record the parameters and return values ​​of system calls using `strace-etrace=openat,read,getdents64`. Combine this with gdb breakpoint debugging to trace the access paths of fields. For example, tracing the `read` call reveals that it reads the `structohm_file.ohm_pos` field to determine the starting position and writes to the `ohm_pos` field to update the offset.

[0072] Graph Integration: Integrating static analysis and dynamic tracing results, a graph of the relationship between system calls and structural fields is constructed. Each system call node is associated with the structure, field list, and access type (read / write) it accesses, as shown in the table below:

[0073] Table 2 Association Map

[0074] System call Call number (Linux 5.15) Involving structure Access Field List Access type Field access percentage openat 257 structohm_file ohm_flags (write), distributed_fd (write) Write 90% / 30% read 0 structohm_file ohm_pos (read / write), ohm_flags (read) Reading / Writing 85% / 70% stat 4 structohm_stat ohm_st_size (read), ohm_st_mode (read) read 95% / 80% getdents64 217 structohm_dirent ohm_next (read / write), d_ino (read), d_reclen (read) Reading / Writing 95% / 90% / 85%

[0075] The constructed association graph is deployed to the user-space translation service (ohm_translate_d) and the dynamic translation engine, respectively. The user-space service is used for static preprocessing, and the dynamic translation engine is used for on-demand conversion. The two synchronize graph updates in real time (such as adding structural fields) through shared memory to ensure consistency.

[0076] It achieves field-level feature anchoring for incompatible structures, instead of the coarse-grained structure-level extraction in existing technologies, laying the foundation for subsequent on-demand conversion; the association graph between system calls and structural fields clearly defines the scope of adaptation, so that only frequently accessed fields need to be processed in the dynamic stage, reducing the amount of data to be converted by 40%.

[0077] S2. Static preprocessing based on structural features.

[0078] Existing instrumentation uses the same logic for all system call sites. This embodiment designs high-frequency path instrumentation and low-frequency path instrumentation based on the access frequency of fields in the association graph to reduce redundant verification.

[0079] S2.1, Target positioning for stake insertion.

[0080] By disassembling the ELF file of the OpenHarmony program using decompilation tools (such as objdump-d), the addresses of system call instructions (syscall for x86 and svc for ARM) are located. Combined with the correlation map, high-frequency call sites (such as read and write, with a call ratio of ≥30%) and low-frequency call sites (such as getcwd and stat, with a call ratio of <10%) are marked.

[0081] S2.2, High-frequency path insertion.

[0082] Instrumentation logic: For frequently called sites (such as read), directly insert field-level transformation cache lookup and fast jump code, skipping redundant parameter parsing and full translation. For example, for the scenario where read calls access structohm_file.ohm_pos (a frequently called field), the instrumentation code pre-sets the offset (4 bytes) of ohm_pos and the transformation rule (__u32→loff_t). When the cache is hit, the transformation is performed directly without dynamic analysis.

[0083] Instrumentation code example (x86 architecture, based on OpenHarmonyread calling the site):

[0084] The original OpenHarmony program's read call instruction (address 0x4005A0)

[0085] ;0x4005A0:mov$0x00,%rax;__NR_read=0

[0086] ;0x4005A7:syscall; Triggers a system call

[0087] Code after high-frequency path instrumentation (for the structohm_file.ohm_pos field)

[0088] 0x4005A0:mov$0x00,%rax;Preserve the original system call number

[0089] 0x4005A7:mov$0x04,%rbx; Loads the OpenHarmony offset (4 bytes) of ohm_pos.

[0090] 0x4005AE:mov$0x18,%rcx; Loads the Linux offset (24 bytes, 0x18) of ohm_pos.

[0091] 0x4005B5:callquery_field_cache; Calls a field conversion cache query (parameters: %rax=call number, %rbx=OH offset, %rcx=Linux offset).

[0092] 0x4005BA:test%eax,%eax; Checks if the cache is hit (%eax=1 means a hit, 0 means a miss).

[0093] 0x4005BC:jnz0x400650; Hit: Jump to fast conversion logic (directly process ohm_pos)

[0094] 0x4005C2:jmp0x400700; Miss: Jump to low-frequency path (dynamic translation)

[0095] Cache design: A two-level cache of "call number + field offset" is built for high-frequency fields. The key is (syscall_num, ohm_offset) and the value is the converted Linux offset and the address of the converted function. The cache hit rate is initially 60% and stabilizes at over 90% after running.

[0096] S2.3, Low-frequency path insertion.

[0097] Instrumentation logic: For low-frequency call sites (such as stat), insert parameter parsing, structure type identification, and dynamic translation trigger code to ensure compatibility while avoiding the occupation of high-frequency path resources;

[0098] Key differences: Low-frequency paths do not have preset conversion rules and require dynamic querying of the structural feature library, but only parse instructions involving data structures, while ordinary instructions are executed directly natively, reducing the translation range by 70%.

[0099] S2.4 Instruction-level pre-translation based on structural features.

[0100] For instruction sequences related to system calls (such as field loading and pointer access), intermediate opcode translation is completed in the static phase, and only the intermediate opcode needs to be converted into native Linux instructions in the dynamic phase, reducing the overhead of real-time disassembly and analysis.

[0101] S2.4.1, Scope and Logic of Pre-translation.

[0102] Pre-translation scope: Only instruction sequences involving access to structural fields in the association graph are pre-translated, such as moveax,[rbp-0x10] (reading structohm_stat.ohm_st_size, offset 12 bytes). Ordinary instructions (such as addeax, ebx) are not pre-translated and are executed directly natively.

[0103] Intermediate opcode design: Define structure-specific intermediate opcodes, such as LOAD_FIELDohm_st_size,0xC,0x18 (load the ohm_st_size field, OH offset 0xC=12 bytes, Linux offset 0x18=24 bytes), STORE_FIELDohm_pos,0x4,0x18 (store the ohm_pos field);

[0104] Pre-translation process:

[0105] Disassemble the system call instruction sequence and identify field access instructions;

[0106] Query the structural feature library to obtain the OH offset, Linux offset, and type of the fields;

[0107] Intermediate opcodes are generated and stored in a shared memory called the pre-translation cache;

[0108] During the dynamic phase, intermediate opcodes are read and Linux native instructions are generated directly (e.g., moveax,[rbp-0x10]→movrax,[rbp-0x18]).

[0109] S2.4.2, Pre-translation cache management.

[0110] Cache structure: The instruction address and structure name are used as keys, and the intermediate opcode is used as the value. The validity period of the cache item is set to 1 hour to avoid errors caused by outdated structure features.

[0111] Warm-up mechanism: When the program starts, the pre-translation results of the instruction sequences of high-frequency calls (read, write, openat) in the association graph are preloaded. After warm-up, the pre-translation cache hit rate in the dynamic stage reaches more than 85%.

[0112] Layered instrumentation differentiates processing logic based on field access frequency, reducing execution steps by 60% after a cache hit on a high-frequency path; instruction-level pre-translation shifts the disassembly and analysis overhead of the dynamic stage to the static stage, reducing dynamic translation time by 70%.

[0113] S3, field-level on-demand dynamic translation and conversion.

[0114] Traditional dynamic translation processes all instructions. This embodiment filters instructions by type and determines the relationship between structure fields, translating only instructions involving incompatible structure fields, while other instructions are executed natively.

[0115] S3.1 Instruction type filtering.

[0116] The instruction decoder in the dynamic translation engine categorizes instructions into three types, processing only the third type:

[0117] Ordinary instructions, such as arithmetic operations (add, sub) and logical operations (and, or), which do not involve memory access or only access local variables, are executed directly natively;

[0118] Unstructured memory access instructions, such as accessing string constants and global variables (which do not involve incompatible structures), are executed directly in their native form.

[0119] Structure field access instructions: Instructions for accessing structohm_file.ohm_pos and structohm_dirent.ohm_next need to be translated and converted.

[0120] S3.2, Determine the association between structural fields.

[0121] For memory access instructions, determine whether incompatible structure fields are involved by matching address ranges and verifying structural features:

[0122] Address range matching: Incompatible memory structures in OpenHarmony programs are allocated in a dedicated address range (such as 0x70000000-0x7FFFF000), which is fixed by the MAP_FIXED flag during mmap. If the target address of a memory access instruction is not within this range, it will be executed directly natively.

[0123] Structural feature verification: If the address is within the specified range, query the structural feature library from step 1 to verify whether the address matches the field offset of a certain structure (e.g., address 0x70000004 matches the offset of 4 bytes of structohm_file.ohm_pos). If they do not match, execute natively.

[0124] S3.3, the core logic of field-level lazy loading.

[0125] For basic structures (such as structohm_stat and structohm_file), a "field-level lazy loading" strategy is adopted, which triggers the conversion of a field only when the program accesses a field, rather than converting the entire structure.

[0126] Taking the ohm_st_size field of struct ohm_stat (12 bytes offset in OH, 24 bytes offset in Linux) as an example, the dynamic conversion process is as follows:

[0127] Instruction interception: Intercept instructions that allow the program to access ohm_st_size (such as moveax,[rbp-0x0C], where rbp-0x0C is the stack address of ohm_st_size).

[0128] Field identification: By calculating the address (rbp-0x0C) and matching it with the structure feature library, it is determined that the accessed field is structohm_stat.ohm_st_size;

[0129] Convert on demand:

[0130] If it is a read operation: read the value (64 bits) from the st_size field (offset 24 bytes) of the Linux native structure, convert it to a 32-bit __off_t, and write it to the address of the ohm_st_size field of the program;

[0131] If it is a write operation: read a 32-bit value from the program's ohm_st_size field, convert it to a 64-bit off_t, and write it to the st_size field of the Linux native structure;

[0132] Command release: After the conversion is complete, modify the target address of the command (e.g., rbp-0x0C→rbp-0x18, corresponding to a Linux offset of 24 bytes), and execute the modified command natively.

[0133] Example code for field-level transformation (based on OpenHarmonystat call):

[0134] / / Field-level lazy-loading transformation functions in the dynamic translation engine (for struct ohm_stat.ohm_st_size)

[0135] voidlazy_convert_ohm_st_size (void*ohm_addr, uint8_taccess_type) {

[0136] / / 1. Obtain the corresponding Linux field information from the structural feature library.

[0137] structstruct_feature*feat=get_struct_feature("structohm_stat","ohm_st_size");

[0138] if (feat == NULL) return;

[0139] / / 2. Calculate the field addresses of the Linux native structure (assuming the Linux structure base address is linux_base_addr)

[0140] void*linux_field_addr=(char*) linux_base_addr+feat->linux_offset;

[0141] if(access_type==ACCESS_READ) {

[0142] / / Read operation: Linux → OpenHarmony (64-bit off_t → 32-bit __off_t)

[0143] off_tlinux_st_size;

[0144] __off_tohm_st_size;

[0145] / / Read Linux field values

[0146] linux_st_size=*(off_t*)linux_field_addr;

[0147] / / Type conversion (truncated to 32 bits to ensure it is within the range supported by OpenHarmony)

[0148] ohm_st_size=(linux_st_size>0xFFFFFFFF)?0xFFFFFFFF:(__off_t)linux_st_size;

[0149] / / Write the address of the OpenHarmony field

[0150] *(__off_t*)ohm_addr=ohm_st_size;

[0151] }elseif(access_type==ACCESS_WRITE){

[0152] / / Write operation: OpenHarmony → Linux (32-bit __off_t → 64-bit __off_t)

[0153] __off_tohm_st_size=*(__off_t*)ohm_addr;

[0154] *(off_t*)linux_field_addr=(off_t)ohm_st_size;

[0155] }

[0156] }

[0157] S3.4 Dynamic hits and updates of the pre-translation cache.

[0158] The dynamic phase first queries the pre-translation cache. If a match is found, the intermediate opcode is used directly to generate the native instruction. If a match is missed, dynamic analysis and pre-translation cache updates are triggered.

[0159] Cache hit: Read intermediate opcodes (such as LOAD_FIELDohm_st_size, 0xC, 0x18), generate Linux native instructions (movrax, [rbp-0x18]), and execute in less than 10 ns;

[0160] Cache miss: The instruction is dynamically analyzed, intermediate opcodes are generated, and the translation is performed. At the same time, the intermediate opcodes are written to the pre-translation cache for subsequent use. The time taken for miss processing is less than 100ns, which is much lower than the 1μs of full instruction translation.

[0161] Dynamic translation range pruning enables 90% of ordinary instructions to be executed natively, reducing the number of translated instructions by 90%; field-level lazy loading avoids full structure conversion, reducing the amount of converted data by 55%, and the time consumption of dynamic conversion of high-frequency fields is reduced to 30% of the original solution.

[0162] S4, Pointer-intensive circular pointer pool and lifecycle management.

[0163] For pointer-intensive structures such as `structohm_dirent` linked lists and `structohm_dentry` hash trees, traditional solutions rely on hash tables for pointer redirection, resulting in low query efficiency and lack of lifecycle management. A circular pointer pool is designed to optimize query efficiency, and lifecycle binding prevents dangling pointers, ensuring efficient and safe conversion of complex structures.

[0164] S4.1 Design and implementation of a circular pointer pool.

[0165] Based on pointer-intensive access patterns (such as sequential access in linked lists), a circular buffer is designed to store OpenHarmony pointer-Linux pointer mapping pairs, which significantly improves query efficiency.

[0166] S4.1.1 Structural design of the circular pointer pool.

[0167] Pool partitioning: Create multiple circular pointer pools based on the address range of OpenHarmony pointers (e.g., each 1MB is divided into a pool), with each pool corresponding to an address range, reducing the query range of a single pool;

[0168] Circular buffer structure: Each pool contains a fixed-size circular buffer (e.g., 1024 entries). Each entry stores an OH pointer, a Linux pointer, an access timestamp, and an associated kernel object ID, as shown in the following structure:

[0169] / / Entry structure of the circular pointer pool (for the struct ohm_dirent linked list)

[0170] structptr_pool_entry{

[0171] uint64_tohm_ptr; / / OpenHarmony pointer (e.g., struct ohm_dirent*)

[0172] uint64_tlinux_ptr; / / Linux pointer (e.g., struct dirent*)

[0173] uint64_taccess_ts; / / Last access timestamp (ns)

[0174] int kernel_obj_id; / / Associates with a Linux kernel object ID (such as a file descriptor fd)

[0175] uint8_tvalid; / / Whether the entry is valid (1 = valid, 0 = invalid)

[0176] };

[0177] / / Circular pointer pool structure

[0178] struct ring_ptr_pool{

[0179] uint64_taddr_start; / / Starting address of the OH pointer covered by this pool

[0180] uint64_t addr_end; / / The end address of the OH pointer covered by this pool

[0181] struct ptr_pool_entry *buf; / / Circular buffer

[0182] uint32_t buf_size; / / Buffer size (e.g., 1024)

[0183] uint32_t head; / / Head pointer (write position)

[0184] uint32_t tail; / / Tail pointer (read position)

[0185] uint32_t valid_count; / / Number of valid entries

[0186] };

[0187] S4.1.1. Query and Insert Process of Pointer Mapping.

[0188] Query Process:

[0189] Receive the OpenHarmony pointer (e.g., 0x70001238), locate the corresponding circular pool according to the address range; traverse the circular buffer starting from the tail pointer (tail), match ohm_ptr with valid = 1. Due to the sequential access characteristic of the linked list, the recently inserted entry (close to the head pointer) has a hit rate of 80%, and the average number of queries is only 5 times (the average of the hash table is 10 times); after hitting, update access_ts and return linux_ptr; if not hit, trigger the creation of a new mapping.

[0190] Insert Process:

[0191] Create a new ptr_pool_entry, fill in ohm_ptr, linux_ptr, kernel_obj_id (e.g., fd = 3 for getdents64 call); if the buffer is not full (valid_count < buf_size), write to the head pointer position and move the head pointer backward; if the buffer is full, eliminate the least recently accessed entry (the smallest access_ts, close to the tail pointer), move the tail pointer backward, and then write the new entry.

[0192] S4.2. Binding of Pointer Lifecycle and Linux Kernel Objects.

[0193] To prevent wild pointers (e.g., the Linux directory entry has been released, but the OH pointer is still accessed), bind the lifecycle of the pointer mapping to Linux kernel objects (such as file descriptors, process IDs). When the kernel object is released, the associated pointer mapping is automatically cleared.

[0194] Lifecycle binding logic includes:

[0195] Binding timing: When creating a pointer mapping, record the associated Linux kernel object ID (such as the fd of the getdents64 call, the pid of the fork call), for example, the structohm_dirent pointer is associated with fd=3;

[0196] Release trigger: Intercept the Linux kernel system calls that release objects (such as close to release file descriptor, exit to release process ID), and obtain the object ID;

[0197] Mapping cleanup: Traverse all circular pointer pools, delete entries that match kernel_obj_id and have valid=1, mark valid=0, and decrement valid_count.

[0198] Clean up the example code (releasing the file descriptor during the close call).

[0199] / / Pointer mapping cleanup function (triggered when close is called to release file descriptor)

[0200] voidclean_ptr_mapping_by_fd(intfd){

[0201] / / Traverse all circular pointer pools

[0202] for(int i=0;i <POOL_NUM;i++){

[0203] structring_ptr_pool*pool=&ptr_pools[i];

[0204] if(pool->valid_count==0) continue;

[0205] uint32_tcurr=pool->tail;

[0206] / / Traverse the circular buffer

[0207] while(1){

[0208] if(pool->buf[curr]. valid&&pool->buf[curr].kernel_obj_id==fd){

[0209] / / Clean up associated pointer mappings

[0210] pool->buf[curr].valid=0;

[0211] pool->valid_count--;

[0212] bpf_printk("Cleanptrmapping:ohm_ptr=0x%lx,fd=%d",

[0213] pool->buf[curr].ohm_ptr,fd);

[0214] }

[0215] if (curr == pool->head) break;

[0216] curr = (curr + 1) % pool->buf_size;

[0217] }

[0218] }

[0219] }

[0220] The circular pointer pool, based on the sequential nature of pointer access, improves query efficiency by 50% compared to hash tables; the lifecycle binding mechanism completely solves the dangling pointer problem, reduces memory leak rate to 0, and improves conversion efficiency of complex linked list structures by 180%.

[0221] S5 features structure-specific verification and hardware-level optimization.

[0222] Focusing on conversion accuracy and execution efficiency, we designed a dedicated verification mechanism for the characteristics of different structures and optimized the conversion logic in conjunction with the CPU hardware instruction set to achieve a precise and efficient closed loop.

[0223] S5.1, Structure-specific double buffer verification.

[0224] Traditional verification uses the general CRC32 checksum, which does not take into account the characteristics of the structured fields. We need to design dedicated verification granularity for different structured field types (such as integers and pointers) to improve verification accuracy and efficiency.

[0225] S5.1.1, Verify the structural adaptation of granularity.

[0226] Basic structure (e.g., structohm_stat): Verify by high-frequency field groups, such as ohm_st_size + ohm_st_mode as a group, only verify these two fields, avoid redundant verification of low-frequency fields, and reduce verification time by 40%;

[0227] Pointer-intensive structures (such as structohm_dirent): Verification is performed by combining nodes and pointers. Each linked list node's d_ino + ohm_next forms a group to ensure the consistency between node data and pointers and prevent linked list breakage.

[0228] S5.1.2, Double Buffer Verification Process.

[0229] Taking structohm_file as an example, the verification process is as follows:

[0230] Main buffer transformation: Performs field-level transformations to generate main buffer data;

[0231] Alternate buffer transformation: Using a separate transformation function (without sharing logic with the main buffer function), the transformation is re-executed to generate alternate buffer data;

[0232] Dedicated verification: Only compare the CRC32 values ​​of high-frequency fields (ohm_flags, ohm_pos). If they match, the conversion is confirmed to be correct; if they do not match, use the preset default value (e.g., ohm_pos=0) and record the error in the log.

[0233] S5.2 Hardware-level optimization based on CPU instruction set.

[0234] Based on the type of the structure field (such as 32-bit / 64-bit integers, consecutive fields), select the CPU's extended instruction set (such as AVX2 for x86, NEON for ARM) to optimize the conversion logic and improve the efficiency of field copying and type conversion.

[0235] For consecutive high-frequency fields in the structure (such as ohm_flags+ohm_pos of structohm_file, which is a total of 8 bytes), SIMD instructions (such as the vmovdqu instruction of the AVX2 instruction set, which copies 32 bytes at a time) are used for batch copying, which improves the copying efficiency by 4 times compared to ordinary mov instructions.

[0236] The ARMNeon example code is as follows:

[0237] / / Batch copy of high-frequency fields in structohm_file based on ARMNEON instructions (compatible with ARMv8 and above architectures)

[0238] #include<arm_neon.h>

[0239] voidneon_copy_ohm_file_high_freq(void*dst,constvoid*src){

[0240] / *

[0241] *Input parameter description:

[0242] *src: The base address of OpenHarmonystructohm_file, storing two frequently used fields (8 bytes in total):

[0243] * -src+0: ohm_flags(unsignedint, 32-bit, file permission flags)

[0244] *-src+4:ohm_pos(__u32, 32-bit, file offset)

[0245] *dst: The base address of the Linux struct file, which needs to store two destination fields (12 bytes in total):

[0246] *-dst+0: f_flags(unsignedint, 32-bit, corresponding to ohm_flags)

[0247] *-dst+4: f_pos(loff_t, 64-bit, obtained by zero-expansion of ohm_pos)

[0248] /

[0249] / / 1. Load OpenHarmony high-frequency fields into NEON vector registers (supports unaligned access)

[0250] / / Load two 32-bit unsigned numbers from src and store them in d0 (ohm_flags) and d1 (ohm_pos) respectively.

[0251] uint32x2_tohm_fields=vld1_u32((constuint32_t*)src);

[0252] uint32_tohm_flags = vget_lane_u32(ohm_fields, 0); / / Extract the 0th 32-bit element (ohm_flags) of d0.

[0253] uint32_tohm_pos=vget_lane_u32(ohm_fields,1); / / Extract the 0th 32-bit element (ohm_pos) of d1

[0254] / / 2. Field type conversion: ohm_pos (32-bit unsigned) → f_pos (64-bit unsigned)

[0255] / / Use the NEON zero-extension instruction to extend the 32-bit ohm_pos to 64 bits (the result is stored in ARM general-purpose register x1).

[0256] uint64_tf_pos = (uint64_t)vmovl_u32(ohm_pos); / / vmovl_u32: 32 → 64-bit zero-extended

[0257] uint32_tf_flags = ohm_flags; / / ohm_flags is of the same type as f_flags, so it can be directly assigned a value.

[0258] / / 3. Store the converted fields to the corresponding location in the Linux struct file.

[0259] / / 3.1 Store f_flags (32 bits) at offset dst+0

[0260] vst1_u32((uint32_t*)dst,vdup_n_u32(f_flags)); / / vdup_n_u32: Copies f_flags as a vector, stored in vst1_u32

[0261] / / 3.2 Store f_pos (64-bit) to offset dst+4 (ARM general-purpose registers directly store 64-bit data)

[0262] *((uint64_t*)((char*)dst+4))=f_pos;

[0263] }

[0264] The following is an example code for x86AVX2:

[0265] / / Batch copy of frequently used fields in structohm_file based on AVX2 (optimized version)

[0266] voidavx2_copy_ohm_file_high_freq(void*dst,constvoid*src){

[0267] / / src: Address of OpenHarmonystructohm_file (including ohm_flags + ohm_pos, 8 bytes)

[0268] / / dst: Linux struct file address (including f_flags + f_pos, 12 bytes)

[0269] __m256isrc_vec,dst_vec;

[0270] / / Read high-frequency fields from OpenHarmony (8 bytes, zero-extended to 32 bytes)

[0271] src_vec=_mm256_loadu_si256((__m256i*)src);

[0272] / / Extract ohm_flags (lower 32 bits) and ohm_pos (bits 32-63)

[0273] uint32_tohm_flags=_mm256_extract_epi32(src_vec,0);

[0274] uint32_tohm_pos=_mm256_extract_epi32(src_vec,1);

[0275] / / Convert to Linux fields (f_flags=ohm_flags, f_pos=ohm_pos zero-extended to 64 bits)

[0276] uint32_tf_flags=ohm_flags;

[0277] uint64_tf_pos=(uint64_t)ohm_pos;

[0278] / / Batch write to Linux fields (f_flags + padding + f_pos, total 12 bytes)

[0279] dst_vec=_mm256_setzero_si256();

[0280] dst_vec=_mm256_insert_epi32(dst_vec,f_flags,0);

[0281] dst_vec=_mm256_insert_epi64(dst_vec,f_pos,1);

[0282] _mm256_storeu_si256((__m256i*)dst,dst_vec);

[0283] }

[0284] Type conversion optimization: For type conversions from 32-bit to 64-bit (such as ohm_pos→f_pos), the x86 movzx instruction (zero extension) or movsx instruction (sign extension) is used, which reduces the conversion time by 50% compared to ordinary arithmetic operations.

[0285] Dedicated structure validation reduces the amount of validation data by 40% while improving accuracy; hardware-level optimization improves the efficiency of field copying and type conversion by 2-4 times, and reduces the overall runtime overhead of high-frequency system calls to below 8%.

[0286] This embodiment supports OpenHarmony 3.0+ ELF programs running on Linux 5.4+ kernels, achieving 99.5% system call compatibility and covering core scenarios such as file operations, process management, and distributed services. The total translation and conversion overhead of high-frequency system calls (such as read and write) is reduced to below 8%, and the overall program running efficiency is improved by 220% compared to traditional hybrid binary translation schemes, approaching the performance of native Linux programs. Field-level on-demand conversion reduces the amount of data processing in the dynamic stage by 55%, and the circular pointer pool improves the efficiency of pointer lookup for complex structures by 50%. Pointer lifecycle binding and structure-specific verification reduce the runtime error rate to below 0.05% and the memory leak rate to 0. The design of the structure feature library and intermediate opcodes supports the adaptation of new OpenHarmony structures or system calls, reducing the adaptation cost by 65% ​​without refactoring the core logic.

[0287] In summary, the above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for operating system containerization kernel compatibility based on hybrid binary translation, characterized in that, Specifically, the following steps are included: Establish the first mapping relationship between the target structure of the container system and the standard structure of the standard system; extract the field names, types, offsets and alignment requirements of the target structure to form basic features through static source code analysis and post-compilation memory layout correction; collect the access frequency of the target fields by running the container system, and mark the high-frequency and low-frequency fields in the basic features to form the first feature library; determine the target fields related to system calls in the container application, and establish the second mapping relationship from system calls to target fields based on the first mapping relationship to form an association graph containing call number, structure, field, access type and field access ratio; Deploy a static translation service and a dynamic translation engine on the host machine, create a first cache with the call number and the first offset of the target field as the key, save the second offset of the host field and the conversion function, and save the pre-translated intermediate opcode sequence in a second cache; The static translation service inserts a first converter at system calls for high-frequency fields and a second converter at system calls for low-frequency fields. For high-frequency fields, an intermediate opcode sequence containing opcode, field name, container offset, and host offset is generated in advance and stored in a second cache. When the container application runs, the first converter first checks the second cache to obtain the pre-translation result. If it misses the result, it checks the first cache. If it still misses the result, it triggers the dynamic translation engine to complete the conversion. The second converter then triggers the dynamic translation engine to complete the conversion.

2. The operating system containerization kernel compatibility method according to claim 1, characterized in that, Generate a unique identifier for the target structure consisting of the structure name and a sequence of offsets for high-frequency fields, wherein the offsets in the offset sequence are arranged in descending order of access frequency.

3. The operating system containerization kernel compatibility method according to claim 1, characterized in that, The dynamic translation engine parses the target field of the system call as a sensitive field, obtains the instructions related to the sensitive field, and ignores the instructions when they are ordinary instructions. When the instructions are access instructions, the engine intercepts the instructions and verifies whether the field address operated on by the instructions is the same as the sensitive field. If they are the same, when the instructions are read, the data is read from the address corresponding to the second offset of the host field, converted, and written to the address corresponding to the first offset of the target field. When the instructions are write, the data is read from the address corresponding to the first offset of the target field, converted, and written to the address corresponding to the second offset, thus completing the conversion. If they are different, the instructions are ignored.

4. The operating system containerization kernel compatibility method according to claim 1, characterized in that, Based on the address range of the container system pointers, multiple circular pointer pools are created. Each circular pointer pool corresponds to an address segment. Each circular pointer pool contains a circular buffer, which stores multiple mapping entries. Each mapping entry contains a target pointer, a host pointer, an access timestamp, and a kernel object ID. Upon receiving the target pointer, the circular pointer pool is determined based on the pointer address range. The circular buffer is traversed starting from the tail pointer. If a buffer is hit, the access timestamp is updated and the host pointer is returned. Otherwise, a new mapping entry is created in the circular buffer. If the circular buffer is not full, the new mapping entry is written to the head pointer position and the head pointer is moved forward. If the circular buffer is full, the mapping entry with the smallest access timestamp is deleted, the pointer is moved forward, and then the new mapping entry is written to the head pointer position.

5. The operating system containerization kernel compatibility method according to claim 4, characterized in that, The size of the circular buffer is a fixed value.

6. The operating system containerization kernel compatibility method according to claim 4, characterized in that, When creating a mapping entry, the ID of the associated kernel object in the host system is recorded; when a system call related to releasing a kernel object is intercepted, the kernel object ID is obtained, and the circular pointer pool is traversed to delete valid mapping entries with the same kernel object ID.

7. The operating system containerization kernel compatibility method according to claim 4, characterized in that, Based on the first feature library, high-frequency fields and pointer-intensive data structures are divided into different verification groups. During the conversion process, a double buffer, including a main buffer and a backup buffer, is constructed for the conversion result. The conversion result is stored in the main buffer, while the backup buffer uses an independent conversion function to obtain the backup conversion result. Only the cyclic redundancy check values ​​of high-frequency fields in the main buffer and the backup buffer are compared. If they match, the conversion is determined to be correct. If they do not match, the default value is used and an error log is recorded.

8. The operating system containerization kernel compatibility method according to claim 1, characterized in that, The target structure information in the first feature library is converted into binary format before being stored.

Images