An operating system containerization kernel compatibility method based on hybrid binary translation

Abstract

The application discloses a hybrid binary translation-based operating system containerization kernel compatibility method, and the method is characterized in that: through static source code analysis and dynamic runtime tracking, a container kernel data structure feature library containing field access frequency is constructed, a unique identifier composed of a structure name and a high-frequency field offset sequence is generated for a target structure, and an association atlas between a system call and a target field is established; in a host computer, a static translation service is used to decompile container application binary code, high-frequency sites and low-frequency sites are respectively instrumented, and an intermediate operation code sequence containing an operation code, a field name and a double-end offset is pre-generated for the high-frequency sites and stored in a cache; in runtime, a pre-translation result is preferentially loaded from the cache for the high-frequency sites, and a dynamic translation engine is used to process the high-frequency sites when the pre-translation result is not hit, and the dynamic translation engine is used to process the low-frequency sites on demand, so that efficient conversion combining field-level static preprocessing and on-demand dynamic conversion is realized.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of cross-platform compatibility, and particularly relates to a hybrid binary translation-based operating system containerization kernel compatibility method. BACKGROUND

[0002] Containerization relies on the native mechanism of the operating system kernel to achieve isolation and resource management. The container system running in the container usually has a system call interface difference with the host system running on the host. For example, Linux relies on the POSIX standard system call, Windows uses Win32 API and NT kernel objects, and the calling methods and parameter structures of the two are completely different, which causes the binary file in the container to be unable to run directly across the kernel. For example, the socket network call of the Linux container cannot be parsed on the Windows NT kernel. In addition, the function library and data structure alignment method of different systems are different, so even applications of the same architecture (x86_64) cannot be executed across systems. Even if the container system and the host system are based on the same kernel, there may still be incompatibility problems. For example, the kernel of the Hongmeng system is developed based on the Linux kernel, but in order to meet the needs of distributed capabilities, lightweight device adaptation, etc., the core data structure of the kernel is deeply customized. For example: in the file management module, the struct file of the Hongmeng system adds the distributed file identifier distributed_id and the extended flag field ohm_flags to the Linux host structure; in the process management module, its struct task_struct extends the Hongmeng scheduling priority ohos_prio and the application capability identifier ability_id field; at the data structure level, its hash linked 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 difference in the kernel data structure of the two will cause problems such as system call parameter mismatch, pointer-intensive structure access conflict, and failure to adapt to underlying hardware differences.

[0003] The existing solution mainly monitors the system call initiated by the container application, and fails to accurately lock at the data structure level according to the access frequency, so there are problems such as full conversion redundancy, high dynamic translation loss, and low efficiency of processing complex structures, especially in the case of limited performance of the host system. SUMMARY

[0004] Therefore, the application provides a hybrid binary translation-based operating system containerization kernel compatibility method, which realizes efficient compatibility of the container system and the host system by combining field-level static preprocessing and on-demand dynamic conversion.

[0005] The application provides a hybrid binary translation-based operating system containerization kernel compatibility method, and specifically comprises the following steps:

[0006] A first mapping relationship between a target structure of a container system and a standard structure of a standard system is established; through static source code analysis and post-compilation memory layout correction, field names, types, offsets and alignment requirements of the target structure are extracted to form basic features; the target fields are collected by running the container system, and high-frequency fields and low-frequency fields in the basic features are marked to form a first feature library; target fields related to system calls in the container application are determined, a second mapping relationship from the system calls to the target fields is established according to the first mapping relationship, and an associated graph including call numbers, structures, fields, access types and field access proportions is formed;

[0007] A static translation service and a dynamic translation engine are deployed on a host computer, a first cache is created with the call number and the first offset of the target field as the key, the second offset of the host field and the conversion function are saved, and a second cache of the pre-translation intermediate operation code sequence is saved;

