A container-based cross-operating system computing platform and method of operation
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- NANKAI UNIV
- Filing Date
- 2026-02-13
- Publication Date
- 2026-06-05
Smart Images
Figure CN122152433A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of computer operating system and virtualization technology, specifically relating to a cross-operating system computing environment system and construction method based on container technology. It focuses on achieving transparent and compatible operation and cross-environment streaming collaborative computing of binary programs of heterogeneous Linux distributions through the fusion scheduling of host shell and container runtime on domestic operating systems such as Kylin OS. Background Technology
[0002] With the rapid development of the domestic software and hardware ecosystem, domestic Linux distributions, represented by Kylin OS, have been applied in many key areas. However, in the actual promotion process, the compatibility and migration adaptation of application software have become the core bottleneck restricting the development of the ecosystem. A large number of existing legacy software, research tools, or commercial applications are compiled and built based on specific versions of Linux distributions (such as Ubuntu 18.04, CentOS 8, etc.), and often lack source code due to their age. Due to differences in Linux kernel versions and incompatibility of basic runtime libraries (such as glibc), these binary programs cannot run directly on domestic operating systems.
[0003] Currently, the main technical approaches to solving the aforementioned cross-operating system compatibility issues fall into three categories: The first category is full virtualization technology based on virtual machines (such as VMware and VirtualBox). This method provides a compatible environment by running a complete guest operating system on the host machine. However, virtual machines have huge resource overhead (high CPU and memory usage), slow startup speed, and strict file system isolation between the virtual machine and the host machine, leading to cumbersome data exchange and making it impossible to implement lightweight command-line tool calls. The second category is recompiling and porting based on source code. This method attempts to recompile the software source code on the target operating system. However, this requires complete source code and a significant amount of manpower to resolve dependency library conflicts, and it completely fails for legacy binary programs without source code. The third category is lightweight virtualization technology based on containers (such as Docker). Although container technology is lighter than virtual machines, it suffers from a serious "contextual fragmentation" problem in command-line interaction. For example, if a user wants to run an Ubuntu version of the grep command on a Kylin system, they must write a lengthy `docker run` command, manually mount volumes to map file paths, and handle complex permission issues.
[0004] More importantly, existing container technologies cannot directly support cross-environment shell pipe operations. For example, a user might want to pass the output of a command running in an Ubuntu container directly to a command running in a CentOS container as input using the pipe operator | (e.g., cmd_in_ubuntu | cmd_in_centos). With current technology, this requires complex multi-container network configurations or intermediate file transfers, which is difficult for ordinary users to perform. This prevents containerized tools from being integrated into the shell's streaming computing workflow as easily as local commands.
[0005] In summary, the industry currently lacks a system that deeply integrates the isolation and compatibility capabilities of containers with the convenient interactive capabilities of shells, making it impossible to achieve transparent computing and streaming collaboration across operating systems without modifying the binary program or requiring user awareness. Therefore, there is an urgent need to develop a cross-operating system computing environment based on container technology. Summary of the Invention
[0006] The purpose of this invention is to address the compatibility issues faced by domestic operating systems such as Kylin OS during ecosystem migration, where legacy binary programs cannot be directly run due to missing source code or dependence on specific older Linux environments. It also aims to resolve the pain points of existing container technologies in command-line interaction, such as context fragmentation and the inability to directly perform cross-environment streaming collaboration. This invention presents a container-based cross-operating system computing platform and its implementation method. The system constructs a virtual shell intermediate layer to dynamically map user commands to heterogeneous container instances, and utilizes host machine I / O bridging technology to achieve cross-environment streaming collaborative computing. This facilitates the compatible operation of heterogeneous applications on domestic platforms without modifying the binary programs.
[0007] Technical solution of the present invention
[0008] A container-based cross-operating system computing platform, the platform comprising a program computing device and a heterogeneous container instance pool; the heterogeneous container instance pool comprising a plurality of container instances; the program computing device comprising at least: a dual-mode interaction subsystem, a heterogeneous command fingerprint storage module, an instruction fusion scheduling module, an environment context mapping module, a host I / O streaming bridge module, and a containerized execution engine interface module;
[0009] in,
[0010] The dual-mode interactive subsystem provides both a graphical user interface and a GShell character command-line interface, serving as a unified entry point for receiving complex user command inputs and maintaining the context state of the Shell session.
[0011] The heterogeneous command fingerprint storage module, as middleware connecting the host environment and the container environment, is used to store the fingerprint mapping relationship between external heterogeneous commands and container images.
[0012] The instruction fusion scheduling module is used to parse the instruction string input by the user, separate the command verb and the flow control character, and use the command verb as an index to retrieve the heterogeneous command fingerprint storage module, thereby dynamically determining whether the execution path of the instruction is local execution on the host machine or containerized compatible execution.
[0013] The environment context mapping module is used to capture the current user identity information and working directory status of the host machine when containerization is triggered, and to calculate container startup parameters, including user permission mapping UID / GID and directory mount path.
[0014] The host I / O streaming bridge module is used to build a data transmission channel between the host shell process and the container isolation process. By intercepting and mapping standard input / output and pipe operators, it enables transparent data transmission across environments.
[0015] The containerized execution engine interface module is used to interface with the underlying container runtime, instantiate a specific Linux distribution container according to the startup parameters, and is responsible for the transient creation and destruction of the container lifecycle.
[0016] Furthermore, the heterogeneous command fingerprint storage module is specifically configured as follows: constructing a heterogeneous mapping database with a key-value pair structure; the key of the heterogeneous mapping database is the calling verb string of the external heterogeneous command; the value of the heterogeneous mapping database is a configuration set containing the target container image name, the absolute path of the executable program inside the container, the version tag, and the dependent library environment.
[0017] Furthermore, the instruction fusion scheduling module is specifically configured as follows: receiving command line string data input by the user; parsing the command line string data into a string array containing command verbs and parameter lists using a delimiter; using the first word in the string array as an index key to perform a matching search on the heterogeneous command fingerprint storage module; if the search is successful, the instruction is determined to be a heterogeneous task, the corresponding image configuration information is extracted and sent to the environment context mapping module; if the search is unsuccessful, the instruction is determined to be a local task, and the system call interface of the host machine is directly called to execute the instruction in the current process context.
[0018] Furthermore, the environment context mapping module is specifically configured as follows: call the host system interface to obtain the user identifier and group identifier of the current terminal user; obtain the absolute path of the working directory of the current Shell session; construct a container startup parameter containing authentication parameters and file path mapping parameters; write the user identifier and group identifier into the container startup parameter as the running identity, and write the absolute path of the working directory into the container startup parameter through volume mounting, thereby ensuring that the program in the container has the same permissions to read and write mounted files as the host user.
[0019] Furthermore, the host I / O streaming bridging module is specifically configured as follows: It allocates and creates standard pipe file objects in the host memory; utilizes a file descriptor copying mechanism to obtain the integer handles of the standard input, standard output, and standard error file descriptors of the host shell process, and redirects them to the input / output stream handles corresponding to the container instance; when the instruction contains a pipe operator, the module directly bridges the output stream file descriptor of the preceding execution unit to the input stream file descriptor of the following execution unit by manipulating the file descriptor table, thereby achieving memory-level data flow across the boundary between the host and the container.
[0020] Furthermore, the containerized execution engine interface module is specifically configured as follows: it adopts a transient container scheduling mode for resource management; it instantiates a container object immediately upon receiving a startup signal and injects an automatic cleanup flag parameter into the container startup parameters; it monitors the exit status code integer returned by the target program in the container in real time, and once the target program finishes execution, it immediately triggers the container destruction process according to the exit status code, automatically clears the container instance and its runtime temporary file layer, and releases host machine resources.
[0021] This invention also provides a method for running a graphical command interpreter on a container-based cross-operating system computing platform, the method comprising the following specific steps:
[0022] First, the graphical user interface of the dual-mode interactive subsystem enters a background listening state to monitor user operation signals of the host desktop environment in real time.
[0023] 2. Capture double-click signals or shortcut call signals from users targeting specific heterogeneous application icons;
[0024] Third, using the metadata associated with the heterogeneous application icon as the index key, retrieve the heterogeneous command fingerprint storage module;
[0025] 4. Obtain the target container image name and default container startup parameters from the heterogeneous command fingerprint storage module.
[0026] 5. Trigger the environment context mapping module to capture the display interface parameters and audio device parameters of the current graphical desktop session;
[0027] 6. Build container startup parameters that include display interface mapping parameters and user home directory mount path;
[0028] 7. The target container is started by calling the underlying container runtime according to the container startup parameters through the containerized execution engine interface module.
[0029] 8. Redirect the graphical interface output data stream of the target container to the host machine's window manager for rendering and display until the user closes the application window;
[0030] 9. After the user closes the application window, the container destruction and temporary resource reclamation operations will be automatically executed, ending the execution process of this graphical application.
[0031] This invention also provides a method for running the GShell character command interpreter on a container-based cross-operating system computing platform, the method comprising the following specific steps:
[0032] First, the GShell character command-line interface of the dual-mode interactive subsystem displays a command prompt on the host terminal and blocks and waits for input;
[0033] Second, receive command line string data entered by the user in the terminal;
[0034] 3. The command line string data is segmented and parsed into command verb strings and parameter list arrays using the instruction fusion scheduling module;
[0035] 4. Match and retrieve the command verb string with the heterogeneous command key in the heterogeneous command fingerprint storage module;
[0036] 5. If the search is successful, the environment context mapping module is triggered to synchronize the absolute path of the current terminal's working directory and the set of environment variables.
[0037] 6. Check if there is a pipe operator in the scan command. If so, use the host I / O streaming bridge module to establish a file descriptor mapping channel in the host memory.
[0038] 7. Perform cross-process interfacing between the standard output stream handle of the preceding execution unit and the standard input stream handle of the following container instance;
[0039] 8. The containerized execution engine interface module starts the container and executes the target program according to the container startup parameters;
[0040] 9. Transmit the standard output data stream of the execution result to the host terminal interface in real time and display it back;
[0041] Step 10: After the target program finishes execution, the container destruction and temporary resource reclamation operations will be automatically performed, ending the current command execution process.
[0042] The specific content involved in this invention and the meaning of the terms used are as follows:
[0043] (1) Dual-mode interactive subsystem: refers to the unified interactive entry point running in the host machine's user space, which includes a graphical user interface and a GShell character command-line interface. In terms of functionality, this system simulates the operating habits of the native operating system, such as double-clicking the icon to start or entering the Shell command line. However, in terms of execution logic, it does not rely on the host machine's underlying toolchain. Instead, it acts as the front end of the "meta-scheduler," responsible for receiving user instructions and maintaining the session state, thereby hiding the isolation characteristics of the underlying heterogeneous containers under the unified interactive interface.
[0044] (2) Heterogeneous command fingerprint storage: refers to a set of key-value pairs, i.e., key-value data sets, pre-configured by the system to describe the correspondence between application layer commands and underlying runtime environments. Each fingerprint rule defines the specific command verb (e.g., make, gcc) or application icon that should be executed on which version of the Linux distribution container image (e.g., Ubuntu 18.04) and in what specific path, thus realizing automatic routing and precise matching of "instructions" to "heterogeneous environments".
[0045] (3) Environment context mapping: refers to a technical means to eliminate the differences in permissions and file views between the host machine and the container. This invention automatically captures the user identifier, group identifier, absolute path of the working directory and environment variables of the current session of the host machine, and synchronizes them to the container through volume mounting and parameter injection when the container is started, so that the program in the container can directly read and write files in the current directory as the host machine user, thus realizing the logical unification of the file system and permission view.
[0046] (4) Host I / O streaming bridging: refers to a data transmission technology that uses host kernel resources to connect different isolated environments. This invention utilizes standard pipe and file descriptor copying technology on the host side to take over the data streams of standard input, standard output and standard error, and connects the input and output of heterogeneous containers with the host terminal or preceding process, thereby realizing streaming collaborative computing across container isolation boundaries.
[0047] Advantages and positive effects of the present invention:
[0048] This invention helps solve the problems of heterogeneous application compatibility and interactive experience in the migration of domestic operating system ecosystems, and is conducive to the implementation of cross-platform computing.
[0049] To ensure consistent user experience and execution across heterogeneous applications, this invention establishes a unified dual-mode entry point combining graphical and command-line interfaces. Whether through double-clicking an icon in the graphical interface or inputting commands in the GShell character terminal, users can transparently invoke heterogeneous programs without needing to master complex container instructions. This mechanism helps shield the differences between underlying containers, allowing users to invoke heterogeneous programs via clicks or commands. Furthermore, the environment context mapping module automatically synchronizes the host machine user's UID / GID and working directory, ensuring consistency between heterogeneous applications and native host applications in file read / write and permission control. This helps reduce permission conflicts that may occur in traditional container solutions.
[0050] For streaming collaboration and hybrid computing of complex tasks, this invention achieves data channel connections between heterogeneous containers while maintaining container isolation through a host I / O streaming bridging mechanism. Programs running on different operating system versions can be connected through standard pipe operators, and data flows directly in memory without needing to be stored on disk, thus making cross-operating system hybrid computing workflows feasible.
[0051] For the migration and adaptation of existing software ecosystems, this invention provides a compatibility solution requiring zero code modification. For binary programs lacking source code or dependent on a specific older version of the glibc environment, this invention utilizes a heterogeneous command fingerprint storage module to establish a mapping relationship and encapsulates the older environment for execution through a heterogeneous container. This approach helps lower the technical threshold for software migration in domestic IT innovation projects, eliminating the need for reverse engineering or source code porting, and facilitating the adaptation of domestic operating systems to existing software ecosystems.
[0052] Regarding resource management and security during system operation, this invention employs a transient management mechanism for the container lifecycle. The system instantiates containers only during graphical startup or command-line execution and automatically destroys them immediately after execution, cleaning up all temporary read / write layer data. This strategy helps reduce system resource consumption and contributes to maintaining the stability of the host environment. Attached Figure Description
[0053] Figure 1 This is a schematic diagram of the overall operation process of the container-based cross-operating system computing platform of the present invention.
[0054] Figure 2 This is a schematic diagram of the system architecture of the container-based cross-operating system computing platform of the present invention. The dual-mode interaction subsystem 200 includes a graphical user interface (corresponding to...). Figure 2 The graphical command startup module 210 in the middle) and the GShell character command line interface (corresponding to Figure 2 The GShell character command interaction module 220 in the database.
[0055] Figure 3 This is a schematic diagram of the source code of the heterogeneous binary program matrix_tool in Embodiment 1 of the present invention and its dependency error detection on the host machine.
[0056] Figure 4 This is a schematic diagram of the heterogeneous mapping database in Embodiment 1 of the present invention.
[0057] Figure 5 This is a schematic diagram of the logical mapping of user instructions into containerized execution instructions in Embodiment 1 of the present invention. Detailed Implementation
[0058] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.
[0059] This invention provides a container-based cross-operating system computing platform and its operating method. For example... Figure 2 As shown, the container-based cross-operating system computing platform provided by this invention includes the following:
[0060] The program computing device 100 and the heterogeneous environment resource pool 600 are typically deployed in the same physical computer or virtual machine and connected through the host operating system's local Socket communication interface or system call interface.
[0061] The program computing device 100 (i.e., the host computing environment) includes: a dual-mode interaction subsystem 200, a heterogeneous command fingerprint storage module 320, an instruction fusion scheduling module 310, an environment context mapping module 410, a host I / O streaming bridge module 420, and a containerized execution engine interface module 510. Figure 2 The numbers 200, 310, 320, 410, 420, and 510 correspond to the six modules mentioned above.
[0062] The heterogeneous environment resource pool 600 (i.e., the underlying container runtime) includes: container images of various Linux distributions (such as Ubuntu, CentOS, etc.), container runtime daemons (such as Docker Daemon or Podman), and temporary container instances managed by them. Figure 2 The winning designation 600 corresponds to the heterogeneous environment resource pool area.
[0063] Furthermore, the heterogeneous command fingerprint storage module is specifically configured as follows: constructing a heterogeneous mapping database with a key-value pair structure; the key of the heterogeneous mapping database is the calling verb string of the external heterogeneous command; the value of the heterogeneous mapping database is a configuration set containing the target container image name, the absolute path of the executable program inside the container, the version tag, and the dependent library environment.
[0064] For example:
[0065] A heterogeneous mapping database with key-value pair structure is constructed in the heterogeneous command fingerprint storage module 320.
[0066] For the two heterogeneous commands, ubuntu_cat and centos_grep, the mapping relationships are configured as follows:
[0067] ubuntu_cat command configuration:
[0068] • Key: Calls the verb string "ubuntu_cat"
[0069] • Value: The configuration set contains
[0070] Target container image name: "ubuntu:22.04"
[0071] The absolute path to the executable program within the container: " / bin / cat"
[0072] Version tag: "22.04"
[0073] o Dependency library environment: ["libc.so.6"]
[0074] centos_grep command configuration:
[0075] • Key: Invoke the verb string "centos_grep"
[0076] • Value: The configuration set contains
[0077] Target container image name: "centos:8"
[0078] The absolute path to the executable program within the container: " / bin / grep"
[0079] Version tag: "8"
[0080] o Dependency library environment: ["libc.so.6", "libpcre.so.1"]
[0081] The database uses a hash table structure stored in memory and supports key-value retrieval with constant time complexity.
[0082] Furthermore, the instruction fusion scheduling module is specifically configured as follows: receiving command line string data input by the user; parsing the command line string data into a string array containing command verbs and parameter lists using a delimiter; using the first word in the string array as an index key to perform a matching search on the heterogeneous command fingerprint storage module; if the search is successful, the instruction is determined to be a heterogeneous task, the corresponding image configuration information is extracted and sent to the environment context mapping module; if the search is unsuccessful, the instruction is determined to be a local task, and the system call interface of the host machine is directly called to execute the instruction in the current process context.
[0083] For example:
[0084] The user enters the following command in the Kylin host terminal: ubuntu_cat data.txt | centos_grep "error" | wc -l.
[0085] The instruction fusion scheduling module performs the following steps:
[0086] Step 1: Receive the command line string data input by the user, such as the command above;
[0087] ubuntu_cat data.txt | centos_grep "error" | wc -l
[0088] Step 2: Use delimiters to parse the command line string data into a string array containing command verbs and parameter lists;
[0089] The instruction fusion scheduling module 310 receives the command line string data and identifies the pipe operator "|". Using the pipe operator as a separator, it parses the command line string into a string array containing three sub-commands:
[0090] Subcommand 1: "ubuntu_cat data.txt"
[0091] Subcommand 2: "centos_grep "error""
[0092] Subcommand 3: "wc -l"
[0093] For each subcommand, it is further parsed into a command verb and a list of parameters:
[0094] Subcommand 1: Command verb "ubuntu_cat", parameter list ["data.txt"]
[0095] Subcommand 2: Command verb "centos_grep", parameter list ["error"]
[0096] Subcommand 3: Command verb "wc", parameter list ["-l"]
[0097] Step 3: Using the first word in the string array as the index key, perform a matching search on the heterogeneous command fingerprint storage module;
[0098] Step 3.1: If the search is successful, the instruction is determined to be a heterogeneous task. The corresponding image configuration information is extracted and sent to the environment context mapping module.
[0099] • Search using "ubuntu_cat" as the index key: If the search is successful, it is determined to be a heterogeneous task. The corresponding image configuration information (ubuntu:22.04, / bin / cat) is extracted and sent to the environment context mapping module 410.
[0100] • Search using "centos_grep" as the index key: If the search is successful, it is determined to be a heterogeneous task, and the corresponding image configuration information (centos:8, / bin / grep) is extracted and sent to the environment context mapping module 410;
[0101] Step 3.2: If the search fails, the instruction is determined to be a local task, and the host machine's system call interface is directly invoked to execute the instruction in the current process context.
[0102] • Search using "wc" as the index key: If the search fails, it is determined to be a local task and marked as to be executed in the current process context of the host machine.
[0103] Furthermore, the environment context mapping module is specifically configured as follows: call the host system interface to obtain the user identifier and group identifier of the current terminal user; obtain the absolute path of the working directory of the current Shell session; construct a container startup parameter containing authentication parameters and file path mapping parameters; write the user identifier and group identifier into the container startup parameter as the running identity, and write the absolute path of the working directory into the container startup parameter through volume mounting, thereby ensuring that the program in the container has the same permissions to read and write mounted files as the host user.
[0104] For example:
[0105] For the two heterogeneous tasks, the environment context mapping module 410 performs the following operations:
[0106] (4-1) Call the host system interface to obtain the current terminal user's user identifier UID is 1000 and group identifier GID is 1000;
[0107] (4-2) Get the absolute path of the current shell session's working directory " / home / user / test";
[0108] (4-3) For the ubuntu_cat command, construct container startup parameters that include authentication parameters and file path mapping parameters:
[0109] • Identity parameters: Write UID 1000 and GID 1000 into the container startup parameters as the running identity (-u 1000:1000)
[0110] • Mount parameters: Write the absolute path of the working directory into the container startup parameters via volume mount (-v / home / user / test: / home / user / test).
[0111] • Working directory: Set the working directory inside the container to / home / user / test (-w / home / user / test)
[0112] • Automatic cleanup: Inject the automatic cleanup flag (--rm)
[0113] (4-4) Perform the same context mapping operation on the centos_grep command to build its container startup parameters.
[0114] The above mapping ensures that programs inside the container can read and write files in the mount directory as the host user, with permissions consistent with those of the host user.
[0115] Furthermore, the host I / O streaming bridging module is specifically configured as follows: It allocates and creates standard pipe file objects in the host memory; utilizes a file descriptor copying mechanism to obtain the integer handles of the standard input, standard output, and standard error file descriptors of the host shell process, and redirects them to the input / output stream handles corresponding to the container instance; when the instruction contains a pipe operator, the module directly bridges the output stream file descriptor of the preceding execution unit to the input stream file descriptor of the following execution unit by manipulating the file descriptor table, thereby achieving memory-level data flow across the boundary between the host and the container.
[0116] For example:
[0117] The host I / O streaming bridge module 420 detected a pipe operator in the instruction and performed the following operation:
[0118] (5-1) Allocate and create two standard pipe file objects, pipe1 and pipe2, in the host machine's memory;
[0119] (5-2) Establish a data stream connection using the file descriptor copying mechanism (dup2):
[0120] Connect the standard input (file descriptor 0) of the host shell process to the standard input of the first container (ubuntu_cat);
[0121] Connect the standard output of the first container (ubuntu_cat) to the standard input of the second container (centos_grep) via pipe1;
[0122] • Connect the standard output of the second container (centos_grep) to the standard input of the local command (wc) via pipe2;
[0123] Connect the standard output of the local command (wc) to the standard output (file descriptor 1) of the host terminal.
[0124] By manipulating the file descriptor table, the output stream file descriptor of the preceding execution unit is directly bridged to the input stream file descriptor of the following execution unit, enabling memory-level data transfer across the boundary between the host machine and the container, without requiring the data to be stored on the ground.
[0125] Furthermore, the containerized execution engine interface module is specifically configured as follows: it adopts a transient container scheduling mode for resource management; it instantiates a container object immediately upon receiving a startup signal and injects an automatic cleanup flag parameter into the container startup parameters; it monitors the exit status code integer returned by the target program in the container in real time, and once the target program finishes execution, it immediately triggers the container destruction process according to the exit status code, automatically clears the container instance and its runtime temporary file layer, and releases host machine resources.
[0126] For example:
[0127] The containerized execution engine interface module 510 adopts a transient container scheduling mode to process two heterogeneous tasks sequentially:
[0128] (6-1) Upon receiving the start signal of the ubuntu_cat task, and based on the container start parameters generated by the environment context mapping module 410, instantiate the first container object immediately and generate Docker execution instructions:
[0129] docker run --rm -u 1000:1000 -v / home / user / test: / home / user / test -w / home / user / test ubuntu:22.04 / bin / cat data.txt
[0130] Inject the automatic cleanup flag parameter (--rm) into the container startup parameters. After the container starts, execute / bin / catdata.txt, read the file contents, and output them through pipe1;
[0131] (6-2) Receive the start signal from the centos_grep task, and instantiate the second container object immediately according to the corresponding container start parameters, generating Docker execution instructions:
[0132] docker run --rm -u 1000:1000 -v / home / user / test: / home / user / test -w / home / user / test centos:8 / bin / grep error
[0133] The container receives input data from pipe1, performs grep filtering, and outputs the results through pipe2.
[0134] (6-3) The local wc command is executed directly on the host machine, receives input from pipe2, counts the number of lines and outputs it to the terminal.
[0135] The containerized execution engine interface module 510 monitors the exit status code integers returned by the target programs within the two containers in real time.
[0136] (7-1) When the ubuntu_cat container finishes execution, it returns an exit status code of 0. The module immediately triggers the container destruction process based on the exit status code, automatically clearing the container instance and its temporary file layer generated during runtime, and releasing host machine resources.
[0137] (7-2) Once the centos_grep container finishes execution, it returns an exit status code of 0, which also triggers the automatic destruction process;
[0138] (7-3) The entire command execution process ends and system resources are completely reclaimed.
[0139] Application Example 1: Core Module Functionality Verification and Cross-Container Flow Pipeline Collaborative Computing
[0140] This embodiment demonstrates the collaborative working mechanism of the heterogeneous command fingerprint storage module, instruction fusion scheduling module, environment context mapping module, host I / O streaming bridge module, and containerized execution engine interface module through a cross-container streaming data processing scenario.
[0141] I. Background Information
[0142] In practical applications, users often need to chain multiple command-line tools from different Linux distributions using pipes to complete complex data processing tasks. For example, using the `cat` command in Ubuntu to read files, the `grep` command in CentOS to filter data, and finally the `wc` command on the host machine to analyze the results. Traditional container technologies cannot support this cross-container pipelining operation; users must export data to intermediate files or configure complex container networks. This embodiment describes how to perform cross-container boundary streaming data transmission using the core module of this invention.
[0143] II. System Configuration
[0144] The computing device is a personal computer running the Kylin V10 operating system; the heterogeneous environment resource pool is a locally installed Docker engine with two pre-downloaded container images: ubuntu:22.04 and centos:8.
[0145] III. Pre-configured
[0146] (1) Construction of heterogeneous mapping database
[0147] A heterogeneous mapping database with key-value pairs is constructed in the heterogeneous command fingerprint storage module 320. The mapping relationships for the two heterogeneous commands, ubuntu_cat and centos_grep, are configured as follows:
[0148] ubuntu_cat command configuration:
[0149] • Key: Calls the verb string "ubuntu_cat"
[0150] • Value: The configuration set contains
[0151] Target container image name: "ubuntu:22.04"
[0152] The absolute path to the executable program within the container: " / bin / cat"
[0153] Version tag: "22.04"
[0154] o Dependency library environment: ["libc.so.6"]
[0155] centos_grep command configuration:
[0156] • Key: Invoke the verb string "centos_grep"
[0157] • Value: The configuration set contains
[0158] Target container image name: "centos:8"
[0159] The absolute path to the executable program within the container: " / bin / grep"
[0160] Version tag: "8"
[0161] o Dependency library environment: ["libc.so.6", "libpcre.so.1"]
[0162] The database uses a hash table structure stored in memory and supports key-value retrieval with constant time complexity.
[0163] (2) Test data preparation
[0164] Create a test file named data.txt in the host machine path / home / user / test. The file contains system log information, totaling 100 lines, of which 20 lines contain the keyword "error".
[0165] IV. Specific Implementation Steps
[0166] The user enters the command: `ubuntu_cat data.txt | centos_grep "error" | wc -l` in the Kylin host terminal. The system then performs the following steps:
[0167] 1. Command Reception and Preliminary Analysis
[0168] The GShell character command-line interface of the dual-mode interactive subsystem 200 receives the compound command string "ubuntu_cat data.txt | centos_grep "error" | wc -l" input by the user and passes it to the instruction fusion scheduling module 310.
[0169] 2. Command string parsing
[0170] The instruction fusion scheduling module 310 receives the command line string data and identifies the pipe operator "|". Using the pipe operator as a separator, it parses the command line string into a string array containing three sub-commands:
[0171] Subcommand 1: "ubuntu_cat data.txt"
[0172] Subcommand 2: "centos_grep "error""
[0173] Subcommand 3: "wc -l"
[0174] For each subcommand, it is further parsed into a command verb and a list of parameters:
[0175] Subcommand 1: Command verb "ubuntu_cat", parameter list ["data.txt"]
[0176] Subcommand 2: Command verb "centos_grep", parameter list ["error"]
[0177] Subcommand 3: Command verb "wc", parameter list ["-l"]
[0178] 3. Heterogeneous task determination
[0179] The instruction fusion scheduling module 310 sequentially uses each command verb as an index key to perform matching and retrieval on the heterogeneous command fingerprint storage module 320:
[0180] • Search using "ubuntu_cat" as the index key: If the search is successful, it is determined to be a heterogeneous task. The corresponding image configuration information (ubuntu:22.04, / bin / cat) is extracted and sent to the environment context mapping module 410.
[0181] • Search using "centos_grep" as the index key: If the search is successful, it is determined to be a heterogeneous task, and the corresponding image configuration information (centos:8, / bin / grep) is extracted and sent to the environment context mapping module 410;
[0182] • Search using "wc" as the index key: If the search fails, it is determined to be a local task and marked as to be executed in the current process context of the host machine.
[0183] 4. Environment Context Capture and Mapping
[0184] For the two heterogeneous tasks, the environment context mapping module 410 performs the following operations:
[0185] (4-1) Call the host system interface to obtain the current terminal user's user identifier UID is 1000 and group identifier GID is 1000;
[0186] (4-2) Get the absolute path of the current shell session's working directory " / home / user / test";
[0187] (4-3) For the ubuntu_cat command, construct container startup parameters that include authentication parameters and file path mapping parameters:
[0188] • Identity parameters: Write UID 1000 and GID 1000 into the container startup parameters as the running identity (-u 1000:1000)
[0189] • Mount parameters: Write the absolute path of the working directory into the container startup parameters via volume mount (-v / home / user / test: / home / user / test).
[0190] • Working directory: Set the working directory inside the container to / home / user / test (-w / home / user / test)
[0191] • Automatic cleanup: Inject the automatic cleanup flag (--rm)
[0192] (4-4) Perform the same context mapping operation on the centos_grep command to build its container startup parameters.
[0193] The above mapping ensures that programs inside the container can read and write files in the mount directory as the host user, with permissions consistent with those of the host user.
[0194] 5. Pipeline channel establishment
[0195] The host I / O streaming bridge module 420 detected a pipe operator in the instruction and performed the following operation:
[0196] (5-1) Allocate and create two standard pipe file objects, pipe1 and pipe2, in the host machine's memory;
[0197] (5-2) Establish a data stream connection using the file descriptor copying mechanism (dup2):
[0198] Connect the standard input (file descriptor 0) of the host shell process to the standard input of the first container (ubuntu_cat);
[0199] Connect the standard output of the first container (ubuntu_cat) to the standard input of the second container (centos_grep) via pipe1;
[0200] • Connect the standard output of the second container (centos_grep) to the standard input of the local command (wc) via pipe2;
[0201] Connect the standard output of the local command (wc) to the standard output (file descriptor 1) of the host terminal.
[0202] By manipulating the file descriptor table, the output stream file descriptor of the preceding execution unit is directly bridged to the input stream file descriptor of the following execution unit, enabling memory-level data transfer across the boundary between the host machine and the container, without requiring the data to be stored on the ground.
[0203] 6. Container transient execution
[0204] The containerized execution engine interface module 510 adopts a transient container scheduling mode to process two heterogeneous tasks sequentially:
[0205] (6-1) Upon receiving the start signal of the ubuntu_cat task, and based on the container start parameters generated by the environment context mapping module 410, instantiate the first container object immediately and generate Docker execution instructions:
[0206] docker run --rm -u 1000:1000 -v / home / user / test: / home / user / test -w / home / user / test ubuntu:22.04 / bin / cat data.txt
[0207] Inject the automatic cleanup flag parameter (--rm) into the container startup parameters. After the container starts, execute / bin / catdata.txt, read the file contents, and output them through pipe1;
[0208] (6-2) Receive the start signal from the centos_grep task, and instantiate the second container object immediately according to the corresponding container start parameters, generating Docker execution instructions:
[0209] docker run --rm -u 1000:1000 -v / home / user / test: / home / user / test -w / home / user / test centos:8 / bin / grep error
[0210] The container receives input data from pipe1, performs grep filtering, and outputs the results through pipe2.
[0211] (6-3) The local wc command is executed directly on the host machine, receives input from pipe2, counts the number of lines and outputs it to the terminal.
[0212] 7. Real-time monitoring and resource recycling
[0213] The containerized execution engine interface module 510 monitors the exit status code integers returned by the target programs within the two containers in real time.
[0214] (7-1) When the ubuntu_cat container finishes execution, it returns an exit status code of 0. The module immediately triggers the container destruction process based on the exit status code, automatically clearing the container instance and its temporary file layer generated during runtime, and releasing host machine resources.
[0215] (7-2) Once the centos_grep container finishes execution, it returns an exit status code of 0, which also triggers the automatic destruction process;
[0216] (7-3) The entire command execution process ends and system resources are completely reclaimed.
[0217] 8. Result Output
[0218] The final statistical result "20" is output to the host terminal, indicating that there are 20 lines in the data.txt file containing the keyword "error". The user's execution experience in the terminal is exactly the same as executing a single local command.
[0219] V. Verification of Technical Effects
[0220] The above steps verified the functionality of the five core modules:
[0221] (1) Heterogeneous command fingerprint storage module: A heterogeneous mapping database with key-value pair structure was successfully constructed, storing complete configuration information of ubuntu_cat and centos_grep, including the target container image name, absolute path of the executable program, version tag and dependent library environment, which can realize fast retrieval;
[0222] (2) Instruction fusion scheduling module: Successfully parsed the compound command string containing pipe characters, accurately separated the command verbs and parameter lists of the three sub-commands, correctly determined the two heterogeneous tasks and one local task by matching and searching the fingerprint database, and realized the dynamic diversion of the execution path;
[0223] (3) Environment Context Mapping Module: Successfully captured the current user's UID 1000, GID 1000 and working directory / home / user / test, and automatically constructed container startup parameters containing authentication parameters and file path mapping parameters, ensuring that the programs in both containers can access the mounted files as the host user, thus avoiding permission conflicts;
[0224] (4) Host I / O streaming bridge module: Successfully created a pipe object in the host memory, established a data transmission channel across three execution environments through the file descriptor copying mechanism, realized the memory-level data flow from Ubuntu container → CentOS container → host process, and had no disk I / O operation during data processing, verifying the transparent transmission capability of cross-environment data flow;
[0225] (5) Containerized execution engine interface module: It adopts transient container scheduling mode. After receiving the start signal, it can quickly complete the instantiation of two containers. After execution, it immediately triggers the automatic destruction process. The container instance is completely cleared by the docker ps command and the system resource usage is restored to the level before execution.
[0226] The technical solution adopted in this embodiment achieves cross-container streaming data transmission based on the following principles:
[0227] (1) Pipe communication mechanism: Using the pipe mechanism provided by the operating system kernel, a data transmission channel is established in memory to avoid the I / O overhead caused by data being stored on the hard drive;
[0228] (2) File descriptor copying: The dup2 system call is used to redirect file descriptors, enabling direct connection of standard input and output streams between different processes;
[0229] (3) Transient container mode: The --rm parameter provided by the container runtime is used to realize the automatic cleanup of the container and avoid the accumulation of container instances.
[0230] The above-mentioned technical means are all standard functions of operating systems and container runtimes, and are technically mature and reliable.
[0231] Application Example 2: Heterogeneous Program Execution Method Based on GShell Character Command Line
[0232] This embodiment corresponds to the GShell character command interpreter running method described in Part III of the invention, such as... Figure 1 , Figure 3 , Figure 4 , Figure 5 The diagram illustrates the complete process of executing the heterogeneous binary program matrix_tool through the GShell character command-line interface.
[0233] I. Background Information
[0234] like Figure 3 As shown, the heterogeneous binary program matrix_tool is a simple C++ example program whose source code contains basic iostream library calls. This program was compiled into a binary executable file under Ubuntu 22.04 and depends on dynamic libraries such as GLIBC 2.34 and libstdc++.so.6.
[0235] When the program is run directly on a host machine running the domestic Kylin operating system (Kylin V10, glibc version 2.31), the dynamic linker reports an error "version 'GLIBC_2.34' not found" due to incompatibility of the underlying library versions, causing the program to fail to execute. Figure 3 As shown, when checking the program's dependencies using the ldd command, it can be seen that several dynamic libraries cannot be found or their versions are mismatched.
[0236] The existing solutions have the following shortcomings: (1) They require users to manually install Docker and master complex command-line parameters (such as docker run -it -v $(PWD):$(PWD) ...), which has a very high operational threshold and is difficult for non-professional users to master complex mounting and permission configuration; (2) Forcibly upgrading the host system library poses a risk of damaging the stability of the domestic operating system. This embodiment solves this compatibility problem through containerization.
[0237] II. System Configuration
[0238] The program computing device is a personal computer with the Kylin V10 operating system installed; the heterogeneous environment resource pool consists of a locally installed Docker engine and a pre-downloaded ubuntu:22.04 container image.
[0239] III. Pre-configured
[0240] During the initial deployment of the platform, a heterogeneous mapping database with a key-value pair structure is constructed using the heterogeneous command fingerprint storage module 320. For example... Figure 4 As shown, the database uses JSON format for storage, and the mapping configuration for the matrix_tool command is as follows:
[0241] Command verb (key): "matrix_tool"
[0242] Target container image: "ubuntu:22.04"
[0243] Interaction type: "cli"
[0244] The executable program path (entrypoint) within the container is: " / usr / local / bin / matrix_tool
[0245] Automatic cleanup flag (auto_rm): "true"
[0246] The system adopts an "on-demand registration, default local" strategy, and the configuration file only needs to define the mapping relationship of heterogeneous commands.
[0247] IV. Specific Implementation Steps
[0248] The steps in this embodiment correspond to the method described in Part III of the invention. In this embodiment, steps 1 and 2 of Part III of the invention are combined into step 1, and step 5 of Part III of the invention is expanded into steps 4 to 6 in order to provide a detailed explanation of the technical details.
[0249] The user enters the command `matrix_tool` in the terminal of the Kylin host machine. The system then performs the following steps:
[0250] First, the GShell character command-line interface of the dual-mode interactive subsystem 200 displays a command prompt on the host terminal and blocks and waits for input; it receives the command-line string data "matrix_tool" entered by the user in the terminal;
[0251] Second, the instruction fusion scheduling module 310 splits and parses the command line string data into the command verb string "matrix_tool" and a parameter list (in this example, the parameter list is empty);
[0252] Third, the instruction fusion scheduling module 310 matches and retrieves the command verb string "matrix_tool" with the heterogeneous command key pre-configured in the heterogeneous command fingerprint storage module 320;
[0253] 4. The search hits and determines that it is a heterogeneous task. The target container image "ubuntu:22.04" and related configuration information are extracted from the heterogeneous command fingerprint storage module 320.
[0254] 5. Trigger the environment context mapping module 410, call the host system interface to obtain the current terminal user's user identifier UID is 1000 and group identifier GID is 1000, and obtain the absolute path of the current shell session's working directory " / home / user / workspace", and synchronize the current terminal's environment variable set;
[0255] 6. As Figure 5 As shown, the environment context mapping module 410 constructs container startup parameters that include authentication parameters and file path mapping parameters, specifically including: user mapping parameter "-u 1000:1000", directory mount parameter "-v / home / user / workspace: / home / user / workspace", working directory parameter "-w / home / user / workspace", automatic cleanup parameter "--rm", and interactive mode parameter "-i".
[0256] 7. Check if the scanning command contains a pipe operator. In this example, there is no pipe operator. The host I / O streaming bridge module 420 establishes a standard input / output channel in the host memory. Using the file descriptor copying mechanism (dup2), it obtains the integer handles (0, 1, 2) of the standard input, standard output, and standard error file descriptors of the host shell process and redirects them to the input / output stream handles corresponding to the container instance to be started, ensuring that the output of the program in the container can be directly echoed on the Kylin terminal.
[0257] 8. Figure 5 As shown, the containerized execution engine interface module 510, based on the container startup parameters constructed in step 6, calls the underlying Docker container runtime to generate complete containerized execution instructions:
[0258] docker run --rm -i -u 1000:1000 -v / home / user / workspace: / home / user / workspace -w / home / user / workspace ubuntu:22.04 / usr / local / bin / matrix_tool
[0259] An Ubuntu 22.04 container is instantiated, and an automatic cleanup flag parameter is injected into the container's startup parameters. Then, " / usr / local / bin / matrix_tool" is executed within the container. At this point, matrix_tool is actually running in the Ubuntu 22.04 container environment and can successfully load its required GLIBC 2.34 library.
[0260] 9. The standard output data stream of the execution result is transmitted in real time through the I / O bridge channel established in step 7 and echoed back to the host terminal interface. The user can see the "Hello, KylinOS!" string output by the program in the Kylin terminal.
[0261] 10. After the matrix_tool target program finishes execution, the containerized execution engine interface module 510 monitors the exit status code integer returned by the target program in the container in real time. Once the exit status code 0 is captured, the container destruction process is triggered immediately according to the exit status code. The container destruction and temporary resource reclamation operations are automatically executed to clear the container instance and its temporary file layer generated during runtime, release host machine resources, and end the current command execution process.
[0262] like Figure 1 As shown, the execution flow of this embodiment corresponds to Figure 1The following steps are as follows: Step 100 corresponds to Step 1 of this embodiment; Step 110 corresponds to Step 2 of this embodiment; Step 115 corresponds to Steps 3-4 of this embodiment; Since the retrieval hit is found in this example, Step 116 is skipped; Step 130 corresponds to Step 7 of this embodiment; Since there is no pipe operator in this example, Step 140 is simplified to establishing a standard I / O channel; Step 150 corresponds to Steps 5-6 and Step 8 of this embodiment; Step 170 corresponds to Steps 9-10 of this embodiment.
[0263] V. Verification of Technical Effects
[0264] Through the above steps, the Ubuntu 22.04 program matrix_tool, which could not run directly on the Kylin V10 host due to GLIBC version incompatibility, can be transparently executed by users through simple command-line input without requiring them to understand Docker container technology.
[0265] Verified through actual testing:
[0266] (1) Compatibility verification: When matrix_tool is run directly on the host machine, the error "version 'GLIBC_2.34' not found" occurs and it cannot be executed; when run on the platform of this invention, the program is successfully executed and outputs "Hello, KylinOS!", proving that the problem of incompatibility between library versions across operating systems has been successfully solved;
[0267] (2) Container startup time: relatively short, the specific time depends on the system configuration;
[0268] (3) Execution experience: The program output is directly displayed on the host terminal, and the user's experience is basically the same as executing it directly on the local machine;
[0269] (4) Resource usage: The container is automatically destroyed after the program finishes execution. The container instance is cleared by verifying with docker ps and the system resource usage is restored to the level before execution.
[0270] The entire process is largely transparent to the user, allowing them to execute heterogeneous programs via command-line input without worrying about the complex underlying cross-system adaptation process.
[0271] Application Example 3: Heterogeneous Application Launch Method Based on Graphical Interface
[0272] This embodiment corresponds to the graphical command interpreter running method described in Part Two of the invention, and describes a technical solution for launching heterogeneous graphical applications through a graphical user interface. This implementation is based on the same technical principle as Embodiment 1, the main difference being that the interaction entry point is expanded from the command-line interface to a graphical desktop environment.
[0273] The following explanation uses the example of launching the "gedit" text editor, a graphical application compiled for Ubuntu 20.04.
[0274] I. System Configuration
[0275] The program computing device is a personal computer running the Kylin V10 operating system; the heterogeneous environment resource pool consists of a locally installed Docker engine and a pre-downloaded ubuntu:20.04 container image.
[0276] II. Pre-configured
[0277] The following mapping relationship is pre-configured for the gedit application in the heterogeneous command fingerprint storage module 320:
[0278] Metadata (key) associated with the application icon: "gedit.desktop"
[0279] Target container image: "ubuntu:20.04"
[0280] Interaction type: "gui"
[0281] The absolute path (entrypoint) of the executable program within the container: " / usr / bin / gedit
[0282] Automatic cleanup flag (auto_rm): "true"
[0283] III. Specific Implementation Steps
[0284] First, the graphical interface of the dual-mode interactive subsystem 200 enters the background listening state to monitor user operation signals of the host desktop environment in real time.
[0285] Second, capture the double-click operation signal of the user targeting a specific heterogeneous application icon, that is, the user double-clicks the "gedit" application icon on the desktop;
[0286] Third, using the metadata "gedit.desktop" associated with the heterogeneous application icon as the index key, retrieve the heterogeneous command fingerprint storage module 320;
[0287] Fourth, obtain the target container image name "ubuntu:20.04" and the default container startup parameters from the heterogeneous command fingerprint storage module 320;
[0288] Fifth, trigger the environment context mapping module 410 to capture the display interface parameters (DISPLAY environment variables) and audio device parameters of the current graphical desktop session;
[0289] 6. Construct a configuration file containing display interface mapping parameters and user home directory mount paths, specifically including: display interface mapping parameter "-e DISPLAY=:0", X11 socket mount parameter "-v / tmp / .X11-unix: / tmp / .X11-unix", user home directory mount parameter "-v / home / user: / home / user", and automatic cleanup parameter "--rm";
[0290] 7. Through the containerized execution engine interface module 510, the underlying Docker container runtime is invoked according to the container startup parameters to generate complete containerized execution instructions:
[0291] Docker run --rm -e DISPLAY=:0 -v / tmp / .X11-unix: / tmp / .X11-unix -v / home / user: / home / user ubuntu:20.04 / usr / bin / gedit
[0292] Instantiate an Ubuntu 20.04 container and execute " / usr / bin / gedit" inside the container;
[0293] 8. The graphical interface output data stream of the target container is redirected to the host machine's window manager for rendering and display via the X11 protocol. The user can see the gedit application window on the host machine's desktop and operate it normally until the user closes the application window.
[0294] 9. After the user closes the gedit application window, the program exits. The containerized execution engine interface module 510 captures the exit signal and automatically performs container destruction operations to clean up temporary resources.
[0295] IV. Technical Solution Description
[0296] This embodiment uses the same core technology mechanism as Embodiment 1, including heterogeneous command fingerprint mapping, automatic environment context capture, I / O streaming bridging, and container transient management. The main differences between the two are:
[0297] (1) Different interaction entry points: Example 1 receives user input through the GShell character command line interface, while this example captures the double-click signal of the icon through the graphical operation interface;
[0298] (2) Different environmental parameter mappings: Example 1 mainly maps the working directory and user permissions, while this example additionally maps the display interface (DISPLAY) and X11 socket to support normal rendering of the graphical interface;
[0299] (3) Different data stream bridging methods: Example 1 bridges the standard input / output stream, while this example bridges the X11 graphics data stream.
[0300] This implementation method enables transparent launching of heterogeneous graphical applications. Users can run graphical applications that were previously unusable due to system incompatibility simply by double-clicking the desktop icon. The application window displays normally on the host desktop, file read / write permissions are synchronized with the host user, and the container is automatically cleaned up after the application is closed. This implementation method demonstrates that the technical solution of this invention is applicable to different interaction scenarios.
[0301] V. Verification of Technical Effects
[0302] This implementation method is based on the same core technology mechanism as Example 1, and uses the following technical means to achieve compatible operation of graphical applications:
[0303] (1) Heterogeneous command fingerprint mapping mechanism: Through the pre-defined mapping relationship, the graphical application icon is associated with the corresponding container image;
[0304] (2) Automatic capture of environment context: Automatically obtain the DISPLAY environment variable and X11 socket path of the current desktop session for cross-environment transmission of the graphical interface;
[0305] (3) Container transient management: The same automatic creation and destruction mechanism as in Example 1 is adopted;
[0306] (4) Graphics data stream bridging: Transmit the graphics output of the application in the container to the host window manager via the X11 protocol.
[0307] The above-mentioned technical methods are all based on mature container technology and the X11 protocol, and are technically feasible.
[0308] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims
1. A container-based cross-operating system computing platform, characterized in that, The platform includes a program computing device and a heterogeneous container instance pool; The heterogeneous container instance pool consists of several container instances; The program computing device includes at least: a dual-mode interaction subsystem, a heterogeneous command fingerprint storage module, an instruction fusion scheduling module, an environment context mapping module, a host I / O streaming bridge module, and a containerized execution engine interface module; in, The dual-mode interactive subsystem provides both a graphical user interface and a GShell character command-line interface, serving as a unified entry point for receiving complex user command inputs and maintaining the context state of the Shell session. The heterogeneous command fingerprint storage module, as middleware connecting the host environment and the container environment, is used to store the fingerprint mapping relationship between external heterogeneous commands and container images. The instruction fusion scheduling module is used to parse the instruction string input by the user, separate the command verb and the flow control character, and use the command verb as an index to retrieve the heterogeneous command fingerprint storage module, thereby dynamically determining whether the execution path of the instruction is local execution on the host machine or containerized compatible execution. The environment context mapping module is used to capture the current user identity information and working directory status of the host machine when containerization is triggered, and to calculate container startup parameters, including user permission mapping UID / GID and directory mount path. The host I / O streaming bridge module is used to build a data transmission channel between the host shell process and the container isolation process. By intercepting and mapping standard input / output and pipe operators, it enables transparent data transmission across environments. The containerized execution engine interface module is used to interface with the underlying container runtime, instantiate a specific Linux distribution container according to the startup parameters, and is responsible for the transient creation and destruction of the container lifecycle.
2. The platform according to claim 1, characterized in that, The heterogeneous command fingerprint storage module is specifically configured as follows: a heterogeneous mapping database with a key-value pair structure is constructed; the key of the heterogeneous mapping database is the verb string of the external heterogeneous command; the value of the heterogeneous mapping database is a configuration set containing the target container image name, the absolute path of the executable program inside the container, the version tag, and the dependent library environment.
3. The platform according to claim 1, characterized in that, The instruction fusion scheduling module is specifically configured to: receive command line string data input by the user; parse the command line string data into a string array containing command verbs and parameter lists using a delimiter; and use the first word in the string array as an index key to perform matching and retrieval on the heterogeneous command fingerprint storage module. If the search finds a match, the instruction is determined to be a heterogeneous task, and the corresponding image configuration information is extracted and sent to the environment context mapping module. If the search fails, the instruction is determined to be a local task, and the host machine's system call interface is invoked to execute the instruction in the current process context.
4. The platform according to claim 1, characterized in that, The environment context mapping module is specifically configured as follows: it calls the host system interface to obtain the user identifier and group identifier of the current terminal user; it obtains the absolute path of the working directory of the current shell session; it constructs a container startup parameter that includes authentication parameters and file path mapping parameters; it writes the user identifier and group identifier into the container startup parameter as the running identity, and writes the absolute path of the working directory into the container startup parameter through volume mounting, thereby ensuring that the program in the container has the same permissions to read and write mounted files as the host user.
5. The platform according to claim 1, characterized in that, The specific configuration of the host I / O streaming bridging module is as follows: It allocates and creates standard pipe file objects in the host memory; utilizes the file descriptor copying mechanism to obtain the integer handles of the standard input, standard output, and standard error file descriptors of the host shell process, and redirects them to the input / output stream handles corresponding to the container instance; when the instruction contains a pipe operator, the module directly bridges the output stream file descriptor of the preceding execution unit to the input stream file descriptor of the following execution unit by manipulating the file descriptor table, thereby achieving memory-level data flow across the boundary between the host and the container.
6. The platform according to claim 1, characterized in that, The containerized execution engine interface module is specifically configured as follows: it adopts a transient container scheduling mode for resource management; it instantiates a container object immediately upon receiving a startup signal and injects an automatic cleanup flag parameter into the container startup parameters; it monitors the exit status code integer returned by the target program in the container in real time, and once the target program finishes execution, it immediately triggers the container destruction process according to the exit status code, automatically clears the container instance and its runtime temporary file layer, and releases host machine resources.
7. A method for running a graphical command interpreter on a container-based cross-operating system computing platform, characterized in that, The method includes the following specific steps: First, the graphical user interface of the dual-mode interactive subsystem enters a background listening state to monitor user operation signals of the host desktop environment in real time.
2. Capture double-click signals or shortcut call signals from users targeting specific heterogeneous application icons; Third, using the metadata associated with the heterogeneous application icon as the index key, retrieve the heterogeneous command fingerprint storage module; 4. Obtain the target container image name and default container startup parameters from the heterogeneous command fingerprint storage module; 5. Trigger the environment context mapping module to capture the display interface parameters and audio device parameters of the current graphical desktop session; 6. Build container startup parameters that include display interface mapping parameters and user home directory mount path; 7. The target container is started by calling the underlying container runtime according to the container startup parameters through the containerized execution engine interface module.
8. Redirect the graphical interface output data stream of the target container to the host machine's window manager for rendering and display until the user closes the application window; 9. After the user closes the application window, the container destruction and temporary resource reclamation operations will be automatically executed, ending the execution process of this graphical application.
8. A method for running the GShell character command interpreter on a container-based cross-operating system computing platform, characterized in that, The method includes the following specific steps: First, the command prompt is displayed on the host terminal through the GShell character command interaction module, and the system blocks and waits for input. Second, receive command line string data entered by the user in the terminal; 3. The command line string data is segmented and parsed into command verb strings and parameter list arrays using the instruction fusion scheduling module; 4. Match and retrieve the command verb string with the heterogeneous command key in the heterogeneous command fingerprint storage module; 5. If the search is successful, the environment context mapping module is triggered to synchronize the absolute path of the current terminal's working directory and the set of environment variables.
6. Check if there is a pipe operator in the scan command. If so, use the host I / O streaming bridge module to establish a file descriptor mapping channel in the host memory.
7. Perform cross-process interfacing between the standard output stream handle of the preceding execution unit and the standard input stream handle of the following container instance; 8. The containerized execution engine interface module starts the container and executes the target program according to the context mapping parameters; 9. Transmit the standard output data stream of the execution result to the host terminal interface in real time and display it back. Step 10: After the target program finishes execution, the container destruction and temporary resource reclamation operations will be automatically performed, ending the current command execution process.