A Linux eco-compatible real-time operating system and method based on hierarchical decoupling

Abstract

The application relates to the technical field of system compatibility, in particular to a Linux ecological compatible real-time operating system and method based on layered decoupling. The method comprises the following steps: dividing a real-time operating system into a user state and a kernel state, wherein the user state comprises an application layer, a system interface layer and a programming interface layer from top to bottom, and the kernel state comprises a macro kernel real-time kernel layer; providing a Linux construction tool chain at the application layer, establishing an embedded Linux basic tool set initialization environment and a command line interactive environment at the system interface layer; the application realizes the compatible connection of the Linux ecology and the real-time kernel through layered decoupling of the user state and the kernel state and POSIX standard calling adaptation, and realizes the context fixation of the system calling and the unified adaptation of VFS, so that the influence of the compatible layer on the real-time scheduling of the real-time kernel is reduced while the Linux application compatibility is ensured.

Description

Technical Field

[0001] This invention relates to the field of system compatibility technology, and in particular to a Linux ecosystem-compatible real-time operating system and method based on layered decoupling. Background Technology

[0002] Real-time operating systems are widely used in embedded scenarios with high requirements for real-time performance and reliability, such as aerospace, high-end industrial control, and automotive electronics. Existing RTOS (Real-Time Operating Systems) typically adopt a layered architecture of application layer and kernel layer, but their interfaces, build environments, and system operation mechanisms differ from the Linux ecosystem. Some systems have incomplete support for POSIX interfaces, Linux build toolchains, shells, and virtual file systems, resulting in high costs for porting Linux applications and open-source components and making it difficult to directly reuse the Linux software ecosystem.

[0003] Meanwhile, when adding Linux compatibility features to existing RTOSs, compatibility processing is easily coupled with the real-time kernel's scheduling and resource management, leading to increased system overhead and affecting the determinism of real-time scheduling; moreover, some systems lack a complete VFS virtual file system adaptation mechanism, making it difficult to access processes, devices, and system resources in a unified manner according to Linux standards.

[0004] Therefore, there is an urgent need for a real-time operation method that can both improve the compatibility of the Linux ecosystem and reduce the impact of compatibility mechanisms on the real-time performance of the real-time kernel. Summary of the Invention

[0005] Therefore, it is necessary to provide a Linux ecosystem-compatible real-time operating system and method based on layered decoupling to solve at least one of the above-mentioned technical problems.

[0006] To achieve the above objectives, a Linux ecosystem-compatible real-time operation method based on layered decoupling is proposed, the method comprising the following steps: Step S1: Divide the real-time operating system into user mode and kernel mode. The user mode includes the application layer, system interface layer and programming interface layer from top to bottom. The kernel mode includes the monolithic kernel and real-time kernel layer. Step S2: Provide a Linux build toolchain at the application layer, establish an embedded Linux basic toolset initialization environment and command-line interactive environment at the system interface layer, and mount the process information virtual file system, device file virtual file system and system information virtual file system; Step S3: By calling the POSIX PSE54 standard interface provided by the standard C language runtime library through the programming interface layer, the system requests generated by the application layer and the system interface layer are encapsulated into standard system call requests; Step S4: The POSIX adaptation layer in the real-time kernel layer of the monolithic kernel receives and verifies standard system call requests, converts the verified requests into corresponding kernel native service calls, and executes them by the real-time kernel. Step S5: The Linux file system is uniformly adapted through the VFS virtual file system layer, enabling user space to access kernel resources through standard system call requests, and real-time scheduling is performed by the monolithic kernel real-time kernel layer.

[0007] This invention provides a Linux ecosystem-compatible real-time operating system based on layered decoupling, used to execute the Linux ecosystem-compatible real-time operation method based on layered decoupling as described above. The Linux ecosystem-compatible real-time operating system based on layered decoupling includes: The architecture layering module is used to divide the real-time operating system into user mode and kernel mode. The user mode includes the application layer, system interface layer and programming interface layer from top to bottom, while the kernel mode includes the monolithic kernel and real-time kernel layer. The environment building module is used to provide a Linux build toolchain at the application layer, establish an embedded Linux basic toolset initialization environment and command-line interactive environment at the system interface layer, and mount process information virtual file system, device file virtual file system and system information virtual file system; The encapsulation module is used to call the POSIX PSE54 standard interface provided by the standard C language runtime library through the programming interface layer, and to encapsulate the system requests generated by the application layer and the system interface layer into standard system call requests. The call adaptation module is used to receive and verify standard system call requests based on the POSIX adaptation layer in the real-time kernel layer of the monolithic kernel, convert the verified requests into corresponding kernel native service calls, and execute them by the real-time kernel. The file adaptation module is used to uniformly adapt the Linux file system through the VFS virtual file system layer, enabling user space to access kernel resources through standard system call requests, and real-time scheduling is performed by the monolithic kernel real-time kernel layer.

[0008] The beneficial effects of this invention are as follows: First, by layering and decoupling user space and kernel space, the application layer, system interface layer, programming interface layer, and monolithic kernel real-time kernel layer are functionally isolated. Linux build toolchains, basic toolsets, command-line environments, and virtual file systems are introduced into user space, enabling Linux applications and open-source components to complete compilation, building, and runtime environment adaptation without changing their original usage. Simultaneously, the POSIX PSE54 standard interface is used to uniformly encapsulate upper-layer system requests into standard system call requests, which are then converted into native real-time kernel services by the kernel POSIX adaptation layer. This reduces the coupling between the Linux ecosystem and the real-time kernel, achieving compatibility and seamless integration between the Linux software ecosystem and the real-time kernel execution mechanism.

[0009] Second, by using system call context consistency verification and register combination fixing mechanisms, a stable correspondence between system call numbers, call parameters, and target registers is established before switching from user mode to kernel mode. This ensures that the original system call and its parameters can still be accurately identified after a privilege level switch, reducing call anomalies caused by parameter misalignment under different processor architectures and calling environments. At the same time, the VFS virtual file system layer uniformly adapts to Linux file system resources, and the real-time kernel executes native services and real-time scheduling. This maintains Linux interface compatibility while reducing interference from the compatibility layer on the real-time kernel scheduling path, thus balancing Linux ecosystem compatibility with the deterministic execution capabilities of the real-time operating system. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating the steps of a Linux ecosystem-compatible real-time operation method based on layered decoupling. Figure 2 for Figure 1 A detailed flowchart illustrating the implementation steps of step S4. Figure 3 This is a system architecture diagram of one embodiment; The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0011] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0012] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0013] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0014] To achieve the above objectives, please refer to Figures 1 to 3 A Linux ecosystem-compatible real-time operation method based on layered decoupling, the method comprising the following steps: Step S1: Divide the real-time operating system into user mode and kernel mode. The user mode includes the application layer, system interface layer and programming interface layer from top to bottom. The kernel mode includes the monolithic kernel and real-time kernel layer. Step S2: Provide a Linux build toolchain at the application layer, establish an embedded Linux basic toolset initialization environment and command-line interactive environment at the system interface layer, and mount the process information virtual file system, device file virtual file system and system information virtual file system; Step S3: By calling the POSIX PSE54 standard interface provided by the standard C language runtime library through the programming interface layer, the system requests generated by the application layer and the system interface layer are encapsulated into standard system call requests; Step S4: The POSIX adaptation layer in the real-time kernel layer of the monolithic kernel receives and verifies standard system call requests, converts the verified requests into corresponding kernel native service calls, and executes them by the real-time kernel. Step S5: The Linux file system is uniformly adapted through the VFS virtual file system layer, enabling user space to access kernel resources through standard system call requests, and real-time scheduling is performed by the monolithic kernel real-time kernel layer.