[0008] The static translation service inserts a first converter at the system call of the high-frequency field and a second converter at the system call of the low-frequency field, generates an intermediate operation code sequence including the operation code, the field name, the container offset and the host offset in advance for the high-frequency field, and stores the intermediate operation code sequence in the second cache; when the container application runs, the first converter preferentially acquires the pre-translation result from the second cache, and if the pre-translation result is not acquired, the first converter searches the first cache, and if the pre-translation result is still not acquired, the dynamic translation engine is triggered to complete the conversion; the second converter triggers the dynamic translation engine to complete the conversion.

[0009] Further, a unique identifier composed of the structure name and the offset sequence of the high-frequency field is generated for the target structure, and the arrangement order of the offsets in the offset sequence is from high to low according to the access frequency.

[0010] Further, the dynamic translation engine analyzes the target field of the system call as a sensitive field, acquires instructions related to the sensitive field, and ignores the instructions when the instructions are normal instructions; when the instructions are access instructions, the instructions are intercepted and it is verified whether the field address of the instruction operation is the same as the sensitive field, if the field address of the instruction operation is the same as the sensitive field, data is read from the address corresponding to the second offset of the host field and written into the address corresponding to the first offset of the target field when the instruction is a read operation, or data is read from the address corresponding to the first offset of the target field and written into the address corresponding to the second offset when the instruction is a write operation, and the conversion is completed; if the field address of the instruction operation is not the same as the sensitive field, the instruction is ignored.

[0011] Further, according to the address range of the container system pointer, a plurality of ring pointer pools are created, the ring pointer pool corresponds to an address segment, the ring pointer pool contains a ring buffer, and the ring buffer stores a plurality of mapping entries, each mapping entry contains a target pointer, a host pointer, an access timestamp and a kernel object ID;

[0012] After receiving the target pointer, the ring pointer pool is determined according to the pointer address range, the ring buffer is traversed from the tail pointer, if the buffer is hit, the access timestamp is updated and the host pointer is returned; otherwise, a new mapping entry is created in the ring buffer, if the ring buffer is not full, the new mapping entry is written to the head pointer position, the head pointer is moved, if the ring buffer is full, the mapping entry with the smallest access timestamp is deleted, the pointer is moved, and then the new mapping entry is written to the head pointer position.

[0013] Further, the size of the ring buffer is a fixed value.

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

[0015] Further, according to the first feature library, the high-frequency fields and pointer-intensive data structures therein are divided into different check 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 saves the conversion result, and the backup buffer uses an independent conversion function to obtain a 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 are consistent, it is determined that the conversion is correct, if they are inconsistent, a default value is used and an error log is recorded.

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

[0017] Beneficial effects:

[0018] The application builds a container kernel data structure feature library containing field access frequency through static source code analysis and dynamic runtime tracking, generates a unique identifier composed of a structure name and a high-frequency field offset sequence for the target structure, establishes an association graph between system calls and target fields, and explicitly depends on the kernel structure and field of each system call; in the host, the static translation service is used to decompile the container application binary code, the high-frequency site and the low-frequency site are instrumented respectively, and the intermediate operation code sequence containing the operation code, the field name and the double-end offset is pre-generated for the high-frequency site and stored in the cache; at runtime, the pre-translation result is loaded from the cache for the high-frequency site, and the dynamic translation engine is used to process when all the results are not hit, and the dynamic translation engine is used to process the low-frequency site as needed, realizing the efficient conversion of the combination of field-level static preprocessing and on-demand dynamic conversion. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 A flowchart of a hybrid binary translation-based operating system containerized kernel compatibility method provided by the application is shown. DETAILED DESCRIPTION

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

[0021] The hybrid binary translation-based operating system containerized kernel compatibility method provided by the application has the core idea that: through static source code analysis and dynamic runtime tracking, a container kernel data structure feature library containing field access frequency is built, a unique identifier composed of a structure name and a high-frequency field offset sequence is generated for the target structure, an association graph between system calls and target fields is established, and the kernel structure and field depended on by each system call are explicitly determined; in the host, the static translation service is used to decompile the container application binary code, the high-frequency site and the low-frequency site are instrumented respectively, and the intermediate operation code sequence containing the operation code, the field name and the double-end offset is pre-generated for the high-frequency site and stored in the cache; at runtime, the pre-translation result is loaded from the cache for the high-frequency site, and the dynamic translation engine is used to process when all the results are not hit, and the dynamic translation engine is used to process the low-frequency site as needed.

