Operating system kernel design method and device and storage medium
By dynamically configuring the operating mode of the operating system kernel components and integrating the advantages of different kernel architectures, the problem of difficult to dynamically adjust and develop complexity in the existing technology is solved, and a better balance of performance and reliability and application code is achieved. portability.
Patent Information
- Application Number
- CN202411372831.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-29
- Publication Date
- 2025-02-11
- Estimated Expiration
- 2044-09-29
AI Technical Summary
The existing operating system kernel architecture has shortcomings in terms of security, performance and reliability, and is difficult to dynamically adjust to meet different application needs, and has low development complexity and application portability.
Dynamically select the operating state and operation mode of kernel components such as file system, network stack, device driver, etc. through user configuration, integrate the architectural advantages of macro kernel, micro kernel and external kernel to form an adaptive architecture to achieve performance and reliability improvement Good balance.
It realizes the support of multiple operating modes of kernel components, and applications do not need to perceive operating modes, which improves system universality and application code portability, and supports users to choose different architectures according to their intentions.
Smart Images

Figure CN119415160A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of computer operating systems, and in particular to an operating system kernel design method, device and storage medium. Background Art
[0002] The operating system is an important part of the computer system, managing hardware resources downward and serving user programs upward. The operating system kernel is the core component of the computer operating system, responsible for hardware resource management and supporting the application execution environment, including but not limited to task management, memory management, IPC management, device management, file system, network, inter-process communication and other functions. By providing a system call interface to the outside world, it supports user-mode programs to make reasonable use of underlying hardware resources. Existing operating systems are designed with operating system kernels of different architectures for different application scenarios to meet the different requirements of application scenarios for software attributes such as performance, reliability, and versatility. The traditional operating system kernel architecture mainly includes macro kernel, micro kernel, exo kernel\single kernel, hybrid kernel, etc. Different kernel architectures have different design concepts, which leads to different advantages and disadvantages.
[0003] The existing kernel architectures have their own characteristics in terms of security, performance, reliability, etc. Different applications are suitable for architectures with different characteristics, but there are still some shortcomings in the following aspects.
[0004] A single kernel requires the kernel architecture to be determined during compilation (and the operating mode to be determined at the same time), and cannot be dynamically adjusted according to application requirements during runtime, making it difficult to simultaneously meet the needs of multiple applications with different requirements and characteristics; a hybrid kernel supports the compilation and generation of multiple kernels (such as macOS\iOS kernels), requiring application developers to call different interfaces to select the kernel to be used, increasing the complexity of development and affecting the portability of the application; users cannot obtain control over the kernel architecture or take advantage of the architectural advantages, such as trusted applications can relax security requirements to improve performance, and untrusted applications can sacrifice performance to enhance security restrictions. Summary of the invention
[0005] In view of the above problems in the prior art, the present invention provides an operating system kernel design method, device and storage medium, which integrate the design of the existing operating system kernel architecture, dynamically select the component operation state and operation mode of kernel components such as file system, network stack, device driver, etc. through user configuration, integrate the architectural advantages of traditional macro kernel, micro kernel and exokernel, and dynamically configure the operation mode of application-dependent components for the specific needs of different user processes in the system, so as to form an adaptive architecture suitable for different demand characteristics and achieve a better balance between performance and reliability.
[0006] In one aspect, the present invention provides a method for designing an operating system kernel, the method being applied to an operating system, the method comprising:
[0007] Create kernel component management objects for each component through the kernel and execute corresponding kernel service threads;
[0008] In response to the kernel component management object receiving a request service sent by a component common process, the kernel component management object runs the component common process, wherein the component common process is used to implement the functions of each component after running, wherein one component corresponds to at least one common process, and one common process is at least a common process of one component;
[0009] In response to the user state running the component main process through the function call mode, the component main process is used to implement the function of the corresponding component through the function call mode in the user state, wherein a component has at most one component main process at the same time, each component main process creates a user service thread, the user service thread is used to monitor the request of other processes to access the component, and a component has at most one user service thread running at the same time;
[0010] A user service thread that runs the main process of the component.
[0011] Optionally, creating a kernel component management object for each component through the kernel and executing a corresponding kernel service thread includes:
[0012] Step 1: Create a kernel component management object for each component and create a corresponding kernel service thread through the kernel;
[0013] Step 2: Start the kernel service thread and set the component library to function call mode;
[0014] Step 3, checking the control queue of the kernel component management object to determine whether there is a request, if there is no request, executing step 4, otherwise executing step 7;
[0015] Step 4, checking the data queue of the kernel component management object to determine whether there is a request, if there is no request, executing step 5, otherwise executing step 6;
[0016] Step 5: In response to the fact that both the control queue and the data queue of the kernel component management object have no request, trigger the kernel service thread to abandon scheduling, and check the control queue and the data queue through processor scheduling, and in response to the existence of a request in any queue, resume the scheduling of the kernel service thread and execute step 3;
[0017] Step 6: Process the request using the function call mode. The request processing process includes responding to the data request and returning the result. After the response, the request sender can continue to run and execute step 3.
[0018] Step 7, the request that triggers the control queue becomes a preemption request, and the component cleanup operation is performed and then the preemption request is responded to, and the request sender can continue to run after the response;
[0019] Step eight, ending the kernel service thread.
[0020] Optionally, the kernel service threads created by the kernel include a file system service thread, a block device driver service thread, a network stack service thread, and a network device driver service thread.
[0021] In the embodiment of the present application, the kernel component refers to the file system, block device driver, network stack, network device driver, etc.
[0022] Optionally, in response to the kernel component management object receiving a request service sent by a component common process, running the component common process includes:
[0023] Step 9: Start at least one common process (there may be multiple processes running at the same time), and set the process access component mode to request service mode;
[0024] Step 10, executing the application code, accessing the component in the request service mode and sending a data request, and determining whether the ordinary process is finished after the request is finished, if not, continuing to execute step 10, otherwise, executing step 11;
[0025] Step 11, ending the normal process.
[0026] Optionally, the step of running the component main process in a function call mode in response to the user state includes:
[0027] Step 12, in response to the user state starting at least one component main process through the function call mode, issuing a preemption request and waiting for the request to be processed, setting the process access component mode to the function call mode, and creating and starting the user service thread;
[0028] Step 13, execute the application code to completion;
[0029] Step 14, sending an end request to the kernel component management object, wherein the end request is accompanied by the process number of the current process as an identifier, and waiting for the request processing to be completed;
[0030] Step 15, in response to the request processing being completed, waiting for the user service thread of the current process to end;
[0031] Step sixteen: in response to the termination of the user service thread, trigger the termination of the component main process.
[0032] Optionally, the user service thread running the main process of the component includes:
[0033] Step 17, starting the user service thread of the main process of the component;
[0034] Step 18, taking out requests from the control queue and the data queue in turn, waiting if there is no request, and determining the request type if there is a request, executing step 19 if it is a data request, executing step 20 if it is a preemption request, and executing step 21 if it is an end request;
[0035] Step 19, use the function call mode to process the request, respond to the data request and return the result, and execute step 18;
[0036] Step 20, execute component cleanup operation and set the mode of the current process accessing the component to request service, respond to the preemption request, and then the request sender can continue to run, and execute step 23;
[0037] Step 21, determine whether the process ID of the request is the same as the process ID of the current process, if so, execute step 22, otherwise do not execute the processing operation and respond to the end request, and continue to execute step 18;
[0038] Step 22, execute component cleanup operation, create and start kernel service thread, and execute step 23 in response to end request;
[0039] Step 23, end the user service thread.
[0040] Optionally, the method further includes:
[0041] Use POSIX interfaces to develop individual applications;
[0042] Design functional kernel component management objects in the kernel, wherein each component includes a kernel service thread, a user service thread, a control queue and a data queue, and the component method includes creating components, creating kernel service threads, creating user service threads, and adding, obtaining and responding operations of control queues and data queues;
[0043] Implement component libraries for each kernel component;
[0044] Configure the operation mode of each application-dependent kernel component according to the intention of the system end user.
[0045] On the other hand, there is also provided an operating system kernel design device, the device comprising:
[0046] The first design module is used to create a kernel component management object for each component through the kernel and execute a corresponding kernel service thread;
[0047] The second design module is used to respond to the kernel component management object receiving a request service sent by a component common process, and run the component common process, wherein the component common process is used to implement the functions of each component after running, wherein one component corresponds to at least one common process, and one common process is at least a common process of one component;
[0048] The third design module is used to respond to the user state running the component main process through the function call mode, the component main process is used to implement the function of the corresponding component through the function call mode in the user state, wherein a component has at most one component main process at the same time, each component main process creates a user service thread, the user service thread is used to monitor the request of other processes to access the component, and a component has at most one user service thread running at the same time;
[0049] The fourth design module is used to run the user service thread of the main process of the component.
[0050] The present invention has at least the following beneficial effects.
[0051] The operating system kernel architecture designed in the present application supports the coexistence of multiple operating modes of kernel components during compilation, and the operating modes of components do not affect each other. The component operating mode can be dynamically determined according to user configuration during runtime; the multiple operating modes of kernel components are directly reflected in the application, that is, the application does not need to be aware of the operating mode of its own operation, and application developers do not need to adapt the code, which improves the versatility of system usage scenarios and the portability of application code; it supports users to choose different architectures for different applications, and is an adaptive system kernel architecture that is sensitive to user intentions. BRIEF DESCRIPTION OF THE DRAWINGS
[0052] Figure 1 It is a schematic diagram of the overall architecture of the method of the embodiment of the present invention;
[0053] Figure 2 A schematic diagram of a kernel function kernel component management object design in an embodiment of the present invention;
[0054] Figure 3 A schematic diagram of a core component library design in an embodiment of the present invention;
[0055] Figure 4 This is a schematic diagram of the kernel service thread execution flow in an embodiment of the present invention;
[0056] Figure 5 This is a schematic diagram of a common process execution flow of a component in an embodiment of the present invention;
[0057] Figure 6 This is a schematic diagram of the main process execution flow of a component in an embodiment of the present invention;
[0058] Figure 7 The figure is a schematic diagram of the user service thread execution flow in an embodiment of the present invention. DETAILED DESCRIPTION
[0059] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below in conjunction with the accompanying drawings.
[0060] The term "multiple" as used herein refers to two or more than two. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the related objects are in an "or" relationship.
[0061] Example 1
[0062] The present invention provides an operating system kernel design method, which is applied to an operating system and includes the following contents.
[0063] Step 1: Create a kernel component management object for each component through the kernel and execute the corresponding kernel service thread.
[0064] Optionally, the kernel service threads created by the kernel include a file system service thread, a block device driver service thread, a network stack service thread, and a network device driver service thread.
[0065] In one example, the kernel creates a kernel component management object for each component and creates a kernel service thread, such as Figure 1 As shown in the figure, the kernel creates file system service threads, block device driver service threads, network stack service threads, network device driver service threads, character device driver service threads, etc. Taking the file system kernel service thread as an example, its implementation depends on Figure 3 The file system component library shown in the figure has a specific execution process as follows: Figure 4 shown.
[0066] In a possible implementation, step one includes steps one to eight.
[0067] Step 1: Create a kernel component management object for each component and create a corresponding kernel service thread through the kernel;
[0068] Step 2: Start the kernel service thread, set the component library to function call mode (i.e., implement fs_trait using the FsServer interface), and continue to step 3;
[0069] Step 3, checking the control queue of the kernel component management object to determine whether there is a request, if there is no request, executing step 4, otherwise executing step 7;
[0070] Step 4, checking the data queue of the kernel component management object to determine whether there is a request, if there is no request, executing step 5, otherwise executing step 6;
[0071] Step 5: In response to the fact that both the control queue and the data queue of the kernel component management object have no request, trigger the kernel service thread to abandon scheduling, and check the control queue and the data queue through processor scheduling, and in response to the existence of a request in any queue, resume the scheduling of the kernel service thread and execute step 3;
[0072] Step 6: Process the request using the function call mode. The request processing process includes responding to the data request and returning the result. After the response, the request sender can continue to run and execute step 3.
[0073] Step 7: The request that triggers the control queue becomes a preemption request (when the component main process exits, an end request is issued, which will only be responded to by the user service thread), and the component cleanup operation (such as file system sync) is performed and then the preemption request is responded to. After the response, the request sender can continue to run;
[0074] Step eight, ending the kernel service thread.
[0075] Step 2: In response to the kernel component management object receiving a request service sent by a component ordinary process, the component ordinary process is run, and the component ordinary process is used to implement the functions of each component after running, wherein one component corresponds to at least one ordinary process, and one ordinary process is at least the ordinary process of one component.
[0076] In one example, the component normal process implements component related functions by sending a request service to the kernel component management object. Figure 1 Process B is a common process of the file system component, and process C is a common process of the network stack component. A component may have multiple common processes at the same time, and a process may be a common process of multiple components. Taking the common process of the file system component as an example, its implementation depends on Figure 3 The file system component library shown in the figure, the execution flow of each process is as follows Figure 5 shown.
[0077] In a possible implementation manner, step 2 includes steps 9 to 11.
[0078] Step 9: Start at least one common process (there may be multiple processes running at the same time), and set the process access component mode to request service mode (i.e., use the FsClient interface to implement fs_trait);
[0079] Step ten, execute the application code, access the component in the request service mode and send a data request. After the request is completed, determine whether the ordinary process is completed. If not, continue to execute step ten, otherwise execute step eleven.
[0080] Step 11, ending the normal process.
[0081] Step three, in response to the user state running the component main process through the function call mode, the component main process is used to implement the function of the corresponding component through the function call mode in the user state, wherein a component has at most one component main process at the same time, each component main process creates a user service thread, the user service thread is used to listen to requests from other processes to access the component, and a component has at most one user service thread running at the same time.
[0082] In one example, the component main process directly implements the component function in the user state through the function call mode, such as Figure 1 Process A in the figure is the main process of the file system. A component can have at most one main process at a time. When a process is started as the main process of a component, if another process already exists as the main process, it can also preempt the main process. After the preemption, the old main process runs in the normal process mode. Taking the main process of the file system component as an example, its implementation depends on Figure 3 The file system component library shown in the figure has a main process execution flow as follows: Figure 6 shown.
[0083] In a possible implementation, step three includes steps twelve to sixteen.
[0084] Step 12, in response to the user state starting at least one component main process (there may be multiple running simultaneously) through the function call mode, a preemption request is issued and waits for the request to be processed, the process access component mode is set to the function call mode (i.e., fs_trait is implemented using the FsServer interface), and the user service thread is created and started.
[0085] Step 13: Execute the application code to completion.
[0086] In addition, in step thirteen, when executing the application code, it is also possible to determine whether the process has ended after completing the component access in the function call mode. If the loop has not ended, the function call is performed, and step fourteen is executed instead. In addition, in step thirteen, the application code is executed until the end, during which the process access component mode may be modified (by twenty) from the initial "function call" to "request service".
[0087] Among them, the function call mode and the request service mode are two types of process access component modes.
[0088] Step 14: Send an end request to the kernel component management object, wherein the end request is accompanied by the process number of the current process as an identifier, and wait for the request processing to be completed.
[0089] Step 15: in response to the request processing being completed, wait for the user service thread of the current process to end.
[0090] Step sixteen: in response to the termination of the user service thread, trigger the termination of the component main process.
[0091] Step 4: Run the user service thread of the component main process.
[0092] In one example, each component main process is responsible for creating a user service thread to listen to requests from other processes to access the component. A component can have at most one main process at a time, and at most one user service thread running at the same time. Taking the file system user service thread as an example, its implementation depends on Figure 3 The file system component library shown in the figure has a specific execution process as follows: Figure 7 shown.
[0093] In a possible implementation manner, step four includes steps seventeen to twenty-three.
[0094] Step 17, starting the user service thread of the main process of the component;
[0095] Step 18, taking out requests from the control queue and the data queue in turn, waiting if there is no request, and determining the request type if there is a request, executing step 19 if it is a data request, executing step 20 if it is a preemption request, and executing step 21 if it is an end request;
[0096] Step 19, use the function call mode to process the request, respond to the data request and return the result, and execute step 18;
[0097] Step 20, execute component cleanup operation (such as file system sync) and set the mode of the current process accessing the component to request service, respond to the preemption request, and then the request sender can continue to run, and execute step 23;
[0098] Step 21, determine whether the process number of the request is the same as the process number of the current process. If so, execute step 22. Otherwise, do not execute the processing operation and respond to the end request. This means that the process that issued the request is no longer the main process, so there is no need to process it. Directly respond to the end request (the request sender can continue to run) and continue to execute step 18;
[0099] Step 22, perform component cleanup operations (such as file system sync), create and start a kernel service thread, respond to the end request (after which the request sender can continue to run) and execute step 23;
[0100] Step 23, end the user service thread.
[0101] The present invention has at least the following beneficial effects.
[0102] The operating system kernel architecture designed in the present application supports the coexistence of multiple operating modes of kernel components during compilation, and the operating modes of components do not affect each other. The component operating mode can be dynamically determined according to user configuration during runtime; the multiple operating modes of kernel components are directly reflected in the application, that is, the application does not need to be aware of the operating mode of its own operation, and application developers do not need to adapt the code, which improves the versatility of system usage scenarios and the portability of application code; it supports users to choose different architectures for different applications, and is an adaptive system kernel architecture that is sensitive to user intentions.
[0103] Example 2
[0104] In addition, before the above kernel design method, a preparation stage is also included.
[0105] Preparation phase 1: Develop applications using POSIX interfaces.
[0106] Application developers use POSIX interfaces to develop applications (consistent with Linux-based application development). Figure 1 As shown in the upper left of , applications may depend on file system kernel components (such as application A and application B) and network stack kernel components (such as application C).
[0107] Preparation Phase 2: Design functional kernel component management objects in the kernel, where each component includes a kernel service thread, a user service thread, a control queue and a data queue. Component methods include creating components, creating kernel service threads, creating user service threads, and adding, obtaining, and responding to control queues and data queues.
[0108] The kernel is designed to manage objects of functional kernel components. Figure 2 As shown, the component members include a kernel service thread, a user service thread, a control queue (receiving two requests: preemption and termination), and a data queue (receiving data access requests); the component method includes creating a component, creating a kernel service thread, creating a user service thread, and adding, obtaining, and responding operations to the control queue and data queue.
[0109] Preparation phase 3: Implement component libraries for each kernel component.
[0110] Implement component libraries for each kernel component. Figure 3The design of the component library is demonstrated by taking the file system component and Rust language as examples. The core member fs_trait is a trait object type variable in the Rust language (similar to a virtual interface), which can be dynamically distributed to specific types. The type FsTrait of fs_trait includes the interface definition that the file system component needs to provide to the application, such as creating files, reading and writing files, synchronization, etc. FsServer and FsClient respectively implement the interface in FsTrait. FsServer implements the file system function through the function call mode, does not rely on the kernel, and can run in kernel mode or user mode; FsClient implements related functions by sending data access requests to the kernel file system kernel component, relies on the kernel, and can only run in user mode.
[0111] Preparation phase 4: Configure the operation mode of each application dependent on the kernel components according to the intention.
[0112] System end users configure the operation mode of application-dependent kernel components according to their intentions. Figure 1 As shown in the upper right corner of the figure, assuming that application A is performance-sensitive, the user can configure it as the main process of the file system; application B is a common process that depends on the file system; application C is a common process that depends on the network stack.
[0113] On the other hand, there is also provided an operating system kernel design device, the device comprising:
[0114] The first design module is used to create a kernel component management object for each component through the kernel and execute a corresponding kernel service thread;
[0115] The second design module is used to respond to the kernel component management object receiving a request service sent by a component common process, and run the component common process, wherein the component common process is used to implement the functions of each component after running, wherein one component corresponds to at least one common process, and one common process is at least a common process of one component;
[0116] The third design module is used to respond to the user state running the component main process through the function call mode, the component main process is used to implement the function of the corresponding component through the function call mode in the user state, wherein a component has at most one component main process at the same time, each component main process creates a user service thread, the user service thread is used to monitor the request of other processes to access the component, and a component has at most one user service thread running at the same time;
[0117] The fourth design module is used to run the user service thread of the main process of the component.
[0118] Optionally, the first design module is used to perform:
[0119] Step 1: Create a kernel component management object for each component and create a corresponding kernel service thread through the kernel;
[0120] Step 2: Start the kernel service thread and set the component library to function call mode;
[0121] Step 3, checking the control queue of the kernel component management object to determine whether there is a request, if there is no request, executing step 4, otherwise executing step 7;
[0122] Step 4, checking the data queue of the kernel component management object to determine whether there is a request, if there is no request, executing step 5, otherwise executing step 6;
[0123] Step 5: In response to the fact that both the control queue and the data queue of the kernel component management object have no request, trigger the kernel service thread to abandon scheduling, and check the control queue and the data queue through processor scheduling, and in response to the existence of a request in any queue, resume the scheduling of the kernel service thread and execute step 3;
[0124] Step 6: Process the request using the function call mode. The request processing process includes responding to the data request and returning the result. After the response, the request sender of the data queue can continue to run and execute step 3.
[0125] Step 7, triggering the request of the control queue to become a preemption request, and executing the component cleanup operation and then responding to the preemption request, after which the request sender of the control queue can continue to run;
[0126] Step eight, ending the kernel service thread.
[0127] Optionally, the second design module is used to perform:
[0128] Step 9, setting the process access component mode to request service mode;
[0129] Step 10, executing the application code, accessing the component in the request service mode and sending a data request, and determining whether the ordinary process is finished after the request is finished, if not, continuing to execute step 10, otherwise, executing step 11;
[0130] Step 11, ending the normal process.
[0131] Optionally, the third design module is used to perform:
[0132] Step 12, in response to the user state starting at least one component main process through the function call mode, issuing a preemption request and waiting for the request to be processed, setting the process access component mode to the function call mode, and creating and starting the user service thread;
[0133] Step 13, execute the application code to completion;
[0134] Step 14, sending an end request to the kernel component management object, wherein the end request is accompanied by the process number of the current process as an identifier, and waiting for the request processing to be completed;
[0135] Step 15, in response to the request processing being completed, waiting for the user service thread of the current process to end;
[0136] Step sixteen: in response to the termination of the user service thread, trigger the termination of the component main process.
[0137] Optionally, the fourth design module is used to perform:
[0138] Step 17, starting the user service thread of the main process of the component;
[0139] Step 18, taking out requests from the control queue and the data queue in turn, waiting if there is no request, and determining the request type if there is a request, executing step 19 if it is a data request, executing step 20 if it is a preemption request, and executing step 21 if it is an end request;
[0140] Step 19, use the function call mode to process the request, respond to the data request and return the result, and execute step 18;
[0141] Step 20, execute component cleanup operation and set the mode of the current process accessing the component to request service, respond to the preemption request, and then the request sender of the preemption request can continue to run, and execute step 23;
[0142] Step 21, determine whether the process ID of the request is the same as the process ID of the current process, if so, execute step 22, otherwise do not execute the processing operation and respond to the end request, and continue to execute step 18;
[0143] Step 22, execute component cleanup operation, create and start kernel service thread, and execute step 23 in response to end request;
[0144] Step 23, end the user service thread.
[0145] Optionally, the device further comprises:
[0146] Application usage module, used to develop various applications using POSIX interfaces;
[0147] The object management module is used to design kernel component management objects in the kernel, wherein each component includes a kernel service thread, a user service thread, a control queue and a data queue, and the component method includes creating component objects, creating kernel service threads, creating user service threads, and adding, obtaining and responding operations of control queues and data queues;
[0148] A component library management module, used to implement a component library for each kernel component;
[0149] The operation mode module is used to configure the operation mode of each application dependent on the kernel component according to the intention of the system terminal user.
[0150] The above is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions under the concept of the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technicians in this technical field, some improvements and modifications without departing from the principle of the present invention should also be regarded as the protection scope of the present invention.
Claims
1. A method for designing an operating system kernel, characterized in that: The method is applied to an operating system, and the method comprises: Create kernel component management objects for each component through the kernel and execute corresponding kernel service threads; In response to the running of the component ordinary process, the kernel component management object receives a request service sent by the component ordinary process, the component ordinary process is used to use the component in a manner of requesting services, a component has no ordinary process or corresponds to at least one ordinary process, and an ordinary process is at least an ordinary process of a component; In response to the user state running the component main process through the function call mode, the component main process is used to implement the function of the corresponding component through the function call mode in the user state, wherein a component has at most one component main process at the same time, each component main process creates a user service thread, the user service thread is used to monitor the request of other ordinary processes to access the component, and the main process component corresponds to one user service thread running at the same time; A user service thread that runs the main process of the component.
2. The method according to claim 1, characterized in that: The step of creating a kernel component management object for each component through the kernel and executing a corresponding kernel service thread includes: Step 1: Create a kernel component management object for each component and create a corresponding kernel service thread through the kernel; Step 2: Start the kernel service thread and set the component library to function call mode; Step 3, checking the control queue of the kernel component management object to determine whether there is a request, if there is no request, executing step 4, otherwise executing step 7; Step 4, checking the data queue of the kernel component management object to determine whether there is a request, if there is no request, executing step 5, otherwise executing step 6; Step 5: In response to the fact that both the control queue and the data queue of the kernel component management object have no request, trigger the kernel service thread to abandon scheduling, and check the control queue and the data queue through processor scheduling, and in response to the existence of a request in any queue, resume the scheduling of the kernel service thread and execute step 3; Step 6: Process the request using the function call mode. The request processing process includes responding to the data request and returning the result. After the response, the request sender of the data queue can continue to run and execute step 3. Step 7, triggering the request of the control queue to become a preemption request, and executing the component cleanup operation and then responding to the preemption request, after which the request sender of the control queue can continue to run; Step eight, ending the kernel service thread.
3. The method according to claim 1, characterized in that In response to the component common process running, the kernel component management object receives a request service sent by the component common process, including: Step 9, setting the process access component mode to request service mode; Step 10, executing the application code, accessing the component in the request service mode and sending a data request, and determining whether the ordinary process is finished after the request is finished, if not, continuing to execute step 10, otherwise, executing step 11; Step 11, ending the normal process.
4. The method according to claim 1, characterized in that: The step of responding to the user state running the component main process in a function call mode includes: Step 12, in response to the user state starting at least one component main process through the function call mode, issuing a preemption request and waiting for the request to be processed, setting the process access component mode to the function call mode, and creating and starting the user service thread; Step 13, execute the application code to completion; Step 14, sending an end request to the kernel component management object, wherein the end request is accompanied by the process number of the current process as an identifier, and waiting for the request processing to be completed; Step 15, in response to the request processing being completed, waiting for the user service thread of the current process to end; Step sixteen: in response to the termination of the user service thread, trigger the termination of the component main process.
5. The method according to claim 1, characterized in that: The user service thread running the main process of the component includes: Step 17, starting the user service thread of the main process of the component; Step 18, taking out requests from the control queue and the data queue in turn, waiting if there is no request, and determining the request type if there is a request, executing step 19 if it is a data request, executing step 20 if it is a preemption request, and executing step 21 if it is an end request; Step 19, use the function call mode to process the request, respond to the data request and return the result, and execute step 18; Step 20, execute component cleanup operation and set the mode of the current process accessing the component to request service, respond to the preemption request, and then the request sender of the preemption request can continue to run, and execute step 23; Step 21, determine whether the process ID of the request is the same as the process ID of the current process, if so, execute step 22, otherwise do not execute the processing operation and respond to the end request, and continue to execute step 18; Step 22, execute component cleanup operation, create and start kernel service thread, and execute step 23 in response to end request; Step 23, end the user service thread.
6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: Use POSIX interfaces to develop individual applications; Design kernel component management objects in the kernel, where each component includes a kernel service thread, a user service thread, a control queue and a data queue. Component methods include creating component objects, creating kernel service threads, creating user service threads, and adding, obtaining and responding operations of control queues and data queues. Implement component libraries for each kernel component; Configure the operation mode of each application-dependent kernel component according to the intention of the system end user.
7. An operating system kernel design device, characterized in that: The device comprises: The first design module is used to create a kernel component management object for each component through the kernel and execute a corresponding kernel service thread; The second design module is used for responding to the running of the component common process, the kernel component management object receiving the request service sent by the component common process, the component common process is used to use the component in the manner of requesting service, a component has no common process or corresponds to at least one common process, and a common process is at least a common process of a component; The third design module is used to respond to the user state running the component main process through the function call mode, the component main process is used to implement the function of the corresponding component through the function call mode in the user state, wherein a component has at most one component main process at the same time, each component main process creates a user service thread, the user service thread is used to monitor the request of other ordinary processes to access the component, and one main process component corresponds to one user service thread running at the same time; The fourth design module is used to run the user service thread of the main process of the component.
8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, which is loaded and executed by a processor to implement the operating system kernel design method as described in any one of claims 1 to 6 above.
Citation Information
Patent Citations
Microkernel operating system and access control method thereof, chip, equipment and medium
CN116702180A
Improved operating system performance
CN1782993A
User mode proxy of kernel mode operations in a computer operating system
US6212574B1
Functional component processing method, medium, device and operating system
WO2022222809A1