[0015] In some embodiments, taking an embedded real-time operating system with a monolithic kernel architecture as an example, this real-time operating system adopts a layered architecture of user space and kernel space. The user space is divided from top to bottom into an application layer, a system interface layer, and a programming interface layer. The kernel space sets up a monolithic kernel real-time kernel layer. The application layer, system interface layer, and programming interface layer all run in user space. Linux ecosystem compatibility functions are mainly completed in user space. The programming interface layer serves as a unified call entry point between user space and kernel space. The monolithic kernel real-time kernel layer is responsible for real-time task scheduling, memory management, interrupt handling, and kernel resource management.

[0016] After system startup, the system first enters the user-space basic environment initialization process. At the application layer, the system provides a self-developed Linux cross-compilation toolchain and corresponding compilation and build framework. This toolchain is compatible with common Linux build methods such as Makefile, CMake, Meson, Ninja, and autoconf. For example, when deploying zlib to this real-time operating system, a corresponding recipe description file is created in the compilation and build framework. The framework then calls the corresponding configuration, compilation, and installation processes, integrating the generated package into the system rootfs. For embedded applications developed using standard Linux build methods, compilation can be completed directly in this build environment, generating executable programs that can run on this real-time operating system.

[0017] The system then proceeds to the system interface layer initialization process. The system starts the user-space `BusyBox init`, which creates the user-space directory, initializes devices, and starts basic services. It then launches the `BusyBoxshell`, creating a Linux command-line interactive environment. Users can execute common Linux commands such as `ls`, `ps`, `top`, `kill`, and `ifconfig` through the shell. Simultaneously, the system mounts `procfs`, `devfs`, and `sysfs` to the ` / proc`, ` / dev`, and ` / sys` directories, respectively. `procfs` provides process status, scheduling parameters, CPU load, and runtime statistics to user space; `devfs` provides device file nodes; and `sysfs` provides system bus, device attributes, and driver status information.

[0018] For example, when a user executes `cat / proc / ...` in the shell to read the running status of a task, the system interface layer first locates the corresponding procfs file node, without directly accessing the task control structure in the monolithic kernel; the access request for that file node continues to be processed down through the programming interface layer. Thus, the system interface layer provides the Linux command line and virtual file nodes, while the programming interface layer is responsible for completing the actual kernel resource calls.

[0019] At the programming interface layer, the system uses musl libc as the standard C language runtime library and provides POSIX PSE54 standard interfaces based on musl libc. When Linux applications in the application layer and shell and system tools in the system interface layer generate system requests such as file access, process operations, memory allocation, and device access, they first call the corresponding POSIX standard interface. For example, when an application performs a file read operation, it calls the read() interface. musl libc processes the input parameters according to the standard semantics of the interface and encapsulates the system call number and call parameters into the corresponding system call context according to the current processor architecture. Then, it executes the system call instruction, switching the processor from user mode to kernel mode.

[0020] Upon entering kernel mode, standard system call requests are first received by the POSIX adaptation layer in the real-time kernel layer of the monolithic kernel. The POSIX adaptation layer reads the system call number, call parameters, and corresponding call context, performs validity checks on the system call number and parameters, and determines the corresponding native kernel service based on the system call type. For example, for a file read request, the POSIX adaptation layer identifies it as a read operation based on the system call number and converts the standard POSIX request into an existing file read service call in the real-time kernel; for task creation, memory allocation, or device access requests, they are converted into corresponding task management, memory management, or device management service calls, respectively. This POSIX adaptation layer does not reimplement complete POSIX functionality; instead, it converts and forwards standard POSIX requests generated by user-space musl libc to existing native kernel services.

[0021] During the above conversion process, the POSIX adaptation layer also filters illegal system calls and abnormal parameters. Once the request passes the verification, the corresponding native service in the monolithic kernel's real-time kernel performs the specific operation. For example, for a request to read a procfs file, the POSIX adaptation layer forwards the standard read request to the corresponding file operation in the VFS, and then the procfs node reads the corresponding process status information and returns it to user space; for a device file access request, the VFS further locates the corresponding devfs device node and calls the corresponding device service.

[0022] For file-related requests, the VFS virtual file system layer in the monolithic kernel's real-time kernel layer serves as a unified file access entry point. It parses the file paths and file operations submitted by user space and determines the corresponding file system type and operation interface based on the file node. VFS can uniformly adapt to file systems such as tmpfs, dosfs, ext2, devfs, procfs, and sysfs, allowing user-space applications to access process resources, device resources, and system resources through a unified file node without needing to be aware of the specific file system type.

[0023] For example, when a user executes a command to read process information in the ` / proc` directory via the shell, VFS first locates the `procfs` node based on the path, and then calls the corresponding file operation interface of `procfs` to obtain process status information. When a user accesses a device file in the ` / dev` directory, VFS locates the `devfs` device object based on the corresponding node, and further calls the native services provided by the device driver. After resource access is completed, the returned data enters user space along the POSIX adaptation layer and system call return path, and the POSIX interface return value is processed by musl libc, finally being used by the application or shell. Throughout the above process, the monolithic kernel real-time kernel layer is always responsible for real-time task scheduling. When a real-time task is running on the system, the POSIX system call request is only a kernel service request during task execution. The POSIX adaptation layer completes the conversion of standard interface semantics to kernel native services, while the specific resource operations are executed by the monolithic kernel native services. Task switching, interrupt response, and priority scheduling are still handled uniformly by the real-time kernel core. The kernel POSIX adaptation layer, VFS, and real-time scheduling core are used as collaborative modules within the monolithic kernel. The POSIX adaptation layer is responsible for standard system call parsing and verification, VFS is responsible for unified file system adaptation, and the core is responsible for real-time scheduling and kernel resource management.

