Design method and device for stateless ubiquitous operating system supporting decoupling service

Abstract

The invention discloses a method and a device for designing a stateless ubiquitous operating system supporting a decoupling service. The device comprises a hardware layer, a macro-kernel base layer, a platform abstraction layer and a LibOS user process layer, by designing a decentralized process state, the state of a user process in a computer system is separated from a system kernel, and system service is decoupled into the user process to obtain a decoupled user process, so that the degree of dependence of the user process on a host system is reduced; a stateless cross-device migration method is designed, and the decoupled user processes are efficiently migrated on different heterogeneous hardware platforms, so that the system service has continuity; and realizing heterogeneous resource integration and resource optimization of a computer system through a dynamic service and resource management method of a hardware resource list for heterogeneous device collaboration and process seamless migration.

Description

Technical Field

[0001] This invention provides a ubiquitous operating system design method, specifically relating to a stateless ubiquitous operating system design method and apparatus that supports decoupled services. It adopts a service decoupling mechanism to design and implement a stateless operating system (UOS) that enables seamless migration across devices, belonging to the field of computer operating system technology. Background Technology

[0002] Ubiquitous computing advocates for the widespread embedding of computing power into various devices and environments. Through heterogeneous resource collaboration and data interaction analysis, it aims to build "intelligent environments" and extend human perception and decision-making capabilities. As the core supporting software for ubiquitous computing scenarios, the Ubiquitous Operating System (UOS) needs to achieve core functions such as heterogeneous resource integration, flexible application deployment, and cross-device task migration to meet the resource optimization and service continuity requirements in scenarios such as industrial production and intelligent collaboration.

[0003] As a crucial software layer connecting underlying heterogeneous resources with upper-layer ubiquitous applications, the core requirement of a ubiquitous operating system is to solve the problems of unified management of massive heterogeneous resources and dynamic application adaptation. However, existing operating system architectures face significant technical bottlenecks when adapting to ubiquitous computing scenarios: Existing operating systems (including monolithic kernels, microkernels, and exogenous kernel architectures) generally suffer from the problem of coupling resources and service states. Core states related to processes (such as open file tables, memory mapping information, system service metadata, etc.) are all centrally stored in the kernel space. This causes processes to need to restore the context through state replay and full data synchronization when migrating across devices. This not only results in low migration efficiency but also easily leads to problems such as state inconsistency and migration failure, failing to meet the core requirement of "seamless migration" in ubiquitous scenarios.

[0004] System services (such as khugepaged, ksmd, and audit) are often deployed as globally independent processes, requiring simultaneous service provision to all processes, creating a bottleneck in centralized architecture. On one hand, resource isolation is difficult; abnormal requests from a single process may consume global resources, triggering PADoS (Performance Attacks of Service) attacks, leading to increased service latency and prolonged long-tail wait times. On the other hand, centralized state management limits system scalability; for example, centralized audit services cannot migrate with applications, causing audit data fragmentation, and log processing efficiency decreases significantly with the increase in the number of devices.

[0005] The hardware architectures (x86, ARM, etc.) and host kernels (Linux, Windows, embedded dedicated kernels, etc.) of different devices are fundamentally different, and existing operating systems lack a unified adaptation mechanism, resulting in strong binding between applications and underlying platforms. When processes migrate between heterogeneous devices, secondary development and adaptation are required for different platforms, making it impossible to achieve the ubiquitous computing goal of "deploy once, run on multiple devices".

[0006] Existing operating system kernel architectures have inherent flaws, including: monolithic kernels concentrate all capabilities in the kernel space, offering significant performance advantages but poor scalability; microkernels provide kernel capabilities through independent processes, relying on IPC (inter-process communication) to implement function calls, offering good component isolation but high communication overhead, making it difficult to balance performance and scalability; exogenous kernels only provide abstract hardware interfaces, with core functions offloaded to LibOS (library operating system), but suffer from problems such as inconsistent interface standards, complex resource management, and difficulties in IPC coordination, all of which cannot directly meet the comprehensive requirements of ubiquitous operating systems.