[0022] The hybrid binary translation-based operating system containerized kernel compatibility method provided by the application has the core idea that: through static source code analysis and dynamic runtime tracking, a container kernel data structure feature library containing field access frequency is built, a unique identifier composed of a structure name and a high-frequency field offset sequence is generated for the target structure, an association graph between system calls and target fields is established, and the kernel structure and field depended on by each system call are explicitly determined; in the host, the static translation service is used to decompile the container application binary code, the high-frequency site and the low-frequency site are instrumented respectively, and the intermediate operation code sequence containing the operation code, the field name and the double-end offset is pre-generated for the high-frequency site and stored in the cache; at runtime, the pre-translation result is loaded from the cache for the high-frequency site, and the dynamic translation engine is used to process when all the results are not hit, and the dynamic translation engine is used to process the low-frequency site as needed. Figure 1

[0023] ​Step 1, record the containerized operating system as a container system, record the operating system having a similar inheritance association with the container system as a standard system, record the operating system running on the host computer and having the same or different version of the standard system as a host system, record the kernel data structure modified in the container system compared with the standard system as a target structure, record the modified kernel data structure corresponding to the target structure in the standard system as a standard structure, determine the first mapping relationship between the target structure and the standard structure, and the first mapping relationship includes name, type, offset and conversion function;

[0024] The basic features of the target structure are extracted by static source code analysis to form a basic feature library, including structure name, field name, field type, offset and alignment requirement, etc. The code containing the target structure is recompiled to obtain a target file, and the offset in the basic feature library is corrected according to the memory layout of the target file. The container application is executed in an independently running container system, the access frequency of the target field related to the target structure in the basic feature library is collected, the target field with an access frequency greater than a first threshold is marked as a high-frequency field, and the target field with an access frequency less than a second threshold is marked as a low-frequency field. The basic feature library with the increased access frequency of the target field forms a first feature library.

[0025] A unique identifier is created for the target structure in the first feature library, and the unique identifier is composed of the structure name and the offset sequence of all high-frequency fields, wherein the arrangement order of the offsets in the offset sequence is from high to low according to the access frequency.

[0026] Further, in order to facilitate retrieval, the information of the target structure in the first feature library is converted into binary format before storage.

[0027] Step 2, determine the target field related to the system call in the container application by static call analysis, establish the mapping relationship from the system call to the target field according to the first mapping relationship, and record the mapping relationship as a second mapping relationship. Then, the container application is executed in an independently running container system, the access path of the target field is dynamically tracked, the offset of the target field is obtained, and the first feature library is updated using the offset. According to the second mapping relationship and the first feature library, an association graph between the system call and the target structure and the target field is established, including system call name, call number, target structure, target field, access type and field access proportion, etc.

[0028] Step 3, in the host machine, a static translation service running in the user state and a dynamic translation engine are constructed, wherein the static translation service is used to perform static pre-conversion according to the association graph, and the dynamic translation engine is used to perform conversion on demand according to the association graph; a first cache is created for saving high-frequency field related information, the cache taking 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; a second cache is created for saving pre-translation results based on structural features.

[0029] Step 4, the static translation service decompiles the container application, locates the instruction of the system call, marks the instruction of the system call as a high-frequency site or a low-frequency site according to the first feature library and the association graph, plugs the first converter at the high-frequency site, and plugs the second converter at the low-frequency site; for the system call instruction related to the high-frequency field in the association graph, the access instruction of the target field is identified, the first offset, the type of the target field and the second offset of the host field are obtained according to the first feature library, and an intermediate operation code sequence is constructed, wherein the intermediate operation code sequence contains one or more combinations composed of operation code, target field name, first offset and second offset, and the instruction address of the system call instruction and the structure name are taken as the key, and the intermediate operation code sequence is taken as the value as the pre-translation result saved to the second cache.

[0030] Wherein, the high-frequency site is the instruction of the system call related to the high-frequency field, and the low-frequency site is the instruction of the system call related to the low-frequency field.