[0024] It should be noted that the specific system architecture diagram can be found by referring to... Figure 3 Kernel Image refers to the kernel image, which is the operating system kernel file generated after compilation and linking and can be booted by the device. U-Boot is a general boot loader used for hardware initialization and operating system loading after the device is powered on. BSP / ARCH is located below the driver layer and is the adaptation layer between the operating system and the hardware. Specifically, BSP stands for Board Support Package, which refers to the set of software support provided for a specific hardware development board, and ARCH stands for Processor Architecture Support, which represents the CPU architecture adaptation code.

[0025] Preferably, in step S1, dividing the real-time operating system into user mode and kernel mode specifically involves: Based on the runtime environment of a real-time operating system, it is divided into user mode and kernel mode. The user space is divided into the application layer, system interface layer and programming interface layer according to the function call layer, and the application layer, system interface layer and programming interface layer are configured to call downwards in sequence; Configure the kernel mode as a monolithic kernel real-time kernel layer, and configure the kernel POSIX adaptation layer and VFS virtual file system layer in the monolithic kernel real-time kernel layer; Establish a system call channel between the programming interface layer and the kernel POSIX adaptation layer, so that kernel service requests generated by the application layer and the system interface layer can be passed to the kernel POSIX adaptation layer through the programming interface layer.

[0026] In some embodiments, an embedded real-time operating system employing a monolithic kernel architecture is also taken as an example.

[0027] In user space, the system is divided into three layers from top to bottom according to function call relationships: the application layer, the system interface layer, and the programming interface layer. These three layers are configured to call each other sequentially. The application layer is used to run applications built on the Linux ecosystem, such as applications developed in C, C++, or other compatible languages. The system interface layer provides basic Linux tools, command-line interaction, and access to system resources. The programming interface layer is located below the system interface layer and serves as the unified interface for user space to initiate system service requests to kernel space.

[0028] For example, when an application in the application layer needs to read a file, it first calls the standard interface provided by the programming interface layer; similarly, when a command-line tool in the system interface layer needs to obtain process status, it also initiates a corresponding system service request through the programming interface layer. Therefore, system requests generated by both the application layer and the system interface layer enter the programming interface layer via a unified path, rather than establishing separate kernel access paths.

[0029] Furthermore, the system configures the kernel mode as a monolithic kernel real-time kernel layer, and within this layer, it configures a kernel POSIX adaptation layer and a VFS virtual file system layer. The kernel POSIX adaptation layer, located between the user-space programming interface layer and the kernel's native services, receives standard POSIX system call requests from user space. The VFS virtual file system layer, located in the file service path corresponding to the kernel POSIX adaptation layer, provides unified adaptation for different file system types. The kernel as a whole comprises the core, the kernel POSIX adaptation layer, and the VFS virtual file system layer. The POSIX adaptation layer is responsible for receiving, parsing, and verifying standard POSIX system calls from user space, and then converting and forwarding them to the kernel's native services. The VFS layer is responsible for unified adaptation of the Linux file system.

[0030] After completing the above-mentioned layer configuration, the system further establishes a system call channel between the programming interface layer and the kernel POSIX adaptation layer. Specifically, the programming interface layer encapsulates the system requests generated by the application layer and the system interface layer using the standard C language runtime library in a POSIX-standardized manner, organizes the corresponding system call number and call parameters according to the system call convention to form a standard system call request, and triggers the switch from user mode to kernel mode through system call instructions.

[0031] Upon entering kernel mode, the standard system call request first enters the kernel POSIX adaptation layer. The kernel POSIX adaptation layer identifies the kernel service corresponding to the current request based on the system call number and verifies the call parameters. If the verification passes, the request is converted into the corresponding native service call in the monolithic kernel's real-time kernel layer. For example, a file access request is further passed to the VFS virtual file system layer, where VFS determines the corresponding file system processing path based on the file node; other kernel service requests are passed to the native service module in the monolithic kernel's real-time kernel according to their corresponding service type.

[0032] Preferably, step S2 includes the following steps: Step S21: Configure the Linux build toolchain at the application layer, and establish the compilation, building, and linking environment corresponding to the application based on the Linux build toolchain; Step S22: Start the embedded Linux basic toolset initialization program at the system interface layer. The initialization program completes the initialization of the user space basic environment and establishes the system directory and device nodes. Step S23: After the user space basic environment is initialized, start the command line interactive environment so that the system interface layer can receive system operation instructions and call the corresponding system functions through the command line; Step S24: Based on the kernel virtual file system interface, establish the mount relationships between the process information virtual file system, the device file virtual file system, and the system information virtual file system and their corresponding directory nodes, and map the process status, device status, and system resource information to their corresponding directory nodes.

[0033] In some embodiments, an embedded real-time operating system employing a monolithic kernel architecture is still taken as an example.

[0034] Specifically, at the application layer, the system configures the Linux build toolchain as a unified compilation environment for applications and establishes corresponding compilation, build, and linking processes based on the source code of the application to be deployed. For example, for a Linux application developed in C, the system calls the corresponding compiler through the cross-compilation toolchain to compile the application source files into object files corresponding to the target architecture, then generates an executable program through the linking process, and deploys the generated program to the user space of the real-time operating system.

[0035] Subsequently, the embedded Linux basic toolset initialization program is started at the system interface layer. After the initialization program starts, it first establishes the basic directory structure required for user space operation and creates the corresponding device nodes, while completing the initialization of the basic user space operating environment. For example, it establishes the application running directory, configuration directory, and device access directory, and creates the corresponding device nodes according to the current system hardware resources, so that subsequent system tools can access system resources in the manner of Linux user space.

[0036] After the user-space basic environment is initialized, the system interface layer starts the command-line interactive environment. Once started, the command-line interactive environment establishes a terminal input / output channel to receive system operation commands from the user and invokes the corresponding system functions based on those commands. For example, when a user executes commands to view processes, access files, or query devices via the command line, the command-line environment parses the corresponding commands and invokes the relevant basic tools in the system interface layer to complete the processing; these basic tools then further initiate corresponding system service requests to the kernel through the programming interface layer.

[0037] Furthermore, after the user space base directory and device nodes are established, the system establishes the mount relationship between the virtual file system and the user space directory nodes through the kernel virtual file system interface. Specifically, the process information virtual file system is mounted to the corresponding process information directory node, the device file virtual file system is mounted to the device directory node, and the system information virtual file system is mounted to the system information directory node.

[0038] After mounting, the system maps process state information from the real-time kernel to the corresponding directory node of the process information virtual file system, maps hardware devices and device status information to the corresponding directory node of the device file virtual file system, and maps system resources, device attributes, and running status information to the corresponding directory node of the system information virtual file system. For example, when a user accesses the process information directory via the command line, the system locates the process information virtual file system based on the corresponding directory node and reads the process state from the real-time kernel; when accessing the device directory, it locates the corresponding device node through the device file virtual file system.