[0007] In summary, existing operating systems suffer from problems such as state coupling, insufficient scalability, and poor heterogeneous compatibility, making it difficult to meet the core requirements of "seamless migration, high scalability, and heterogeneous collaboration" for operating systems in ubiquitous computing scenarios. They also struggle to achieve seamless migration of computing tasks between different hardware devices, resulting in low scalability and flexibility in the utilization of system hardware resources, and thus failing to meet the dynamic and ever-changing needs of ubiquitous applications. Summary of the Invention

[0008] To overcome the shortcomings of the existing technology, this invention provides a stateless ubiquitous operating system design method and apparatus that employs decoupled services. This method is implemented on a computer hardware platform including processors, memory, storage devices, and peripheral interfaces. By designing a stateless ubiquitous operating system that supports decoupled services, it solves the management problem of massive heterogeneous hardware resources in ubiquitous computing systems / scenarios, breaks the coupling relationship between process and kernel states in memory and storage, enables seamless migration of tasks between different hardware devices, and improves the scalability and flexibility of the system in hardware resource utilization to adapt to the dynamic and ever-changing ubiquitous application requirements.

[0009] To achieve the above objectives, this invention proposes a stateless ubiquitous operating system design method that supports decoupled services, comprising the following three parts: A: Supports a decentralized process state design that decouples services; A1. Decouple and encapsulate system services, break down a single service process (user process) into multiple fragments, and strongly bind each fragment to a process (user process); A2. Decentralized management of process state: The system kernel core state required for process operation is unloaded from the kernel space to the process and maintained independently within the process as an operating system module of the LibOS library. The system kernel does not store any process-related state, thus achieving stateless process operation. A3. Based on the decoupling and encapsulation of A1 services and the decentralization of A2 process states, a hybrid kernel architecture is constructed using a monolithic kernel base layer + LibOS library operating system process layer: The monolithic kernel base layer retains core basic capabilities, including basic inter-process communication (IPC), I / O interfaces, and schedulers, maintaining high performance in underlying resource scheduling and communication. The LibOS library operating system process layer contains user processes after service decoupling. These user processes exist in the form of LibOS and contain not only LibOS's memory management module and device driver module, but also decoupled system service fragments. B: Stateless cross-device migration and unified adaptation design for heterogeneous hardware platforms; B1. Design a stateless migration mechanism: When migrating a process, only the process code, LibOS module and its own service status data need to be packaged and transmitted. There is no need to synchronize the global state in the kernel. After receiving the process, the target device of the migration can directly resume running through the LibOS module, thus achieving seamless migration. B2. Establish a platform abstraction adaptation layer to shield the differences between the upper and lower layers in the hybrid kernel: Add a platform abstraction layer between the LibOS process layer (or LibOS user process layer) and the monolithic kernel base layer, define a unified interface, including kernel communication, resource invocation and service registration, and shield the differences between the monolithic kernel base layer and hardware architecture; achieve heterogeneous device compatibility through the platform abstraction adaptation layer; C: Design combining dynamic services and resource management with hardware resource lists; C1. Design a dynamic service management mechanism: Support dynamic loading and unloading of system services. Adopt the sidecar functional mode, which can dynamically load the required services (such as auditing and performance monitoring) from the file system or image repository for the process according to the application requirements, or unload idle services to realize modular management of services.

[0010] C2. Dynamic adjustment of resource management list: When the system adds heterogeneous resources or uninstalls existing resources, the resource management set is updated through driver instrumentation and uninstallation. The LibOS process layer perceives resource changes through the unified interface of the platform abstraction layer and adjusts the binding relationship between services and resources synchronously without refactoring the core code.