[0031] Step 5, when the container application starts, the pre-translation result in the second cache is loaded, the first converter is triggered when the high-frequency site is executed, the instruction address of the system call and the structure name are obtained, if the second cache is hit, the intermediate operation code sequence of the second cache is read to complete the conversion, and the host machine instruction is generated;

[0032] If the second cache is not hit, the first offset of the target field is loaded, 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, and the host machine instruction is generated, and the intermediate operation code sequence is constructed and written into the second cache; if the first cache is not hit, step 6 is executed;

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

[0034] Step 6, the dynamic translation engine parses the target field related to the current system call, takes it as a sensitive field, obtains the instruction related to the sensitive field, and ignores the instruction when the instruction is a normal instruction.

[0035] When the instruction is an access instruction, the instruction is intercepted and it is verified whether the field address of the instruction operation is same as the sensitive field, if yes, when the instruction is a read operation, data is read from the address corresponding to the second offset of the host field, and the converted data is written to the address corresponding to the first offset of the target field, when the instruction is a write operation, data is read from the address corresponding to the first offset of the target field, and the converted data is written to the address corresponding to the second offset, and the conversion is completed; if not, the instruction is ignored.

[0036] For pointer-intensive data structures, in order to further improve the query efficiency, the application establishes a ring pointer pool to store the mapping relationship between the target pointer and the host pointer, specifically:

[0037] According to the address range of the container system pointer, a plurality of ring pointer pools are created, each ring pointer pool corresponds to an address segment, each ring pointer pool contains a ring buffer, the size of the ring buffer is a fixed value, and the ring buffer stores a plurality of mapping entries, each mapping entry contains a target pointer, a host pointer, an access timestamp and a kernel object ID.

[0038] After receiving the target pointer, the ring pointer pool is determined according to the pointer address range, the ring buffer is traversed from the tail pointer, if the buffer is hit, the access timestamp is updated and the host pointer is returned; otherwise, a new mapping entry is created in the ring buffer, if the ring buffer is not full, the new mapping entry is written to the head pointer position, the head pointer is moved, if the ring buffer is full, the mapping entry with the smallest access timestamp is deleted, the pointer is moved, and the new mapping entry is written to the head pointer position.

[0039] Further, in order to prevent the generation of wild pointers, the application binds the life cycle of the pointer mapping to the kernel object of the host system, and automatically cleans the associated pointer mapping when the kernel object is released, specifically:

[0040] When the mapping entry is established, the ID of the associated kernel object in the host system is recorded; when the system call related to the release of the kernel object is intercepted, the kernel object ID is obtained, and the valid mapping entries with the same kernel object ID in the ring pointer pool are deleted.

[0041] In addition, in order to improve the reliability of the conversion process, the application verifies the conversion result, specifically:

[0042] According to the first feature library, high-frequency field and pointer-intensive data structures therein are divided into different check groups; during the conversion process, a double buffer including a main buffer and a backup buffer is constructed for the conversion result, the field-level conversion result is saved in the main buffer, and the backup buffer adopts an independent conversion function to obtain a backup conversion result; only the cyclic redundancy check values of the high-frequency fields in the main buffer and the backup buffer are compared, and if the values are consistent, it is determined that the conversion is correct, and if the values are inconsistent, a default value is adopted and an error log is recorded.

[0043] Embodiments:

[0044] This embodiment takes OpenHarmony as a container system and Linux system as a host system as an example, adopts the operating system containerization kernel compatibility method based on hybrid binary translation provided by the application, solves the compatibility problem of OpenHarmony and standard Linux, and the specific process includes:

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

[0046] S1.1, field-level feature anchoring of incompatible data structures.

[0047] S1.1.1, feature extraction tool chain and process.

[0048] Static source code analysis: using the official Clang cross-compilation tool chain (version 14.0.0) of OpenHarmony, the kernel data structure header file (such as fs.h, stat.h, dirent.h) is analyzed by AST (abstract syntax tree), and basic features such as structure name, field name, field type, offset, alignment requirement are extracted. For example, when analyzing structohm_file, the AST is generated by the command clang-Xclang-ast-dump-fsyntax-onlyfs.h, and the field type of distributed_fd is int and the offset is 12 bytes by traversing the AST node;