[0039] Thus, the application layer forms the environment for compiling, building, and linking Linux applications, while the system interface layer forms the Linux basic tools and command-line runtime environment. It maps processes, devices, and system resources in the real-time kernel to user-space directory nodes through process information virtual file systems, device file virtual file systems, and system information virtual file systems. procfs provides process status, scheduling parameters, CPU load, and runtime statistics; devfs manages hardware device file nodes; and sysfs displays system buses, device attributes, and driver status.

[0040] Preferably, step S21 includes: Configure a self-developed Linux cross-compilation toolchain and corresponding compilation and build framework at the application layer, and establish a source code compilation environment for Linux applications based on the compilation and build framework; For each Linux open-source component to be ported, a corresponding build recipe description file is created, and the component source code verification information, toolchain dependencies, root file system dependencies, and patch file information are configured in the build recipe description file; Based on the build recipe description file, the corresponding configuration, compilation and installation processing interfaces of the compilation and build framework are called to sequentially perform build configuration, source code compilation and installation processing on Linux open source components to generate the corresponding software packages; The generated software packages are automatically integrated into the system root file system according to the root file system dependencies, forming a Linux application that can be run directly.

[0041] In some embodiments, a corresponding build recipe description file is created for the Linux open-source component to be ported. For example, for the zlib component, a corresponding .recipe file is created in the build system, recording the SHA256 verification information of the component source code, toolchain dependencies, root file system dependencies, and patch file information to be applied. The source code verification information corresponds to the component source code version, the toolchain dependencies specify the toolchains that the component depends on during compilation, the root file system dependencies determine the system integration relationships of the compiled package, and the patch file information specifies the patch files that need to be applied during the component build process.

[0042] After the build recipe description file is created, the build framework reads the build information from the file and calls the corresponding configuration, compilation, and installation interfaces according to the processing flow defined in the recipe. For example, in the zlib build process, the configuration interface is first called to complete the source code build environment configuration, then the compilation interface is called to execute the source code compilation, and finally the installation interface is called to organize the compiled files into the corresponding software package. Taking zlib as an example, its recipe calls the CMake configuration interface through do_configure, the CMake compilation interface through do_compile, and the CMake installation interface through do_install to complete the entire build process.

[0043] After installation, the build framework automatically integrates the generated packages into the corresponding directory of the system's root filesystem based on the root filesystem dependencies in the build recipe description file. For example, after zlib is compiled and installed, its library files and related runtime files are written to the corresponding location in the system's root filesystem and generated along with the root filesystem.

[0044] Subsequently, during system startup, the integrated software packages are loaded from the rootfs, and Linux applications directly call the corresponding runtime libraries and system interfaces to execute. For standard Linux open-source components built in this manner, there is no need to rebuild a separate porting process. Instead, they enter a unified compilation, installation, and rootfs integration process through the corresponding build recipe, thereby forming Linux applications that can run directly in the user space of this real-time operating system. This build layer can complete the entire build process of open-source components by writing corresponding .recipe description files and automatically integrate the generated software packages into the system rootfs.

[0045] Preferably, the configuration method for the self-developed Linux cross-compilation toolchain and the corresponding compilation and build framework includes: Create a build recipe for the Linux application to be built, and record the toolchain dependency information used to complete the application compilation and the root file system dependency information used to run the application. The application configuration and compilation are completed by calling the corresponding Linux build toolchain based on the toolchain dependency information, and the runtime components corresponding to the compilation artifacts are determined based on the root file system dependency information. During the application installation process, the compiled artifacts are associated with the identified runtime components according to the corresponding root file system directory relationships, and an application package is generated. Based on the root file system dependency information, the application package and its corresponding runtime components are synchronously integrated into the system root file system, so that the application's compilation dependencies and runtime dependencies are matched during the build phase.

[0046] In some embodiments, for the Linux application to be built, a corresponding build recipe is first established in the compilation and build framework, and toolchain dependency information and root file system dependency information are recorded in the build recipe. The toolchain dependency information is used to determine the compilation tools and their dependent components called during the application source code compilation process, and the root file system dependency information is used to determine the runtime components that need to be integrated into the system root file system at runtime.

[0047] After the build recipe is established, the build framework reads the toolchain dependency information and calls the corresponding Linux cross-compilation toolchain to perform configuration and compilation processing on the Linux application source code. For example, when the application to be built uses CMake for configuration, the build framework calls the corresponding cross-compiler and CMake configuration interface according to the toolchain dependency information to establish the compilation environment for the target architecture, and executes source code compilation after configuration to generate the application compilation artifacts corresponding to the target architecture.

[0048] During application installation, the build framework further reads the root file system dependency information and determines the corresponding runtime components based on the runtime dependencies recorded therein. For example, if an application requires a dynamic library, the system determines the required dynamic library based on the root file system dependency information and associates the application's compilation artifacts with the corresponding dynamic library. Subsequently, according to the directory relationships in the root file system, the application and its runtime components are mapped to the application directory, library directory, and other runtime resource directories, and the application package is generated accordingly.

[0049] After the application package is generated, the build framework continues to perform system integration processing based on the root file system dependency information, synchronously writing the application package and its corresponding runtime components to the system root file system. For example, the application is written to the application directory of the root file system, the corresponding dynamic libraries are written to the library directory, and the dependency relationship between the application and the dynamic libraries is maintained.

[0050] Preferably, step S3, which encapsulates the system requests generated by the application layer and the system interface layer into standard system call requests, includes: The programming interface layer receives system requests generated by the application layer and the system interface layer, and determines the system call type based on the POSIX interface corresponding to the system request. The standard C runtime library is invoked to validate the parameters of the system request and determine the corresponding standard system call number according to the target system call type; Based on the target processor architecture, the standard system call number and system call parameters are loaded into the corresponding processor register, and a standard system call request is constructed according to the system call instructions corresponding to the processor architecture. Executing a system call instruction triggers a switch from user mode to kernel mode, sending the standard system call request to the POSIX adaptation layer in kernel mode.

[0051] In some embodiments, an embedded real-time operating system employing a monolithic kernel architecture is still taken as an example.

[0052] When a Linux application in the application layer needs to read a file, it sends a corresponding read request to the programming interface layer. Similarly, when command-line tools in the system interface layer perform operations such as file reading or process querying, they also call the corresponding POSIX interface through the programming interface layer. The programming interface layer first determines the corresponding system call type based on the POSIX interface invoked in the current system request. For example, a file read request is determined to be a read type, a file open request to be determined to be an open type, and a file close request to be determined to be a close type.