[0011] This invention also provides a stateless ubiquitous operating system device that supports decoupled services. This device is deployed on a computer hardware platform including at least one processor, memory, storage devices, and peripheral interfaces. During runtime, the processor executes the operating system kernel program and the library operating system LibOS program. The device includes at least the following hierarchical structure: The hardware layer provides physical resources such as CPU, memory, storage devices, and peripherals. The monolithic kernel base layer runs in processor privileged mode and is used to provide basic scheduling, basic inter-process communication, and input / output interfaces for the hardware layer; The platform abstraction layer, which runs in processor user mode or privileged mode, is used to provide a unified adaptation protocol and interface, converting calls initiated by LibOS into instructions executable by the host kernel. The LibOS process layer runs in processor user space, providing memory management, device drivers, file systems, inter-application communication and dynamic sideloading service modules for each process, and maintaining state data related to the process. The application layer runs on top of LibOS, accessing hardware resources and binding services through LibOS to implement specific business logic.

[0012] In summary, this invention first provides a decentralized process state design (A) to separate the state of each user process in a ubiquitous operating system from the ubiquitous operating system kernel (hereinafter referred to as the system kernel), and decouples ubiquitous operating system services (hereinafter referred to as system services) to user processes, resulting in decoupled user processes, thereby minimizing the dependence of user processes on the system kernel. Based on this, this invention provides a stateless cross-device migration (B) for efficiently migrating the aforementioned decoupled user processes across different heterogeneous hardware platforms, ensuring the continuity of system services and meeting the service continuity requirements in various scenarios such as industrial production and intelligent collaboration. Finally, through a dynamic service and resource management design of the hardware resource list (C), the invention realizes the functions of heterogeneous resource integration and resource optimization in the ubiquitous computing system.

[0013] Compared with the prior art, the beneficial technical effects of the present invention are as follows: This invention provides a stateless ubiquitous operating system design method and apparatus that supports decoupled services. By designing a stateless process that supports service decoupling and LibOS process binding, the kernel state and system service state of the process are migrated from the kernel space to the process and its LibOS. The monolithic kernel base layer no longer maintains high-level state information related to specific processes, fundamentally eliminating the dependency of process migration on kernel state replay. Furthermore, a platform abstraction layer is introduced between the monolithic kernel base layer and the LibOS process layer, using a unified interface to shield the differences between different CPU architectures and different host kernels, enabling applications and LibOS to be deployed "once" and migrated and run on multiple hardware platforms. Based on the above stateless hybrid architecture, a dynamic side-loading service and resource management list dynamic adjustment mechanism is introduced, allowing system services to be loaded or unloaded at the process level and automatically adjusting the service-resource binding relationship as hardware resources increase or decrease, thereby balancing high scalability and resource utilization efficiency. By organically combining service decoupling, process state decentralization, platform abstraction layer, and dynamic service management, this invention achieves seamless migration of processes across heterogeneous hardware devices and service continuity while ensuring high performance, which is different from the single improvement of traditional monolithic kernel, microkernel, or exogenous kernel architectures.

[0014] The stateless ubiquitous operating system design with decoupled services proposed in this invention can solve core problems such as state coupling, heterogeneous compatibility, and insufficient scalability in ubiquitous computing scenarios. Specific beneficial effects are as follows: 1. Achieve seamless migration: The stateless design of processes eliminates the kernel state synchronization dependency during migration. Migration only requires the transfer of the process itself and LibOS-related data, improving the migration success rate; 2. Enhanced System Scalability: The decentralized service architecture breaks through the bottleneck of centralization, supports the access of massive heterogeneous devices and high-density service deployment, and can reduce the average service latency and long-tail latency. Dynamic service loading supports on-demand customization of application functions, and dynamic adjustments when resources change reduce the cost of system reconstruction. 3. Enhanced heterogeneous compatibility: The platform abstraction layer unifies the adaptation interface, achieving compatibility with different hardware architectures such as x86 and ARM, as well as multiple types of host kernels, enabling "deploy once, migrate to multiple devices" without secondary adaptation; 4. Optimize performance and resource consumption: Applications do not need to switch modes when accessing kernel capabilities and binding services. Combined with the high performance advantages of the monolithic kernel base layer, the overall performance is better than the traditional microkernel architecture. At the same time, dynamic service management reduces redundant resource consumption and improves the system's lightweight level. Attached Figure Description