[0049] Compilation verification: the code containing the target structure is compiled into the target file (.o), and the memory layout of the structure is viewed by the command objdump-s-j.data to verify the consistency of the offset parsed statically and the actual compilation result. For example, after compiling the structohm_file test code, the objdump output shows that the starting address of ohm_pos field is 0x04, which is completely matched with the 4-byte offset parsed statically, ensuring the accuracy of the features;

[0050] Dynamic access sampling: Run the target program (such as dfs_server) in the OpenHarmony native environment, collect the access frequency of the structure field through perfrecord-emem:load / store, and mark the high-frequency field (access ratio ≥ 50%) and the low-frequency field (access ratio < 10%). For example, sampling finds that the ohm_flags (access ratio 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, Field-level feature list of core incompatible structures.

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

[0053] Table 1 Field-level feature list

[0054] Incompatible structure Field name Field type OpenHarmony offset (bytes) Linux corresponding field Linux offset (bytes) Linux type Access frequency Field role structohm_file ohm_flags unsigned int 0 f_flags 16 unsigned int 90% File access permission flag ohm_pos __u32 4 f_pos 24 loff_t (64 bits) 85% Current file offset distributed_fd int 12 No - - 30% Distributed file identifier ohm_reserved unsigned char 16 No - - 5% Reserved field structohm_stat ohm_st_size __off_t (32 bits) 12 st_size 24 off_t (64 bits) 95% File size ohm_st_mode __mode_t 8 st_mode 16 mode_t 80% File type and permission ohm_st_ino __ino_t 4 st_ino 8 ino_t (64 bits) 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 unsigned short 6 d_reclen 10 unsigned short 85% Directory entry record length

[0055] S1.1.3, Uniqueness guarantee and storage of features.

[0056] Unique anchoring: For each incompatible structure, use the structure name and high-frequency field offset combination as the unique identifier, such as 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 Linux native structures;

[0057] Feature storage: Convert the field-level features to binary format and store them in the structure feature library ( / etc / ohm_struct_db.bin), which supports fast query by structure name and field name (query time < 100 ns). The format is as follows:

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

[0059] structstruct_feature{

[0060] charstruct_name

[64] ; / / Structure name (such as "structohm_file")

[0061] charfield_name

[64] ; / / Field name (such as "ohm_flags")

[0062] uint8_t field_type; / / field type (0=int, 1=uint32_t, 2=pointer, etc.)

[0063] uint32_t ohm_offset; / / offset in OpenHarmony (bytes)

[0064] uint32_t linux_offset; / / offset in Linux (bytes, 0xFFFFFFFF if none)

[0065] char linux_field

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

[0066] uint8_t access_freq; / / access frequency (0=low, 1=medium, 2=high)

[0067] };

[0068] S1.2, Association graph construction.

[0069] Through static call analysis and dynamic running tracking, it is clear which structures and fields each system call will access, and the field-level association graph is constructed to provide the basis for subsequent on-demand conversion and avoid full conversion.

[0070] Static call analysis: based on Clang AST tool chain, parse OpenHarmony program ELF file (such as / system / bin / ls), traverse system call related functions (such as __openat, __read), analyze the structure fields involved in function parameters and return values. For example, when analyzing the __openat function, it is found that the flags parameter will be written to the struct ohm_file.ohm_flags field, and the ohm_pos field will be read to initialize the file offset.

[0071] Dynamic running tracking: run the program in the OpenHarmony native environment, record the parameters and return values of system calls through strace-etrace=openat, read, getdents64, and combine gdb breakpoint debugging to track the access path of the field. For example, when tracking the read call, it is found that it will read the struct ohm_file.ohm_pos field to determine the starting position of reading and write the ohm_pos field to update the offset.

[0072] Graph integration: integrate static analysis and dynamic tracking results to construct the association graph of system calls and structure fields, each system call node is associated with its accessed structure, field list and access type (read / write), as shown in the following table:

[0073] Table 2 Association Map

[0074] System call Call number (Linux 5.15) Involved structure Access field list Access type Field access proportion openat 257 structohm_file ohm_flags (write), distributed_fd (write) Write 90% / 30% read 0 structohm_file ohm_pos (read / write), ohm_flags (read) Read / write 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) Read / write 95% / 90% / 85%