[0053] After determining the system call type, the standard C runtime library musl libc processes and validates the call parameters of the current system request, and obtains the corresponding standard system call number based on the determined system call type. For example, when the current request corresponds to the read interface, musl libc determines the corresponding system call number according to the system call convention corresponding to that interface, and organizes the file descriptor, data buffer address, and read length as the corresponding system call parameters. musl libc is responsible for POSIX function encapsulation and system call construction, and performs parameter validation and compatibility adaptation before forming the system call.

[0054] Subsequently, the system determines the system call parameter loading method based on the target processor architecture of the current real-time operating system. For processors using the x86 architecture, the system loads the standard system call number and corresponding call parameters into the designated processor register according to the x86 system call convention, and uses the corresponding system call instruction to form a system call request. For processors using the ARM / AArch64 architecture, the system loads the corresponding parameters according to the ARM / AArch64 system call convention, and triggers the system call using the svc instruction. The x86 architecture uses the int 0x80 or syscall instruction, while the ARM / AArch64 architecture uses the svc instruction, and the system call number and interface parameters are loaded into the designated register according to the kernel convention.

[0055] For example, when a Linux application performs a file read operation on an ARM / AArch64 processor, musllibc first generates the corresponding standard system call number based on the read interface, and loads the system call number, file descriptor, buffer address, and read length into the corresponding registers according to the system call convention. Then, it executes the svc instruction. After the processor executes this instruction, it switches the current execution environment from user mode to kernel mode and passes the already loaded system call number and call parameters to the kernel as the current system call request.

[0056] Upon entering kernel mode, standard system call requests first reach the POSIX adaptation layer in the monolithic kernel's real-time kernel layer. The POSIX adaptation layer reads the system call number and parameters, parses and verifies the system call request, and further converts it into the corresponding native kernel service call based on the system call type. The POSIX adaptation layer, located in kernel mode, receives, parses, and verifies standard POSIX system calls issued from user mode, and then converts and forwards them to the original kernel services.

[0057] Preferably, the process further includes the following steps before executing a system call instruction to trigger a switch from user mode to kernel mode: The order in which the call parameters are passed is determined based on the system call number corresponding to the standard system call request, and the correspondence between the system call parameters and the target register is established according to the current processor architecture. The system call number and call parameters are formed into a unified system call context according to the correspondence, and the consistency between the system call number and the call parameters in the system call context is verified. The system call context that passes the consistency check is fixed to the call context area corresponding to the current task, so that the system call request initiated by the user mode maintains the correspondence between the system call number and the call parameters after the user mode switches to the kernel mode; Generate system call instruction execution parameters corresponding to the current processor architecture based on the system call context, and provide the execution parameters to the system call instruction.

[0058] In some embodiments, before executing the svc system call instruction and triggering a switch from user mode to kernel mode, the system first performs context organization on the standard system call request.

[0059] Specifically, the programming interface layer reads the system call number from the standard system call request and determines the passing order of the corresponding call parameters based on the system call number. For example, when the current system call number corresponds to a file read operation, the file descriptor, data buffer address, and read length are sorted according to the corresponding calling convention; then, based on the current processor architecture, a correspondence is established between each call parameter and the target processor register, so that each call parameter has a definite register location.

[0060] After establishing the register mapping, the system organizes the system call number and each call parameter into a unified system call context according to the mapping. This system call context records the current system call number, the call parameters, and the register positions corresponding to each parameter. Subsequently, a consistency check is performed on the system call context to verify whether the system call number and the current call parameters belong to the same system call type, and to check whether the mapping between the call parameters and their corresponding register positions is consistent. For example, when the system call number corresponds to a file read operation, the system checks whether the number of parameters, the parameter arrangement, and the register positions corresponding to each parameter in the current context are consistent with the calling convention corresponding to the file read operation.

[0061] Once the system call number and call parameters pass the consistency check, the system fixes the system call context to the call context region corresponding to the current task. For example, if the current Linux application is executed by task A, the resulting system call context is written to the call context region corresponding to task A, maintaining the association between this context and task A. When a system call instruction is subsequently executed and a switch occurs from user mode to kernel mode, the kernel POSIX adaptation layer can obtain the system call number and call parameters corresponding to this system call based on the call context region corresponding to the current task.

[0062] After the system call context is fixed, the system generates system call instruction execution parameters based on the current processor architecture. For ARM / AArch64 processors, the system call number and call parameters are used to form the register parameters required for the svc instruction execution according to the aforementioned register correspondence, and these execution parameters are provided to the system call instruction. Subsequently, the svc instruction is executed, causing the processor to switch from user mode to kernel mode. The kernel POSIX adaptation layer reads the system call number and call parameters according to the call context region corresponding to the current task, and continues to perform subsequent system call parsing and kernel native service conversion processing.

[0063] As an example of the present invention, reference is made to Figure 2 As shown, step S4 in this example includes: Step S41: Receive standard system call requests sent by the programming interface layer through the POSIX adaptation layer in the real-time kernel layer of the monolithic kernel, and extract the system call number and call parameters corresponding to the standard system call request; Step S42: Determine the corresponding kernel service type based on the system call number, perform legality verification on the call parameters, and map the standard system call request that passes the verification to the corresponding kernel native service; Step S43: Based on the service call interface corresponding to the kernel native service, convert the standard system call request into a kernel native service call request, and forward the kernel native service call request to the real-time kernel core; Step S44: The real-time kernel core executes the kernel native service call request and feeds back the execution result to the programming interface layer in accordance with the return method corresponding to the standard system call request.

[0064] In some embodiments, taking an embedded real-time operating system with a monolithic kernel architecture as an example, the Linux application in the application layer calls the POSIX standard interface through the programming interface layer to form a standard system call request. After completing the system call context organization in user mode, it enters kernel mode through system call instructions. After entering kernel mode, the standard system call request is processed by the POSIX adaptation layer in the monolithic kernel real-time kernel layer.

[0065] Specifically, the POSIX adaptation layer receives standard system call requests sent by the programming interface layer and reads the system call number and corresponding call parameters from the current system call context. For example, when the current application performs a file read operation, after receiving the corresponding standard system call request, the POSIX adaptation layer reads the file read system call number and obtains call parameters such as the file descriptor, data buffer address, and read length.

[0066] Subsequently, the POSIX adaptation layer determines the kernel service type corresponding to the current request based on the read system call number. For example, if the system call number corresponds to a file read operation, the current request is identified as a file read service; if the system call number corresponds to a file open operation, it is identified as a file open service. After determining the kernel service type, the POSIX adaptation layer performs validity checks on the current call parameters, including checking whether the number of call parameters matches the system call type, and whether the resource identifiers corresponding to the call parameters can be processed according to the current system call type. After passing the checks, a mapping relationship is established between the standard system call request and the corresponding native kernel service.