[0015] Figure 1This is the overall architecture diagram of the present invention, which shows the four-level architecture of "hardware layer - monolithic kernel base layer - platform abstraction layer - LibOS user process layer" and the core components of each level.

[0016] Figure 2 This is a schematic diagram of the service decoupling and stateless migration process in the method of the present invention, which shows the complete process of process state management, migration data transmission, and target device recovery. Detailed Implementation

[0017] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0018] This invention provides a stateless ubiquitous operating system design method and apparatus that supports decoupled services, the technical solution of which includes: A. Supports decentralized process state design for service decoupling; A1. Decouple and encapsulate system services: Break down a single service process into multiple fragments and strongly bind each fragment to a user process: Specifically, the code logic and allocated computer hardware resources such as CPU resources, memory resources, and I / O resources of all system services (including but not limited to system auditing, network traffic monitoring, performance monitoring, distributed storage management, etc.) in the ubiquitous operating system are decomposed. This breaks the traditional global service model of the operating system and strongly binds system services to specific user processes (that is, the original system service is transformed from a single process into multiple code fragments, and each fragment is injected into the user process and written into the address space memory of the user process. The fragment is responsible for providing one-to-one service to the injected process). The decoupled service fragments are deployed as a whole in the user space by the injected process, rather than as independent processes, so that the system service is no longer an independent process.

[0019] A2. Decentralized process state management: The kernel state required for process operation (including file mapping information in the file system, memory management data in the memory management subsystem, etc.) is unloaded from the kernel space to the process and maintained independently in the process as an operating system module of the LibOS library. The system kernel does not store any process-related state, thus realizing stateless process operation.

[0020] A3. Hybrid kernel architecture construction: A complete hybrid kernel architecture is formed based on the decoupling and encapsulation of A1 services and the decentralization of A2 process states. This architecture includes a macro kernel base layer that does not record any process states in the decentralization of A2 process states, which is used to provide the most basic system kernel capabilities for the upper layers. This architecture also includes user processes that support the decoupling of services in the decoupling and encapsulation of A1 services. These user processes exist in the form of LibOS. In addition to the memory management, device driver and other modules common to LibOS, the user processes also contain decoupling system service fragments.

[0021] The hybrid kernel architecture adopts a hybrid architecture of "monolithic kernel base layer + LibOS library operating system process layer", which separates kernel capabilities and functional modules: the monolithic kernel base layer retains core basic capabilities, including basic inter-process communication (IPC), I / O interfaces, and schedulers, to maintain high performance in underlying resource scheduling and communication; in addition, the LibOS library operating system process layer integrates kernel capabilities such as memory management, device drivers, file system, and application inter-process communication (IPC) (i.e., the functional modules simplified in the monolithic kernel base layer), as well as the bound services split from A1, forming an integrated deployment with the process, so that applications do not need to trigger mode switching when accessing the above capabilities.

[0022] B. Stateless migration and unified adaptation design for heterogeneous hardware platforms ensure service continuity; In this invention, heterogeneous hardware platform refers to the lowest-level computer hardware platform, which includes hardware structures with different attributes, performance, and media. For example, x86 and ARM chips, GPUs and NPU chips from different manufacturers, and computer storage media of different natures can coexist.

[0023] B1. Stateless migration mechanism design: Based on A2's decentralized process state management, when migrating a process, only the process code, LibOS module and its own service state data need to be packaged and transmitted. There is no need to synchronize the global state in the kernel. After receiving the process, the target device can directly resume operation through the LibOS module to achieve seamless migration.

[0024] B2. A platform abstraction and adaptation layer is built to shield the differences between the upper and lower layers in a hybrid kernel: To support the migration and adaptation of the LibOS library operating system process layer across different hardware platforms to different underlying monolithic kernel base layers, this invention adds a platform abstraction layer between the LibOS process layer and the monolithic kernel base layer, defining a unified adaptation protocol and interface standard (hereinafter referred to as the unified interface) that covers core scenarios such as kernel communication, resource invocation, and service registration, while shielding the differences between different monolithic kernel base layers and hardware architectures.