[0075] The constructed association map is respectively deployed to the user state translation service (ohm_translate_d) and the dynamic translation engine. The user state service is used for static preprocessing, and the dynamic translation engine is used for on-demand conversion. Both of them synchronize the map update (such as adding a structure field) in real time through shared memory to ensure consistency.

[0076] The field-level feature anchoring of incompatible structures is realized instead of the structure-level coarse-grained extraction in the prior art, which lays a foundation for subsequent on-demand conversion. The association map of system calls and structure fields clearly adapts the scope, so that the dynamic stage only needs to process high-frequency access fields, and the conversion data volume is reduced by 40%.

[0077] S2, static preprocessing based on structure features.

[0078] The existing insertion uses the same logic for all system call sites. According to the access frequency of the fields in the association map, the embodiment designs high-frequency path insertion and low-frequency path insertion to reduce redundant checks.

[0079] S2.1, insertion target positioning.

[0080] The ELF file of the OpenHarmony program is disassembled through a disassembly tool (such as objdump-d), the address of the system call instruction (x86's syscall, ARM's svc) is located, and the high-frequency call site (such as read, write, call ratio ≥ 30%) and the low-frequency call site (such as getcwd, stat, call ratio < 10%) are marked in combination with the association map.

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

[0082] Insertion logic: for high-frequency call sites (such as read), directly insert field-level conversion cache query and fast jump code, skip redundant parameter parsing and full translation. For example, for the scenario of read calling accessing struct ohm_file.ohm_pos (high-frequency field), the insertion code presets the offset (4 bytes) and conversion rule (__u32→loff_t) of ohm_pos, and directly executes the conversion when the cache hits without dynamic analysis;

[0083] Insertion code example (x86 architecture, based on OpenHarmony read call site):

[0084] ; Original read call instruction of OpenHarmony program (address 0x4005A0)

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

[0086] ; 0x4005A7: syscall; trigger system call

[0087] ; High-frequency path instrumentation code (for struct ohm_file.ohm_pos field)

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

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

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

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

[0092] 0x4005BA: test %eax, %eax; check cache hit or miss (%eax = 1 hit, 0 miss)

[0093] 0x4005BC: jnz 0x400650; hit: jump to fast conversion logic (handle ohm_pos directly)

[0094] 0x4005C2: jmp 0x400700; miss: jump to low-frequency path (dynamic translation)

[0095] Cache design: build a two-level cache for high-frequency fields with "call number + field offset" as the key, and the converted Linux offset and conversion function address as the value. The cache hit rate initially reaches 60% and stabilizes at over 90% after running.

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