[0067] After mapping is complete, the POSIX adaptation layer reads the service call interface of the corresponding kernel native service and reorganizes the standard system call request according to the service call interface. For example, for a file read request, the file descriptor, data buffer address, and read length in the standard POSIX interface are converted into service call parameters required by the real-time kernel file service interface, forming the corresponding kernel native service call request. Subsequently, the POSIX adaptation layer forwards the formed kernel native service call request to the real-time kernel core.

[0068] After receiving a request to invoke a kernel native service, the real-time kernel core invokes the corresponding kernel service to perform the processing based on the service type. For example, in a file reading scenario, the real-time kernel core locates the corresponding file object based on the file descriptor, performs the corresponding file reading operation, and writes the read data into the data buffer specified by the call parameters; in other system call scenarios, it performs the corresponding task management, memory management, or device access processing based on the corresponding kernel native service.

[0069] After the kernel native service completes its execution, the real-time kernel core obtains the corresponding execution result and organizes the return data according to the return method corresponding to the original standard system call request. For example, for a file read request, the actual length of the data read is used as the return result; if resources are unavailable or parameters are abnormal during execution, a corresponding error return status is generated. Subsequently, the execution result is returned to the POSIX adaptation layer according to the kernel native service call path. The POSIX adaptation layer converts the result according to the return convention of the standard system call and feeds it back to the programming interface layer through the return path between user space and kernel space. Finally, the standard C runtime library delivers the return result to the Linux application that initiated the request.

[0070] Preferably, fixing the system call context that has passed the consistency check to the call context area corresponding to the current task specifically involves: Obtain the system call number and call parameters from the system call context that has passed the consistency check, and determine the system call parameter passing rules corresponding to the current processor architecture; According to the system call parameter passing rules, determine the system call number and the target register corresponding to each call parameter, and establish the mapping relationship between the system call number, call parameters and target register; Based on the mapping relationship, the system call number and call parameters are loaded into the target register corresponding to the current task in sequence, so that the system call number and the corresponding call parameters form a fixed register combination; While keeping the register combination unchanged, the current task is switched to the system call instruction execution state so that when switching from user mode to kernel mode, the kernel can identify the corresponding system call and its call parameters based on the register combination.

[0071] In some embodiments, before executing a system call instruction, the system performs a fixed process on the system call context that has passed the consistency check. Specifically, the system first reads the system call number and call parameters from the system call context that has passed the consistency check, and obtains the system call parameter passing rules for the current processor. For example, when the current system call request is a file read request, the system reads the corresponding system call number, file descriptor, data buffer address, and read length, and determines the passing position of each parameter according to the system call parameter passing rules corresponding to the ARM / AArch64 processor.

[0072] Subsequently, the system establishes a mapping relationship between the system call number, call parameters, and target register according to the parameter passing rules. For example, the system call number is mapped to the target register used to pass the system call number, and the file descriptor, data buffer address, and read length are mapped to the corresponding parameter registers, thereby forming a fixed set of register correspondences.

[0073] After establishing the mapping relationship, the system loads the system call number and each call parameter into the target register corresponding to the current task in sequence according to the mapping relationship. For example, if the current task A is performing the file read operation, the system call number corresponding to this file read is written to the system call number register corresponding to task A, the file descriptor is written to the first parameter register, the data buffer address is written to the second parameter register, and the read length is written to the third parameter register, so that this system call forms a fixed register combination.

[0074] After the register loading is complete, the system maintains the above register combination unchanged and switches the current task A to the system call instruction execution state. In this state, task A does not execute other user-mode call operations that would change the contents of the target registers, but instead directly executes the corresponding system call instruction according to the current register combination.

[0075] Subsequently, the processor executes the system call instruction and triggers a switch from user mode to kernel mode. Upon entering kernel mode, the POSIX adaptation layer in the monolithic kernel's real-time kernel layer reads the system call number and the corresponding call parameters in the registers, and identifies the current request based on the system call number. For example, after reading the system call number corresponding to file read, it simultaneously retrieves the file descriptor, data buffer address, and read length from the corresponding parameter register, thereby reconstructing the complete call relationship corresponding to this system call, and further performing subsequent parameter verification and kernel native service conversion.

[0076] Of particular importance, step S24 also includes: The user-space virtual file system mount relationship is established through the kernel virtual file system interface, and the directory nodes corresponding to the process information virtual file system, device file virtual file system and system information virtual file system are determined respectively. The process information virtual file system, device file virtual file system, and system information virtual file system are mounted to the corresponding directory nodes, and the association between each directory node and the corresponding status information of the monolithic kernel real-time kernel layer is established. Based on the association relationship, the execution state node mirror mapping converts the process state, device state, and system resource state in the real-time kernel layer of the monolithic kernel into virtual file information under the corresponding directory node, and establishes a mapping between virtual files and kernel state according to the corresponding state type. When user space accesses a virtual file through the corresponding directory node, it obtains the real-time status information corresponding to the real-time kernel layer of the monolithic kernel based on the mapping and returns it to user space.

[0077] In some embodiments, taking an embedded real-time operating system with a monolithic kernel architecture as an example, after system startup, the system interface layer has already established three user-space directory nodes: / proc, / dev, and / sys. The system establishes the mount relationships between these three virtual file systems and their corresponding directory nodes through the VFS virtual file system interface in the monolithic kernel's real-time kernel layer. The process information virtual file system corresponds to / proc, the device file virtual file system corresponds to / dev, and the system information virtual file system corresponds to / sys. Procfs, devfs, and sysfs are all implemented based on the kernel's standard VFS interface and are mounted to the / proc, / dev, and / sys directory nodes, respectively.

[0078] After mounting is complete, the system establishes associations between each directory node and the corresponding status information of the real-time kernel layer of the monolithic kernel. Specifically, task control information, task running status, and scheduling-related information in the real-time kernel are associated with the corresponding process information node under / proc; hardware devices and device status identified by the real-time kernel are associated with the corresponding device nodes under / dev; and system bus, device attributes, driver status, and system resource information are associated with the corresponding system information node under / sys.

[0079] After establishing the above associations, VFS performs state node mirroring based on the node type of each virtual file system. For process information nodes, the process states in the real-time kernel layer of the monolithic kernel are converted into virtual file information according to the node structure corresponding to the process information virtual file system; for device nodes, device states are converted into corresponding device file information; and for system information nodes, system resource states are converted into corresponding system information file content. Subsequently, a mapping relationship between virtual files and corresponding kernel states is established, so that the virtual file content corresponds to the specific state information in the real-time kernel. The three types of pseudo-file systems dynamically map kernel data structures in memory to expose and update kernel information, device states, and process resources in real time.

[0080] For example, when task A is running in a real-time operating system, the monolithic kernel's real-time kernel layer records the running status of task A and its corresponding scheduling information. The system associates this status with the virtual file node corresponding to task A under / proc. When user space executes a process query operation via the command line and accesses this node, VFS locates the kernel status corresponding to task A based on the established node mapping relationship, reads the current task status from the monolithic kernel's real-time kernel layer, organizes the read status information into the corresponding virtual file content, and returns it to user space.