[0025] Heterogeneous device compatibility is achieved through a platform abstraction adaptation layer: For different hardware architectures such as x86 and ARM, and for monolithic kernel base layers implemented based on different kernels such as Linux, Windows, and embedded kernels, a unified interface of the platform abstraction layer is used for matching. This allows processes to migrate and run across heterogeneous devices without modifying the application and LibOS core code. In specific implementation, protocol adaptation plugins are designed and deployed in the platform abstraction adaptation layer to achieve interface matching between LibOS modules and the system kernel.

[0026] C. Design of dynamic system services and hardware resource management that combine hardware resource lists; By adding dynamic management of system services and resources, it is possible to support the dynamic injection of system service fragments into or unloaded from user processes, and to enable LibOS to be aware of resource changes when hardware resources change dynamically.

[0027] C1. Design a dynamic service management mechanism: Support dynamic loading and unloading of system services. Adopt the sidecar functional mode, which can dynamically load the required services (such as auditing and performance monitoring) from the file system or image repository for the process according to the application requirements, or unload idle services to realize modular management of services.

[0028] C2. Dynamic adjustment of resource management list: When the system adds heterogeneous resources or uninstalls existing resources, the resource management set is updated through driver instrumentation and uninstallation. The LibOS process layer perceives resource changes through the unified interface of the platform abstraction layer and adjusts the binding relationship between services and resources synchronously without refactoring the core code.

[0029] Specific embodiments of the present invention include: (I) Overall Architecture Implementation The ubiquitous operating system of this invention adopts a four-level architecture (such as...). Figure 1 As shown in the diagram, from bottom to top, the layers are: hardware layer, monolithic kernel base layer, platform abstraction layer, and LibOS process layer. The implementation details of each layer are as follows: 1. Hardware Layer: This layer includes CPUs such as x86 or ARM architecture processors, random access memory (RAM), storage devices such as hard disks or solid-state drives (SSDs), and peripherals such as network interfaces and input / output devices. The hardware layer provides physical support for the system's computing, storage, and input / output functions.

[0030] 2. Monolithic Kernel Base Layer: This layer deploys a scheduler, basic inter-process communication modules, and input / output interface modules running in privileged mode on the processor. It manages and schedules CPU time slices, memory page frames, memory blocks, and peripheral interrupts in the hardware layer, performing basic task switching, message passing, and data transmission to ensure high performance and reliability of the underlying operations. In other words, this invention simplifies the existing Linux system kernel, retaining only the necessary modules (scheduler, IPC, IO) for deployment.

[0031] 3. Platform Abstraction Layer: Based on a unified interface, this layer implements heterogeneous kernel-compatible interfaces, standard resource call interfaces, and service registration interfaces on top of the monolithic kernel base layer. The platform abstraction layer translates system call requests from the LibOS process layer, converting them into call formats executable by the monolithic kernel base layer. This shields the differences between different CPU architectures, memory management mechanisms, and device drivers, achieving decoupling between upper-layer modules and the underlying hardware platform.

[0032] 4. LibOS User Process Layer: This layer deploys ubiquitous applications such as distributed shared storage applications, cross-device auditing applications, and network traffic analysis applications. These applications access underlying hardware resources and service modules through a unified interface provided by LibOS to implement specific business logic. Furthermore, each user process independently carries a LibOS module in its user-space address space. This LibOS module integrates memory management, device drivers, file systems, inter-process communication, and dynamically loaded system services (such as system auditing services and network monitoring services), and maintains state data related to the process in local memory (such as file mapping tables, memory allocation records, and service runtime parameters). LibOS manages the hardware resource usage of the process by executing corresponding programs on the processor, forming an integrated deployment with the process.

[0033] Furthermore, the application layer can deploy ubiquitous applications such as distributed shared storage applications, cross-device auditing applications, and network traffic analysis applications. These applications access underlying hardware resources and service modules by calling the unified interface provided by LibOS to implement specific business logic.