[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 occupying high-frequency path resources.

[0098] Core difference: low-frequency path does not preset conversion rules and needs to dynamically query the structure feature library, but only analyzes instructions related to data structures, and directly executes ordinary instructions in the original form, reducing the translation range by 70%.

[0099] S2.4, structure feature-based instruction-level pre-translation.

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

[0101] S2.4.1, pre-translation range and logic.

[0102] Pre-translation range: only instructions related to structure field access in the correlation graph are pre-translated, such as moveax, [rbp-0x10] (reading struct ohm_stat.ohm_st_size, offset 12 bytes), and ordinary instructions (such as addeax, ebx) are not pre-translated and are directly executed in the original form;

[0103] Intermediate operation code design: define structure-specific intermediate operation codes, such as LOAD_FIELD ohm_st_size, 0xC, 0x18 (load ohm_st_size field, OH offset 0xC=12 bytes, Linux offset 0x18=24 bytes), and STORE_FIELD ohm_pos, 0x4, 0x18 (store ohm_pos field);

[0104] Pre-translation process:

[0105] Disassemble system call-related instruction sequences and identify field access instructions.

[0106] Query the structure feature library to obtain the OH offset, Linux offset, and type of the field.

[0107] Generate intermediate operation codes and store them in a shared memory named pre-translation cache.

[0108] In the dynamic phase, read the intermediate operation codes and directly generate Linux native instructions (such as moveax, [rbp-0x10] → movrax, [rbp-0x18]).

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

[0110] Cache structure: use instruction address and structure name as keys, intermediate operation code as value, and set cache item validity period to 1 hour to avoid outdated structure features causing errors.

[0111] Preheat mechanism: when the program starts, the pre-translation results of frequently called (read, write, openat) instruction sequences in the associated graph are preloaded, and the pre-translation cache hit rate in the dynamic stage after preheating is more than 85%.

[0112] Layered instrumentation distinguishes processing logic based on field access frequency, and the execution steps of high-frequency paths are reduced by 60% after cache hit; instruction-level pre-translation transfers the disassembly and analysis overhead of the dynamic stage to the static stage, and the dynamic translation time is reduced by 70%.

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

[0114] Traditional dynamic translation processes all instructions, and the embodiment translates only instructions involving incompatible structure fields through instruction type filtering and structure field association judgment, and other instructions are executed natively.

[0115] S3.1, instruction type filtering.

[0116] Through the instruction decoder of the dynamic translation engine, the instructions are divided into three categories, and only the third category is processed:

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

[0118] Non-structure memory access instructions: such as accessing string constants and global variables (which do not involve incompatible structures), which are directly executed natively;

[0119] Structure field access instructions: such as instructions accessing structohm_file.ohm_pos and structohm_dirent.ohm_next, which need to be translated and converted.

[0120] S3.2, structure field association judgment.

[0121] For memory access instructions, whether they involve incompatible structure fields is determined by address range matching and structure feature verification:

[0122] Address range matching: the incompatible structure memory allocation of the OpenHarmony program is in a dedicated address segment (such as 0x70000000-0x7FFFF000), which is fixed through the MAP_FIXED flag when mmap, and if the target address of the memory access instruction is not in this range, it is directly executed natively;

[0123] Struct feature verification: If the address is in the exclusive range, query the struct feature library in step 1 to verify whether the address matches the field offset of a certain structure (such as address 0x70000004 matching the offset of 4 bytes of struct ohm_file.ohm_pos). If it does not match, it is executed natively.

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

[0125] For basic structures (such as struct ohm_stat, struct ohm_file), the "field-level lazy loading" strategy is adopted, which triggers the conversion of the field only when the program accesses the field, rather than full conversion of the entire structure.

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

[0127] Instruction interception: Intercept the instruction that accesses ohm_st_size (such as moveax, [rbp-0x0C], rbp-0x0C is the stack address of ohm_st_size);

[0128] Field identification: Through address calculation (rbp-0x0C) and structure feature library matching, it is determined that the accessed field is struct ohm_stat.ohm_st_size;

[0129] On-demand conversion:

[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 32-bit __off_t, and write it to the ohm_st_size field address of the program;

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

[0132] Instruction release: After the conversion is completed, modify the target address of the instruction (such as rbp-0x0C→rbp-0x18, corresponding to Linux offset 24 bytes), and execute the modified instruction natively.

[0133] Field-level conversion example code (based on OpenHarmony stat call):

[0134] / / Field-level lazy loading conversion function in 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_t ohm_st_size = *(__off_t *) ohm_addr;

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

[0155] }

[0156] }

[0157] S3.4, Dynamic hit and update of pre-translation cache.

[0158] The dynamic phase first queries the pre-translation cache. If it hits, it directly uses the intermediate operation code to generate native instructions. If it misses, it triggers dynamic analysis and pre-translation cache update:

[0159] Cache hit: read intermediate operation code (e.g. LOAD_FIELD ohm_st_size, 0xC, 0x18), generate Linux native instruction (mov rax, [rbp-0x18]), execution time <10ns;

[0160] Cache miss: dynamic analysis of the instruction, generate intermediate operation code, perform conversion, and write the intermediate operation code to the pre-translation cache for subsequent calls. The miss handling time is <100ns, much lower than the 1μs of full instruction translation.