[0081] Similarly, when user space accesses a device node through the / dev directory, VFS obtains the real-time status information of the corresponding device based on the mapping relationship between the device node and the kernel device status; when user space accesses the system information node under the / sys directory, it reads the system resources, device attributes or driver status information in the real-time kernel layer of the monolithic kernel according to the mapping relationship corresponding to the node, and returns the corresponding information to user space.

[0082] Most importantly, when user space accesses a virtual file through the corresponding directory node, it retrieves the real-time state information corresponding to the real-time kernel layer of the monolithic kernel based on the mapping and returns it to user space. Specifically: Receive user-space access requests for virtual files under a directory node, and determine the corresponding status type based on the accessed directory node and virtual file identifier; Based on the state type, call the monolithic kernel state acquisition interface corresponding to that state type to read the process state, device state, or system resource state corresponding to the current moment from the real-time kernel layer of the monolithic kernel. The read kernel state is reconstructed according to the mapping relationship between virtual files and kernel state, and the real-time state items in the kernel state are reorganized into the Linux file information of the corresponding virtual files. Based on the file access location in the user-mode access request, the corresponding content is extracted from the reconstructed Linux file information and returned to user mode through the kernel virtual file system interface.

[0083] In some embodiments, taking an embedded real-time operating system with a monolithic kernel architecture as an example, when user space accesses system resources through virtual files in the / proc, / dev, or / sys directories, the kernel virtual file system interface first receives the corresponding file access request. The system determines the status type of the current access based on the directory node actually accessed by user space and the virtual file identifier. For example, when accessing a process information file under / proc, the current request is determined to be a process status access; when accessing a device node under / dev, the current request is determined to be a device status access; and when accessing a system information file under / sys, it is determined to be a system resource status access.

[0084] After determining the state type, VFS calls the corresponding monolithic kernel state acquisition interface based on the state type to read the current state information from the real-time kernel layer of the monolithic kernel. For example, for process state access, it reads the running status, scheduling status, and related process information of the corresponding task from the real-time kernel; for device state access, it reads the current device status of the corresponding device; and for system resource state access, it reads the resource status information corresponding to the current system.

[0085] After reading the state information from the real-time kernel layer of the monolithic kernel, the VFS reconstructs the state nodes according to the established mapping relationship between virtual files and kernel states. For example, when a user accesses a virtual file corresponding to a process under / proc, the task state information of that process in the real-time kernel is rearranged according to the information organization method specified by the virtual file to form the corresponding Linux file information; for virtual files under / dev and / sys, the read state content is organized according to the node structure corresponding to device information and system information, respectively.

[0086] Subsequently, the system reads the file access location from the user-space access request. For example, when a user-space request reads a specified offset position and length of a virtual file, the VFS determines the corresponding data content in the reconstructed Linux file information based on the file access position and extracts a data segment that matches the access length.

[0087] Finally, VFS organizes the extracted data according to the return method corresponding to the user-space file access interface and returns it to user space through the kernel virtual file system interface. Upon receiving the returned content, user space processes it as the result of reading the corresponding Linux virtual file. Thus, user space accesses standard Linux file nodes, while the actual returned content comes from the real-time state information of the monolithic kernel's real-time kernel layer.

[0088] This invention provides a Linux ecosystem-compatible real-time operating system based on layered decoupling, used to execute the Linux ecosystem-compatible real-time operation method based on layered decoupling as described above. The Linux ecosystem-compatible real-time operating system based on layered decoupling includes: The architecture layering module is used to divide the real-time operating system into user mode and kernel mode. The user mode includes the application layer, system interface layer and programming interface layer from top to bottom, while the kernel mode includes the monolithic kernel and real-time kernel layer. The environment building module is used to provide a Linux build toolchain at the application layer, establish an embedded Linux basic toolset initialization environment and command-line interactive environment at the system interface layer, and mount process information virtual file system, device file virtual file system and system information virtual file system; The encapsulation module is used to call the POSIX PSE54 standard interface provided by the standard C language runtime library through the programming interface layer, and to encapsulate the system requests generated by the application layer and the system interface layer into standard system call requests. The call adaptation module is used to receive and verify standard system call requests based on the POSIX adaptation layer in the real-time kernel layer of the monolithic kernel, convert the verified requests into corresponding kernel native service calls, and execute them by the real-time kernel. The file adaptation module is used to uniformly adapt the Linux file system through the VFS virtual file system layer, enabling user space to access kernel resources through standard system call requests, and real-time scheduling is performed by the monolithic kernel real-time kernel layer.

[0089] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0090] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. A Linux ecosystem-compatible real-time operation method based on layered decoupling, characterized in that, Includes the following steps: Step S1: Divide the real-time operating system into user mode and kernel mode. The user mode includes the application layer, system interface layer and programming interface layer from top to bottom. The kernel mode includes the monolithic kernel and real-time kernel layer. Step S2: Provide a Linux build toolchain at the application layer, establish an embedded Linux basic toolset initialization environment and command-line interactive environment at the system interface layer, and mount the process information virtual file system, device file virtual file system and system information virtual file system; Step S3: By calling the POSIX PSE54 standard interface provided by the standard C language runtime library through the programming interface layer, the system requests generated by the application layer and the system interface layer are encapsulated into standard system call requests; Step S4: The POSIX adaptation layer in the real-time kernel layer of the monolithic kernel receives and verifies standard system call requests, converts the verified requests into corresponding kernel native service calls, and executes them by the real-time kernel. Step S5: The Linux file system is uniformly adapted through the VFS virtual file system layer, enabling user space to access kernel resources through standard system call requests, and real-time scheduling is performed by the monolithic kernel real-time kernel layer.

2. The Linux ecosystem-compatible real-time operation method based on layered decoupling according to claim 1, characterized in that, Step S1, which divides the real-time operating system into user mode and kernel mode, specifically involves: Based on the runtime environment of a real-time operating system, it is divided into user mode and kernel mode. The user space is divided into the application layer, system interface layer and programming interface layer according to the function call layer, and the application layer, system interface layer and programming interface layer are configured to call downwards in sequence; Configure the kernel mode as a monolithic kernel real-time kernel layer, and configure the kernel POSIX adaptation layer and VFS virtual file system layer in the monolithic kernel real-time kernel layer; Establish a system call channel between the programming interface layer and the kernel POSIX adaptation layer, so that kernel service requests generated by the application layer and the system interface layer can be passed to the kernel POSIX adaptation layer through the programming interface layer.