[0034] (II) Implementation of Service Decoupling and State Management First, the system services are decoupled (modularized). The global code corresponding to each system service is converted into several code snippets, each of which provides the code logic to execute a one-to-one service for the target user process. When the user process starts, each code snippet is dynamically injected into the target user process and loaded into the memory of the address space to which the user process belongs. It is then called by the user process, thus transforming the "global service" into a "one-to-one service".

[0035] When a process starts, the LibOS module automatically initializes the state storage area (memory / device, such as the process's private page table space) to store state data such as file mapping tables, memory allocation records, and service running parameters. State updates are synchronized in real time by the LibOS module. The system kernel does not need to store or maintain any user process state in memory, and the system kernel does not participate in the storage and maintenance of any user process state.

[0036] (III) Implementation of Platform Abstraction and Heterogeneous Compatibility The platform abstraction layer (PAL) establishes a unified adaptation protocol through clearly defined kernel communication formats, resource call parameters, and service registration procedures. It then develops and parses modules embedded within the PAL. For typical combinations such as x86 architecture-Linux kernel and ARM architecture-embedded kernel, corresponding protocol adaptation plugins are developed. These plugins are deployed in the PAL to achieve interface matching between LibOS modules and the host kernel. For example, when an ARM architecture device is connected, the adaptation plugin converts LibOS memory management requests into a calling specification supported by the embedded kernel, without requiring modification to the LibOS core code.

[0037] (iv) Implementation of dynamic services and resource management Dynamic sideloading requires the development of a service image repository to store various standardized service modules and provide service query, download, and installation interfaces. Applications call the load_service() interface, specifying the required service name and version. The LibOS module pulls the service image from the repository or file system, injects it into the process space, completes initialization, and establishes a binding relationship with the process.

[0038] When new hardware resources are added, causing changes to the resource list, the system automatically loads the corresponding driver. The driver registers resource information through the unified interface of the platform abstraction layer, and the LibOS module updates the local resource management list, synchronously adjusting the binding relationship between services and resources. When resources are unloaded, the driver triggers a resource deregistration notification, and the LibOS module removes the relevant resource records, releasing the resources occupied by idle services.

[0039] (v) Implementation of stateless migration When the system issues a migration command, the system executes it in the following order (e.g., ...). Figure 2 (as shown) 1. After the source device triggers the migration command, it packages the process code, its own core components, bound service modules, and status data into a standard image through the LibOS module, and transmits it to the target device through the network or mobile storage medium; 2. Based on a unified adaptation protocol, the platform abstraction layer of the target device verifies image compatibility, and the monolithic kernel base layer allocates hardware resources for the image; 3. The LibOS module of the target device automatically decompresses the image, restores the process state and service runtime environment, and the process can continue to run without state replay. The migration process is transparent to the application.

[0040] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A stateless pervasive operating system design method supporting decoupled service, characterized in that, Comprising the following steps: A. Designing a decentralized process state that supports service decoupling; A1. Decoupling and encapsulating system services, breaking a single service process into multiple segments, and strongly binding each segment to a user process; A2. Decentralized management of process state: offload the system kernel core state required for process running from the kernel space to the process interior, and maintain it independently in the form of a LibOS library operating system module inside the process. The system kernel does not store any process-related state, enabling stateless process running; A3. Based on A1 service decoupling and encapsulation and A2 process state decentralization, a hybrid kernel architecture is constructed using a macro kernel base layer and a LibOS library operating system process layer: The macro kernel base layer retains core basic capabilities, including basic inter-process communication (IPC), IO interface, and scheduler, maintaining high performance in underlying resource scheduling and communication. The LibOS library operating system process layer includes user processes after service decoupling. User processes exist in the form of LibOS, and in addition to memory management modules and device driver modules of LibOS, they also include decoupled system service segments; B. Designing a stateless cross-device migration method to efficiently migrate decoupled user processes across different heterogeneous hardware platforms, ensuring system service continuity; B1. Designing a stateless migration mechanism: during process migration, only process code, LibOS modules, and self-contained service state data need to be packaged and transmitted. The target device receives the process and directly resumes running through the LibOS module, achieving seamless migration; B2. Building a platform abstraction adaptation layer: a platform abstraction adaptation layer is added between the LibOS process layer and the macro kernel base layer to define a unified interface and mask differences in the macro kernel base layer and hardware architecture. Heterogeneous device compatibility is achieved through the platform abstraction adaptation layer; C. By adding dynamic management of system services and resources, the design supports dynamic injection of system service segments into user processes or unloading from user processes. LibOS is aware of dynamic changes in hardware resources, enabling dynamic integration and allocation of heterogeneous resources in computer systems and resource optimization.

2. The stateless ubiquitous operating system design method supporting decoupled service of claim 1, wherein, The strong binding in A1 is the injection of service segments into user processes after breaking them into multiple segments and writing them into the address space memory of the user process.

3. The stateless ubiquitous operating system design method supporting decoupled service of claim 2, wherein, In B2, the definition of a unified interface includes defining a unified adaptation protocol and interface standard, specifically including kernel communication, resource invocation, and service registration.

4. The stateless ubiquitous operating system design method for supporting decoupled service of claim 3, wherein, Heterogeneous device compatibility is achieved through the platform abstraction adaptation layer by designing protocol adaptation plugins, deploying them in the platform abstraction adaptation layer, matching LibOS modules with system kernel interfaces, and enabling process migration and running across heterogeneous devices without modifying application and LibOS core code.

5. The stateless ubiquitous operating system design method for supporting decoupled service of claim 4, wherein, In step C, dynamic service and resource management of the hardware resource list includes: C1. Design a dynamic service management mechanism to dynamically side-load and unload system services, dynamically load required services or unload idle services from the file system or image repository for processes, and realize modular management of system services; C2. Dynamically adjust the hardware resource management list: when the system adds heterogeneous resources or unloads the original resources, update the resource management set through the driver plug-in unloading method, and LibOS process layer perceives resource changes through the unified interface of the platform abstraction layer, synchronously adjusts the binding relationship between services and resources, and does not need to reconstruct the core code.

6. A stateless pervasive operating system device supporting decoupled services implemented by the method of claim 1. The system includes a hardware layer, a macro kernel basic layer, a platform abstraction layer, and a LibOS process layer, which are used for heterogeneous device collaboration and process seamless migration.

7. The stateless operating system apparatus for supporting decoupled services of claim 6, wherein, The hardware layer includes an x86 architecture processor or an ARM architecture processor CPU, random access memory, a disk or a solid state disk, and a network interface, an input / output device.

8. The stateless operating system apparatus for supporting decoupled services of claim 6, wherein, The macro kernel basic layer is used to deploy a scheduler, a basic inter-process communication module, and an input / output interface module running in a processor privileged state, which is used to manage and schedule CPU time slices, memory page frames, storage blocks, and peripheral interrupts in the hardware layer, and realize basic task switching, message passing, and data transmission.

9. The stateless operating system apparatus for supporting decoupled services of claim 8, wherein, The platform abstraction layer includes an implementation of a heterogeneous kernel compatible interface, a resource calling standard interface, and a service registration interface; it is used to translate system call requests from the LibOS process layer into executable call forms for the macro kernel basic layer, mask differences in different CPU architectures, memory management mechanisms, and device drivers, and realize decoupling of upper layer modules and underlying hardware platforms.

10. The stateless global operating system apparatus of claim 9, wherein the decoupled services are supported by the stateless global operating system apparatus. The LibOS process layer is used to deploy distributed shared storage applications, cross-device audit applications, and network traffic analysis applications; the LibOS process layer independently carries LibOS modules in the user mode address space, integrates memory management, device drivers, file systems, inter-process communication, and dynamically side-loadable system services, and maintains process-related state data in local memory; by executing LibOS corresponding programs on the processor, the hardware resource usage of the process is managed, and the process forms an integrated deployment; the deployed applications access underlying hardware resources and service modules through the unified interface provided by LibOS to realize corresponding applications.

Images