[0161] Dynamic translation range clipping allows 90% of normal instructions to be executed natively, reducing the amount of translated instructions by 90%. Field-level lazy loading avoids full structure conversion, reducing the amount of converted data by 55%, and the dynamic conversion time of high-frequency fields is reduced to 30% of the original scheme.

[0162] S4, Ring pointer pool and life cycle management of pointer-intensive structures.

[0163] For pointer-intensive structures such as struct ohm_dirent linked list and struct ohm_dentry hash tree, the traditional scheme relies on hash table for pointer redirection, which has low query efficiency and no life cycle management. Design ring pointer pool to optimize query efficiency, life cycle binding to prevent wild pointers, and ensure efficient and safe conversion of complex structures.

[0164] S4.1, Design and implementation of ring pointer pool.

[0165] Based on the access mode of pointer-intensive structure (such as sequential access of linked list), the ring buffer is designed to store OpenHarmony pointer-Linux pointer mapping pairs, which greatly improves the query efficiency.

[0166] S4.1.1, Structure design of ring pointer pool.

[0167] Pool division: according to the address range of OpenHarmony pointer (such as 1MB per pool), multiple ring pointer pools are created, each pool corresponds to an address segment, reducing the query range of a single pool;

[0168] Ring buffer structure: each pool contains a fixed-size ring buffer (such as 1024 entries), each entry stores OH pointer, Linux pointer, access timestamp, and associated kernel object ID, structure as follows:

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

[0170] struct ptr_pool_entry {

[0171] uint64_t ohm_ptr; / / OpenHarmony pointer (such as struct ohm_dirent *)

[0172] uint64_t linux_ptr; / / Linux pointer (such as struct dirent *)

[0173] uint64_t access_ts; / / Last access timestamp (ns)

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

[0175] uint8_t valid; / / Entry validity (1 = valid, 0 = invalid)

[0176] };

[0177] / / Ring pointer pool structure

[0178] struct ring_ptr_pool {

[0179] uint64_t addr_start; / / Start address of OH pointer covered by this pool

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

[0181] struct ptr_pool_entry *buf; / / Ring 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 insertion process of pointer mapping.

[0188] Query process:

[0189] Receive the OpenHarmony pointer (e.g., 0x70001238) and locate the corresponding ring pool according to the address range; start traversing the ring buffer from the tail pointer (tail), match ohm_ptr and valid=1, due to the sequential access characteristics of the linked list, the hit rate of the most recently inserted entry (close to the head pointer) reaches 80%, and the average query times are only 5 (hash table average 10); update access_ts after hitting and return linux_ptr; if not hit, trigger new mapping creation.

[0190] Insertion process:

[0191] Create a new ptr_pool_entry and fill in ohm_ptr, linux_ptr, and 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; if the buffer is full, discard the least accessed entry (access_ts is the smallest, close to the tail pointer), move the tail pointer, and then write the new entry.

[0192] S4.2, Binding of pointer life cycle and Linux kernel object.

[0193] To prevent wild pointers (e.g., Linux directory entries have been released, but OH pointers are still accessed), the life cycle of pointer mapping is bound to the Linux kernel object (e.g., file descriptor, process ID), and the associated pointer mapping is automatically cleaned up when the kernel object is released.

[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 copying 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 32-bit to 64-bit type conversions (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 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-translated intermediate opcode sequence. The static translation service inserts a first converter at the system call of high-frequency fields and a second converter at the system call of low-frequency fields. Based on the association graph, it pre-generates an intermediate opcode sequence containing opcode, field name, container offset and host offset for high-frequency fields and stores it in the second cache. When the container application is running, 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, the dynamic translation engine is triggered to complete the translation based on the association graph. The second converter triggers the dynamic translation engine to complete the conversion based on the associated graph.

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 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 offset of the host field, converted, and written to the address corresponding to the offset of the target field. When the instructions are write, the data is read from the address corresponding to the offset of the target field, converted, and written to the address corresponding to the offset of the host field, 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 ring 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