3. The Linux ecosystem-compatible real-time operation method based on layered decoupling according to claim 1, characterized in that, Step S2 includes the following steps: Step S21: Configure the Linux build toolchain at the application layer, and establish the compilation, building, and linking environment corresponding to the application based on the Linux build toolchain; Step S22: Start the embedded Linux basic toolset initialization program at the system interface layer. The initialization program completes the initialization of the user space basic environment and establishes the system directory and device nodes. Step S23: After the user space basic environment is initialized, start the command line interactive environment so that the system interface layer can receive system operation instructions and call the corresponding system functions through the command line; Step S24: Based on the kernel virtual file system interface, establish the mount relationships between the process information virtual file system, the device file virtual file system, and the system information virtual file system and their corresponding directory nodes, and map the process status, device status, and system resource information to their corresponding directory nodes.

4. The Linux ecosystem-compatible real-time operation method based on layered decoupling according to claim 3, characterized in that, Step S21 includes: Configure a self-developed Linux cross-compilation toolchain and corresponding compilation and build framework at the application layer, and establish a source code compilation environment for Linux applications based on the compilation and build framework; For each Linux open-source component to be ported, a corresponding build recipe description file is created, and the component source code verification information, toolchain dependencies, root file system dependencies, and patch file information are configured in the build recipe description file; Based on the build recipe description file, the corresponding configuration, compilation and installation processing interfaces of the compilation and build framework are called to sequentially perform build configuration, source code compilation and installation processing on Linux open source components to generate the corresponding software packages; The generated software packages are automatically integrated into the system root file system according to the root file system dependencies, forming a Linux application that can be run directly.

5. The Linux ecosystem-compatible real-time operation method based on layered decoupling according to claim 4, characterized in that, The configuration methods for the self-developed Linux cross-compilation toolchain and corresponding compilation and build framework include: Create a build recipe for the Linux application to be built, and record the toolchain dependency information used to complete the application compilation and the root file system dependency information used to run the application. The application configuration and compilation are completed by calling the corresponding Linux build toolchain based on the toolchain dependency information, and the runtime components corresponding to the compilation artifacts are determined based on the root file system dependency information. During the application installation process, the compiled artifacts are associated with the identified runtime components according to the corresponding root file system directory relationships, and an application package is generated. Based on the root file system dependency information, the application package and its corresponding runtime components are synchronously integrated into the system root file system, so that the application's compilation dependencies and runtime dependencies are matched during the build phase.

6. The Linux ecosystem-compatible real-time operation method based on layered decoupling according to claim 1, characterized in that, Step S3 encapsulates the system requests generated by the application layer and system interface layer into standard system call requests, including: The programming interface layer receives system requests generated by the application layer and the system interface layer, and determines the system call type based on the POSIX interface corresponding to the system request. The standard C runtime library is invoked to validate the parameters of the system request and determine the corresponding standard system call number according to the target system call type; Based on the target processor architecture, the standard system call number and system call parameters are loaded into the corresponding processor register, and a standard system call request is constructed according to the system call instructions corresponding to the processor architecture. Executing a system call instruction triggers a switch from user mode to kernel mode, sending the standard system call request to the POSIX adaptation layer in kernel mode.

7. The Linux ecosystem-compatible real-time operation method based on layered decoupling according to claim 6, characterized in that, Before the execution of a system call instruction triggers the switch from user mode to kernel mode, the following steps are also included: The order in which the call parameters are passed is determined based on the system call number corresponding to the standard system call request, and the correspondence between the system call parameters and the target register is established according to the current processor architecture. The system call number and call parameters are formed into a unified system call context according to the correspondence, and the consistency between the system call number and the call parameters in the system call context is verified. The system call context that passes the consistency check is fixed to the call context area corresponding to the current task, so that the system call request initiated by the user mode maintains the correspondence between the system call number and the call parameters after the user mode switches to the kernel mode; Generate system call instruction execution parameters corresponding to the current processor architecture based on the system call context, and provide the execution parameters to the system call instruction.

8. The Linux ecosystem-compatible real-time operation method based on layered decoupling according to claim 1, characterized in that, Step S4 includes the following steps: Step S41: Receive standard system call requests sent by the programming interface layer through the POSIX adaptation layer in the real-time kernel layer of the monolithic kernel, and extract the system call number and call parameters corresponding to the standard system call request; Step S42: Determine the corresponding kernel service type based on the system call number, perform legality verification on the call parameters, and map the standard system call request that passes the verification to the corresponding kernel native service; Step S43: Based on the service call interface corresponding to the kernel native service, convert the standard system call request into a kernel native service call request, and forward the kernel native service call request to the real-time kernel core; Step S44: The real-time kernel core executes the kernel native service call request and feeds back the execution result to the programming interface layer in accordance with the return method corresponding to the standard system call request.

9. The Linux ecosystem-compatible real-time operation method based on layered decoupling according to claim 7, characterized in that, Specifically, fixing the system call context that passes the consistency check to the call context region corresponding to the current task is as follows: Obtain the system call number and call parameters from the system call context that has passed the consistency check, and determine the system call parameter passing rules corresponding to the current processor architecture; According to the system call parameter passing rules, determine the system call number and the target register corresponding to each call parameter, and establish the mapping relationship between the system call number, call parameters and target register; Based on the mapping relationship, the system call number and call parameters are loaded into the target register corresponding to the current task in sequence, so that the system call number and the corresponding call parameters form a fixed register combination; While keeping the register combination unchanged, the current task is switched to the system call instruction execution state so that when switching from user mode to kernel mode, the kernel can identify the corresponding system call and its call parameters based on the register combination.

10. A Linux ecosystem-compatible real-time operating system based on layered decoupling, characterized in that, For executing the Linux ecosystem-compatible real-time operating method based on layered decoupling as described in claim 1, the Linux ecosystem-compatible real-time operating system based on layered decoupling includes: The architecture layering module is used to divide the real-time operating system into user mode and kernel mode. The user mode includes the application layer, system interface layer and programming interface layer from top to bottom, while the kernel mode includes the monolithic kernel and real-time kernel layer. The environment building module is used to provide a Linux build toolchain at the application layer, establish an embedded Linux basic toolset initialization environment and command-line interactive environment at the system interface layer, and mount process information virtual file system, device file virtual file system and system information virtual file system; The encapsulation module is used to call the POSIX PSE54 standard interface provided by the standard C language runtime library through the programming interface layer, and to encapsulate the system requests generated by the application layer and the system interface layer into standard system call requests. The call adaptation module is used to receive and verify standard system call requests based on the POSIX adaptation layer in the real-time kernel layer of the monolithic kernel, convert the verified requests into corresponding kernel native service calls, and execute them by the real-time kernel. The file adaptation module is used to uniformly adapt the Linux file system through the VFS virtual file system layer, enabling user space to access kernel resources through standard system call requests, and real-time scheduling is performed by the monolithic kernel real-time kernel layer.

Images