Interrupt processing method and system and electronic equipment
By setting up interrupt management nodes and endpoints in the microkernel operating system and using a listening mechanism to transmit interrupt information, the problem of low interrupt handling efficiency in existing technologies is solved, achieving efficient and secure interrupt information transmission and enhanced system scalability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Z-ONE TECH CO LTD
- Filing Date
- 2026-01-21
- Publication Date
- 2026-05-08
AI Technical Summary
In existing microkernel operating systems, there are problems with low interrupt handling efficiency and insufficient system scalability in quickly, flexibly, efficiently, and securely notifying user-mode processes of interrupt information from hardware devices.
By setting up interrupt management nodes and interrupt endpoints in the microkernel, interrupt service processes in user-mode processes register corresponding interrupt endpoints and use a listening mechanism to transmit interrupt information, supporting the listening and processing of multiple interrupt sources and enhancing system scalability.
It achieves efficient and secure transmission of interrupt information, improves the interrupt handling efficiency of microkernel operating systems, meets the flexible needs of listening to and handling multiple interrupt sources, and enhances system scalability.
Smart Images
Figure CN121996378A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of microkernel operating system interrupt handling technology, and in particular to an interrupt handling method, system and electronic device. Background Technology
[0002] A microkernel operating system is an operating system based on a microkernel architecture. Its core idea is to "minimize the kernel," meaning that only the smallest and most critical core functions (such as process scheduling, memory management, and inter-process communication) are retained in the microkernel, while most system services (such as file systems, device drivers, and network protocol stacks) are moved to user-space processes. This architecture improves the modularity and flexibility of the system, but it also brings the challenge of how to efficiently and safely notify the user-space processes in the microkernel operating system of interrupt information from hardware devices to better implement interrupt handling. Summary of the Invention
[0003] This application provides an interrupt handling method, system, and electronic device that can more efficiently and securely notify interrupt information from hardware devices to user-mode processes in a microkernel operating system, thereby better implementing interrupt handling.
[0004] Firstly, this application provides an interrupt handling method applied to an interrupt handling system. The interrupt handling system includes a hardware device and a microkernel operating system. The microkernel operating system includes a microkernel and user-mode processes. The microkernel includes an interrupt management node and at least one interrupt endpoint. The user-mode processes include at least one interrupt service process and at least one application node corresponding to each interrupt service process. Each interrupt service process is registered with a corresponding interrupt endpoint. The method includes: when an interrupt occurs, the hardware device sends corresponding interrupt information to the interrupt management node in the microkernel. The interrupt information includes interrupt type identification information. The interrupt management node in the microkernel receives the interrupt information, determines the interrupt type corresponding to the interrupt information based on the interrupt type identification information included in the interrupt information, and determines the interrupt endpoint corresponding to the interrupt information based on the interrupt type and a preset correspondence between interrupt types and interrupt endpoints. The interrupt information is then sent to the corresponding interrupt endpoint. The interrupt service process, acting as an interrupt listener, listens for registered interrupt endpoints. When interrupt information is detected at a registered interrupt endpoint, the interrupt information is obtained from the registered interrupt endpoint and sent to the corresponding application node, enabling the application node to perform corresponding interrupt handling based on the interrupt information.
[0005] In the technical solution provided by this application, the microkernel includes an interrupt management node and at least one interrupt endpoint. The interrupt management node has a pre-defined mapping between interrupt types and interrupt endpoints. Interrupt service processes in user-mode processes register corresponding interrupt endpoints and, acting as interrupt listeners, monitor the registered interrupt endpoints to obtain corresponding interrupt information. Therefore, when the interrupt management node in the microkernel receives interrupt information from a hardware peripheral, it can transmit or route the interrupt information to the corresponding interrupt endpoint based on the interrupt type and the pre-defined mapping between interrupt types and interrupt endpoints. The interrupt service process registered with that endpoint then obtains the interrupt information through a listening mechanism. This achieves the goal of transmitting interrupt information from the microkernel to the interrupt service process in user-mode processes based on the interrupt endpoint, the mapping between interrupt endpoints and interrupt types, and the listening mechanism of the interrupt service process. Ultimately, the interrupt information is transmitted to the corresponding application node in the user-mode process for interrupt handling. In other words, it achieves the goal of notifying user-mode processes in the microkernel operating system of interrupt information from hardware devices.
[0006] Therefore, based on the correspondence between interrupt endpoints, interrupt types, and the monitoring mechanism of interrupt service processes, interrupt information can be transmitted conveniently and accurately. This means that interrupt information from hardware devices can be communicated to user-mode processes in the microkernel operating system more efficiently and securely, improving interrupt handling efficiency and enabling better interrupt processing. Furthermore, multiple interrupts can be processed simultaneously, meeting the flexible needs of monitoring and handling various interrupt sources and enhancing system scalability.
[0007] Optionally, in one implementation of this application, the interrupt endpoint has information caching capability. The method further includes: when the interrupt endpoint receives interrupt information and determines that an interrupt has been triggered, if it determines that no interrupt service process is listening for and acquiring the interrupt information as an interrupt listener, then the interrupt information is cached in the interrupt cache queue corresponding to the interrupt endpoint in the form of a linked list.
[0008] By adopting the above technical solution, when there is no interrupt service process acting as an interrupt listener to obtain interrupt information, the interrupt information that triggers the interrupt is cached, avoiding the loss of interrupt information during transmission. Furthermore, the cached interrupt information is stored in a linked list, which realizes efficient enqueue and dequeue management of interrupt information. This allows for better interrupt handling between hardware devices, microkernels, and user-mode processes, thereby improving the interrupt handling efficiency in microkernel operating systems.
[0009] Optionally, in one implementation of this application, the running state of the interrupt endpoint includes an idle state, a sending state, and a receiving state. The method further includes: the interrupt endpoint adjusting its running state based on whether there is an interrupt service process acting as an interrupt listener to obtain interrupt information and whether an interrupt has been triggered.
[0010] By adopting the above technical solution, the running state of the interrupt endpoint is dynamically adjusted based on the listening state and interrupt triggering state of the interrupt service process, which realizes precise management of the running state of the interrupt endpoint, avoids transmission conflicts or resource waste of interrupt information, and thus can better realize interrupt handling between hardware devices, microkernel and user-mode processes, improving the interrupt handling efficiency in microkernel operating systems.
[0011] Optionally, in one implementation of this application, the interrupt endpoint adjusts its running state based on whether an interrupt service process is listening for interrupt information and whether an interrupt is triggered. This includes: when no interrupt service process is listening for interrupt information and no interrupt is triggered, the interrupt endpoint is in an idle state; when no interrupt service process is listening for interrupt information but an interrupt is triggered, the interrupt endpoint is in a sending state; when an interrupt service process is listening for interrupt information but no interrupt is triggered, the interrupt endpoint is in a receiving state. If interrupt information exists at the interrupt endpoint, it is considered that an interrupt has been triggered; if no interrupt information exists at the interrupt endpoint, it is considered that no interrupt has been triggered.
[0012] By adopting the above technical solution, the running status of the interrupt endpoint is determined by listening to whether there is interrupt information and whether there is interrupt triggering at the interrupt endpoint. This enables the precise transmission of interrupt information from the microkernel to the user-mode process, thereby better realizing interrupt handling between hardware devices, the microkernel, and user-mode processes, and improving the interrupt handling efficiency in the microkernel operating system.
[0013] Optionally, in one implementation of this application, the interrupt service process acts as an interrupt listener receiver, listening to registered interrupt endpoints, including: when the interrupt endpoint registered by the interrupt service process is in an idle state, the interrupt service process is suspended in a receive-blocked state and enters the thread waiting queue of the registered interrupt endpoint to listen for and obtain the corresponding interrupt information when it is listening to and obtaining interrupt information from the registered interrupt endpoint; when the interrupt endpoint registered by the interrupt service process is in a send state, the interrupt service process directly obtains the corresponding interrupt information from the interrupt buffer queue of the registered interrupt endpoint when it is listening to and obtaining interrupt information from the registered interrupt endpoint; when the interrupt endpoint registered by the interrupt service process is in a receive state, the interrupt service process, which is suspended in a receive-blocked state, is awakened and added to the executable scheduling queue when it is listening to and obtaining interrupt information from the registered interrupt endpoint, based on an interrupt trigger of the registered interrupt endpoint.
[0014] By adopting the above technical solution, the interrupt service process establishes corresponding methods for obtaining interrupt information for the idle, sending, and receiving states of the interrupt endpoint. When the interrupt endpoint is in the idle state, the interrupt service process is suspended and enters the receiving blocked state and waits in the thread queue to listen for interrupt information when it tries to obtain interrupt information. When the interrupt endpoint is in the sending state, the interrupt service process directly obtains the corresponding interrupt information from the interrupt buffer queue of the registered interrupt endpoint. When the interrupt endpoint is in the receiving state, the interrupt service process wakes up the blocked process based on the interrupt trigger event and adds it to the executable scheduling queue to listen for interrupt information. This achieves precise adaptation between the interrupt service process and the interrupt endpoint state, ensuring efficient acquisition and real-time response of interrupt information and the specificity of listening. As a result, it can better realize interrupt handling between hardware devices, microkernel, and user-mode processes, and improve the interrupt handling efficiency in the microkernel operating system.
[0015] Optionally, in one implementation of this application, the microkernel further includes an interrupt scheduling node. The method further includes registering the interrupt service process with the interrupt endpoint in the following manner: the interrupt service process sends an interrupt registration request to the interrupt scheduling node in the microkernel, the interrupt registration request including interrupt type identifier information of the interrupt type corresponding to the interrupt service process; the interrupt scheduling node in the microkernel determines the interrupt endpoint corresponding to the interrupt service process according to the interrupt type identifier information included in the interrupt registration request, completes the registration configuration between the interrupt service process and the interrupt endpoint, returns the corresponding configuration information to the interrupt service process, and stores the correspondence between the interrupt type corresponding to the interrupt service process and the interrupt endpoint registered by the interrupt service process in a vector table; the interrupt service process completes the corresponding registration configuration according to the configuration information.
[0016] By adopting the above technical solution, the interrupt scheduling node determines the interrupt endpoint corresponding to the interrupt service process based on the interrupt type of the interrupt service process, completes the registration configuration between the interrupt service process and the interrupt endpoint, and stores the configuration result in the form of a vector table, which simplifies interrupt management. Furthermore, the microkernel only needs to maintain the interrupt vector table, reducing intervention in interrupt management. This allows for better interrupt handling between hardware devices, the microkernel, and user-mode processes, thereby improving the interrupt handling efficiency in the microkernel operating system.
[0017] Optionally, in one implementation of this application, there is one or more interrupt service processes registered at each interrupt endpoint, and / or each interrupt service process is registered with one or more corresponding interrupt endpoints.
[0018] By adopting the above technical solution, the flexibility of the correspondence between interrupt endpoints and interrupt service processes allows interrupt service processes to more accurately monitor interrupt information at interrupt endpoints and send it to the corresponding application nodes. This improves the efficiency and accuracy of application nodes in processing interrupt information, thereby better enabling interrupt handling between hardware devices, microkernels, and user-space processes, and improving interrupt handling efficiency in microkernel operating systems. Furthermore, the registration mechanism allows multiple interrupt service processes to handle multiple interrupts simultaneously, meeting the flexible needs of monitoring and handling various interrupt sources and enhancing system scalability.
[0019] Optionally, in one implementation of this application, the application node is a user-mode device driver service program.
[0020] By adopting the above technical solution and using the user-mode device driver service program as the application node, the interrupt handling responsibilities of the microkernel and user-mode processes can be separated, thereby improving the stability and security of the microkernel operating system.
[0021] Optionally, in one implementation of this application, the interrupt information also includes interrupt content description information.
[0022] Using the above technical solution, the interrupt content description information describes the specific content of the interrupt. That is, compared with the existing technology that only sends interrupt notifications, more additional information can be carried in the interrupt information. Based on the interrupt information carrying more interrupt-related information, interrupt handling between hardware devices, microkernels, and user-mode processes can be better realized, thus improving the interrupt handling efficiency in microkernel operating systems.
[0023] Secondly, this application provides an interrupt handling system, which includes a hardware device and a microkernel operating system. The microkernel operating system includes a microkernel and user-mode processes. The microkernel includes an interrupt management node and at least one interrupt endpoint. The user-mode processes include at least one interrupt service process and at least one application node corresponding to each interrupt service process. Each interrupt service process is registered with a corresponding interrupt endpoint. When an interrupt occurs, the hardware device sends corresponding interrupt information to the interrupt management node in the microkernel. The interrupt information includes interrupt type identification information. The interrupt management node in the microkernel receives the interrupt information, determines the interrupt type corresponding to the interrupt information based on the interrupt type identification information, and determines the corresponding interrupt endpoint based on the interrupt type and a preset correspondence between interrupt types and interrupt endpoints. The interrupt service process acts as an interrupt listener, monitoring the registered interrupt endpoints. When interrupt information is detected at a registered interrupt endpoint, the interrupt service process retrieves the interrupt information from the registered interrupt endpoint and sends the retrieved interrupt information to the corresponding application node, enabling the application node to perform corresponding interrupt handling based on the interrupt information.
[0024] Thirdly, an implementation of this application provides an electronic device including the above-described interrupt handling system for implementing the above-described interrupt handling method.
[0025] Fourthly, an implementation of this application provides an electronic device, including: a processor and a memory communicatively connected to the processor; the memory stores a computer program, and the processor executes the computer program stored in the memory to enable the electronic device to implement the above-described interrupt handling method.
[0026] Fifthly, this application provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which are executed by an electronic device to enable the electronic device to implement the above-described interrupt handling method.
[0027] Sixthly, an implementation of this application provides a computer program product, including a computer program that, when executed by a processor, causes an electronic device to implement the above-described interrupt handling method.
[0028] In summary, the interrupt handling scheme provided in this application transmits interrupt information between the microkernel and user-space service processes through interrupt endpoints and a listening mechanism. The user-space interrupt service process first listens to the corresponding interrupt endpoint to receive interrupt information from the microkernel and then distributes it to each application node. Each application node is responsible for its associated interrupt information and performs appropriate interrupt handling and response. Furthermore, this scheme supports both a one-to-many mode (one interrupt endpoint forwarding multiple interrupts to serve multiple application nodes) and a one-to-one mode (one interrupt endpoint forwarding only one interrupt to serve only one application node). Additionally, the interrupt information can carry interrupt content information other than interrupt identification information. Thus, by setting interrupt endpoints, the responsibility for interrupt handling is shifted from the microkernel to each application node in the user-space process to perform corresponding interrupt handling. By flexibly selecting the interrupt distribution mode and leveraging the ability to attach additional information, interrupt handling between hardware devices, the microkernel, and user-space processes can be better realized, improving the interrupt handling efficiency in the microkernel operating system. Furthermore, the microkernel can handle multiple interrupts simultaneously, meeting the flexible needs of listening to and handling various interrupt sources, and also enhancing system scalability. Attached Figure Description
[0029] Figure 1 This is a schematic diagram of the interrupt handling system provided in the implementation of this application; Figure 2 This is a flowchart illustrating one of the interrupt handling methods provided in the implementation of this application; Figure 3 This is a schematic diagram of an interrupt endpoint caching interrupt information based on a doubly linked list in the interrupt handling method provided in this application. Figure 4 This is a schematic diagram of the state transition of the interrupt endpoint in the interrupt handling method provided by the implementation of this application; Figure 5 This is a schematic diagram of the state transition of the interrupt service process in the interrupt handling method provided in this application. Figure 6 This is a schematic diagram of the structure of an electronic device provided in the implementation of this application. Detailed Implementation
[0030] A microkernel operating system, also known as a microkernel system, uses interrupt handling as its core mechanism for interaction with hardware. Its main function is to respond to sudden requests (i.e., interrupts) from hardware devices (such as keyboards, network cards, and sensors), triggering the kernel to suspend the current task through the interrupt controller and execute the corresponding interrupt service routine, and then resume the original task after completion.
[0031] In existing microkernel operating systems, interrupt dispatch is mostly based on a simple notification mechanism, which is a very lightweight event notification method. When registering an interrupt, a user-space interrupt service process needs to provide a Notify and an interrupt number. A Notify can only be bound to one interrupt for registration, not supporting a one-to-many model. Furthermore, a listener cannot simultaneously listen to all interrupt notifications. User-space interrupt service processes must either start multiple threads or poll multiple notifications one by one, making the implementation relatively complex. In addition, Notify is only a simple event notification mechanism; it cannot carry or attach additional information, which is detrimental to system scalability. This increases the complexity of interrupt management and reduces the timeliness of interrupt handling, making it difficult to meet the flexible requirements of microkernels for simultaneously listening to and handling multiple interrupt sources. Moreover, how to perform interrupt dispatch quickly, flexibly, efficiently, and securely under a microkernel operating system architecture remains a hot research topic.
[0032] In other words, existing technologies face the challenge of how to quickly, flexibly, efficiently, and securely notify user-mode processes in a microkernel operating system of interrupt information from hardware devices in order to better implement interrupt handling.
[0033] Based on this, this application provides an interrupt handling system, such as... Figure 1 As shown, the system includes hardware devices and a microkernel operating system. The microkernel operating system includes a microkernel and user-mode processes. The microkernel includes an interrupt management node and at least one interrupt endpoint. The user-mode processes include at least one interrupt service process and at least one application node corresponding to each interrupt service process. Each interrupt service process is registered with a corresponding interrupt endpoint.
[0034] Furthermore, the microkernel in a microkernel operating system also includes an interrupt scheduler node.
[0035] Based on this interrupt handling system, this application also provides an interrupt handling method applied to the interrupt handling system. The method includes: when an interrupt occurs, a hardware device sends corresponding interrupt information to the interrupt management node in the microkernel. The interrupt information includes interrupt type identification information. The interrupt management node in the microkernel receives the interrupt information, determines the interrupt type corresponding to the interrupt information based on the interrupt type identification information included in the interrupt information, and determines the interrupt endpoint corresponding to the interrupt information based on the interrupt type and a preset correspondence between interrupt types and interrupt endpoints. The interrupt information is then sent to the corresponding interrupt endpoint. An interrupt service process, acting as an interrupt listener, listens for registered interrupt endpoints. When interrupt information is detected at a registered interrupt endpoint, the process obtains the interrupt information from the registered interrupt endpoint and sends the obtained interrupt information to the corresponding application node, enabling the application node to perform corresponding interrupt handling based on the interrupt information.
[0036] In other words, in the interrupt handling system provided by this application, the microkernel includes an interrupt management node and at least one independent interrupt endpoint. The interrupt management node has a pre-defined correspondence between interrupt types and interrupt endpoints. The interrupt service process in the user-mode process registers the corresponding interrupt endpoint and acts as an interrupt listener, listening to the registered interrupt endpoint to obtain the corresponding interrupt information. Therefore, in the interrupt handling method based on this interrupt handling system, when the interrupt management node in the microkernel receives interrupt information from a hardware peripheral, it can transmit or route the interrupt information to the corresponding interrupt endpoint based on the interrupt type corresponding to the interrupt information and the pre-defined correspondence between interrupt types and interrupt endpoints. The interrupt service process registered with that interrupt endpoint then obtains the interrupt information based on the listening mechanism. This achieves the purpose of transmitting or routing interrupt information from the microkernel to the interrupt service process in the user-mode process based on the interrupt endpoint, the correspondence between interrupt endpoints and interrupt types, and the listening mechanism of the interrupt service process. Ultimately, the interrupt information is transmitted or routed to the corresponding application node in the user-mode process for corresponding interrupt handling, thus achieving the purpose of notifying the user-mode process in the microkernel operating system of the interrupt information from the hardware device.
[0037] Therefore, based on the correspondence between interrupt endpoints, interrupt endpoints and interrupt types, and the monitoring mechanism of interrupt service processes, the transmission of interrupt information can be conveniently and accurately achieved. This means the process is simple and accurate, and interrupt information from hardware devices can be communicated to user-mode processes in the microkernel operating system more efficiently and securely. This improves the interrupt handling efficiency in the microkernel operating system and allows for better interrupt handling. Furthermore, multiple interrupts can be processed simultaneously, meeting the flexible needs of monitoring and handling various interrupt sources and enhancing system scalability.
[0038] The following section will provide a more detailed description of the creation of interrupt endpoints and the registration process of interrupt service processes with interrupt endpoints.
[0039] For example, the registration of interrupt endpoints by an interrupt service process is implemented as follows: The interrupt service process sends an interrupt registration request to the interrupt scheduling node in the microkernel. The interrupt registration request includes interrupt type identifier information of the interrupt type corresponding to the interrupt service process. The interrupt scheduling node in the microkernel determines the interrupt endpoint corresponding to the interrupt service process based on the interrupt type identifier information included in the interrupt registration request, completes the registration configuration between the interrupt service process and the interrupt endpoint, returns the corresponding configuration information to the interrupt service process, and stores the correspondence between the interrupt type corresponding to the interrupt service process and the interrupt endpoints registered by the interrupt service process in a vector table. The interrupt service process completes the corresponding registration configuration based on the configuration information.
[0040] In other words, in the implementation of this application, an independent interrupt endpoint is designed. The microkernel provides a system call to create the interrupt endpoint, meaning the microkernel provides an interrupt scheduling node to complete the registration of the interrupt endpoint. When registering an interrupt, the interrupt service process sends an interrupt registration request to the interrupt scheduling node in the microkernel. The interrupt registration request includes interrupt type identifier information corresponding to the interrupt type of the interrupt service process; this interrupt identifier information can be the interrupt number. Next, the interrupt scheduling node in the microkernel determines the interrupt endpoint corresponding to the interrupt service process based on the interrupt number included in the interrupt registration request, completes the registration configuration between the interrupt service process and the corresponding interrupt endpoint, returns the corresponding configuration information to the interrupt service process, and stores the correspondence between the interrupt type corresponding to the interrupt service process and the interrupt endpoints registered by the interrupt service process in a vector table. The interrupt service process completes the corresponding registration configuration based on the configuration information. That is, during interrupt registration, the interrupt number and interrupt endpoint are passed as parameters to the interrupt scheduling node in the microkernel. When the interrupt scheduling node receives the interrupt registration, in addition to configuring and enabling the hardware interrupt control registers, it also needs to maintain a vector table containing the interrupt number and interrupt endpoint.
[0041] Specifically, in an implementable example, the vector table is shown in Table 1. Table 1 includes, for example, interrupt numbers, interrupt endpoints, and interrupt service processes. Interrupt numbers include, for example, U20 and E20; interrupt endpoints include, for example, Universal Serial Bus (USB) mouse interrupt endpoints and Ethernet (Eth) interrupt endpoints; and interrupt service processes include the USB mouse interrupt service process (usb_irq_mouse_handler) and the Ethernet interrupt service process (eth_irq_handler).
[0042] Table 1
[0043] The methods for completing interrupt registration are not limited to the examples mentioned above. Furthermore, the interrupt identification information is not limited to the interrupt number; it can also be other identifiers that recognize interrupt information, which can be set as needed. Additionally, the correspondence between interrupt types and interrupt endpoints can also be set as needed.
[0044] Optionally, in one implementation of this application, when registering an interrupt, the user-mode process stores a table showing the relationship between interrupt service processes and the application nodes corresponding to those interrupt service processes. When an interrupt is triggered, the microkernel can determine the interrupt service process corresponding to the interrupt information based on the vector table of interrupt service processes and interrupt endpoints. The user-mode process can then select the application node corresponding to the interrupt information based on the table showing the relationship between interrupt service processes and the application nodes corresponding to those interrupt service processes.
[0045] Specifically, in a feasible example, where the application node is a user-space device driver service program, the relationship table between interrupt service processes and their corresponding application nodes is shown in Table 2. Interrupt service processes include the USB mouse interrupt service process (usb_irq_mouse_handler), the Ethernet interrupt service process (eth_irq_handler), etc., and the corresponding application nodes include the USB mouse driver node corresponding to the USB mouse interrupt service process, and the wired network card driver node (eth0) and the wireless network card driver node (wlan0) corresponding to the Ethernet interrupt service process, etc.
[0046] Table 2
[0047] Of course, application nodes can also be file system servers, network protocol stack servers, etc.
[0048] The technical solution provided by the implementation method of this application will be described in further detail below with reference to the accompanying drawings.
[0049] One implementation of this application, the interrupt handling method provided in this application, is as follows: Figure 2 As shown, the method includes the following steps.
[0050] S100: When an interrupt occurs, the hardware device sends the corresponding interrupt information to the interrupt management node in the microkernel. The interrupt information includes interrupt type identification information.
[0051] Optionally, in one implementation of this application, when a USB interrupt exists at the hardware device, the hardware device sends interrupt information, interrupt type identification information, i.e., interrupt number U20, to the interrupt management node in the microkernel.
[0052] S200: The interrupt management node in the microkernel receives interrupt information, determines the interrupt type corresponding to the interrupt information based on the interrupt type identifier information included in the interrupt information, and determines the interrupt endpoint corresponding to the interrupt information based on the interrupt type and the preset correspondence between interrupt types and interrupt endpoints, and sends the interrupt information to the corresponding interrupt endpoint.
[0053] Optionally, in one implementation of this application, the interrupt management node in the microkernel receives interrupt information. Based on the interrupt type identifier information included in the interrupt information, upon receiving the interrupt information, the interrupt management node first identifies the interrupt type identifier information. If the identifier information is "U20", it is determined to be a USB mouse-triggered interrupt; if the identifier information is "E20", it is determined to be an Ethernet-triggered interrupt. Subsequently, the interrupt management node determines the interrupt endpoint corresponding to the interrupt information based on the vector table of interrupt types and interrupt endpoints pre-stored in the interrupt management node, and sends the interrupt information to the corresponding interrupt endpoint.
[0054] Optionally, when an interrupt message with interrupt number U20 is received from a hardware device, the interrupt management node determines the interrupt type as a USB mouse trigger interrupt based on the interrupt number, determines the interrupt endpoint corresponding to the interrupt message as a USB mouse interrupt endpoint based on Table 1, and sends the interrupt message to the corresponding USB mouse interrupt endpoint.
[0055] S300: The interrupt service process acts as an interrupt listener and receiver, listening to the registered interrupt endpoints. If interrupt information is detected at a registered interrupt endpoint, the process obtains the interrupt information from the registered interrupt endpoint and sends the obtained interrupt information to the corresponding application node, so that the application node can perform corresponding interrupt handling based on the interrupt information.
[0056] Optionally, when the USB mouse interrupt service process registered at the USB mouse interrupt endpoint detects an interrupt message at the USB mouse interrupt endpoint, the USB mouse interrupt service process obtains the corresponding interrupt message from the USB mouse interrupt endpoint. Based on the correspondence between the USB mouse interrupt service process and the application node in Table 2, it can determine that the application node corresponding to the interrupt message has a USB mouse driver node, and send the obtained interrupt message to the USB mouse driver node so that the USB mouse driver node can perform corresponding interrupt processing according to the interrupt message.
[0057] In addition, when the Ethernet interrupt service process registered at the Ethernet interrupt endpoint detects an interrupt message at the Ethernet interrupt endpoint, the Ethernet interrupt service process obtains the corresponding interrupt message from the Ethernet interrupt endpoint. Based on the correspondence between the Ethernet interrupt service process and the application node in Table 2, it can be determined that the application node corresponding to the interrupt message is the wired network card driver node (eth0) and the wireless network card driver node (wlan0). The obtained interrupt message is then sent to the wired network card driver node (eth0) and the wireless network card driver node (wlan0) so that the wired network card driver node (eth0) and the wireless network card driver node (wlan0) can perform corresponding interrupt processing according to the interrupt message.
[0058] Optionally, in one implementation of this application, the interrupt endpoint also has information caching capability. When the interrupt endpoint receives interrupt information and determines that an interrupt has been triggered, if it determines that no interrupt service process is listening for and receiving the interrupt information, the interrupt information is cached in the interrupt cache queue corresponding to the interrupt endpoint in the form of a linked list.
[0059] For example, when an interrupt endpoint caches interrupt information, it stores the interrupt information in the corresponding interrupt cache queue in the form of a linked list. When an interrupt is triggered at the interrupt endpoint but no interrupt service process is listening for the interrupt, the interrupt endpoint caches the interrupt information to ensure that it is not lost.
[0060] Optionally, such as Figure 3 As shown, the cached interrupt information is stored in the form of a doubly linked list. The list includes a head node, a tail node, and at least one intermediate node that stores the interrupt information. The intermediate node that stores the interrupt information includes a predecessor node (pre) pointing to the previous node, the interrupt data, and a successor node (next) pointing to the next node. Here, pre and next represent the doubly linked nodes, and the interrupt data is the interrupt information, which can also be called the interrupt message.
[0061] Of course, there are no restrictions on how the cached interrupt information is stored; it can be set as needed.
[0062] Furthermore, the interrupt information may include the aforementioned interrupt type identification information (e.g., interrupt number), and may also include interrupt content description information. The interrupt content description information describes the specific content of the interrupt, such as the location and time of the interrupt. That is, compared to the existing technology that simply sends interrupt notifications, more additional information can be carried in the interrupt information. Based on the interrupt information carrying more interrupt-related information, interrupt handling between hardware devices, the microkernel, and user-mode processes can be better implemented, improving the interrupt handling efficiency in the microkernel operating system.
[0063] Optionally, in one implementation of this application, the running state of the interrupt endpoint includes an idle state, a sending state, and a receiving state. The interrupt endpoint adjusts its running state based on whether there is an interrupt service process acting as an interrupt listener to obtain interrupt information and whether an interrupt is triggered.
[0064] For example, the running state of the interrupt endpoint is adjusted based on whether an interrupt service process is listening for interrupt information and whether an interrupt is triggered. This includes: when no interrupt service process is listening for interrupt information and no interrupt is triggered, the interrupt endpoint is in an idle state; when no interrupt service process is listening for interrupt information but an interrupt is triggered, the interrupt endpoint is in a sending state; and when an interrupt service process is listening for interrupt information but no interrupt is triggered, the interrupt endpoint is in a receiving state. In other words, the endpoint is in an idle state when there is no receiver listening and no interrupt is triggered; the endpoint is in a sending state when there is no receiver listening but an interrupt is triggered; and the endpoint is in a receiving state when there is a receiver listening but no interrupt is triggered.
[0065] Furthermore, if interrupt information exists at the interrupt endpoint, an interrupt is considered to have been triggered; if no interrupt information exists at the interrupt endpoint, no interrupt is considered to have been triggered. This can also be understood as: if the buffer queue at the interrupt endpoint is not empty, an interrupt is considered to have been triggered; if the buffer queue at the interrupt endpoint is empty, no interrupt is considered to have been triggered.
[0066] For example, such as Figure 4 As shown, Figure 4 This diagram illustrates a state transition for an interrupt endpoint, which can be, for example, an interrupt endpoint in the microkernel operating system corresponding to an STM series microcontroller. The idle state is the basic state of the interrupt endpoint. When an interrupt is triggered at the interrupt endpoint, the endpoint state switches from idle to sending. Furthermore, if another interrupt is triggered while the interrupt endpoint is in the sending state, it will remain in the sending state, forming a loop, until the interrupt service routine in the sending state detects and receives the interrupt information, and the interrupt information buffer queue is empty. At this point, the interrupt endpoint switches from the sending state to the idle state. Similarly, when an interrupt endpoint in the idle state receives an interrupt, it switches from idle to receiving. If the interrupt endpoint in the receiving state continues to receive interrupt information, it will remain in the receiving state, forming a loop, until an interrupt is triggered at the interrupt endpoint, and the thread queue waiting to receive interrupt information is empty. At this point, the interrupt endpoint state switches from the receiving state to the idle state.
[0067] Of course, the transition mechanism between the three states of the interrupt endpoint is not limited to the example above, and can be set as needed.
[0068] Optionally, in one implementation of this application, the interrupt service process acts as an interrupt listener receiver, listening to registered interrupt endpoints, including: when the interrupt endpoint registered by the interrupt service process is in an idle state, the interrupt service process is suspended in a receive-blocked state and enters the thread waiting queue of the registered interrupt endpoint to listen for and obtain the corresponding interrupt information when it is listening to and obtaining interrupt information from the registered interrupt endpoint; when the interrupt endpoint registered by the interrupt service process is in a send state, the interrupt service process directly obtains the corresponding interrupt information from the interrupt buffer queue of the registered interrupt endpoint when it is listening to and obtaining interrupt information from the registered interrupt endpoint; when the interrupt endpoint registered by the interrupt service process is in a receive state, the interrupt service process is awakened and added to the executable scheduling queue when it is listening to and obtaining interrupt information from the registered interrupt endpoint, based on the existence of an interrupt at the registered interrupt endpoint, to listen for and obtain the corresponding interrupt information.
[0069] In other words, the running state of the interrupt service process listening to interrupt endpoints in user-mode processes is controlled by the interrupt endpoints it has registered with. When there are listeners but no interrupt is triggered, the listener is set to a blocked state and enters the thread waiting queue of the interrupt endpoint. When there are no listeners but an interrupt is triggered, the interrupt information is buffered and not lost. When there are listeners and an interrupt is triggered, the listener is removed from the interrupt endpoint's waiting queue, the interrupt information is prepared, and the listener is set to a runnable state. The ultimate goal is to realize the transmission of interrupt information between the microkernel and application nodes through the endpoint mechanism.
[0070] For example, such as Figure 5 As shown, Figure 5This diagram illustrates a state transition for an interrupt service routine (ISR). The ISR can be, for example, the ISR within the microkernel operating system corresponding to an STM series microcontroller. When the ISR's registered interrupt endpoint is in the transmit state, the ISR is in the run state. Upon registering to listen for receive interrupts, the ISR directly retrieves messages from the interrupt buffer queue. Once the interrupt information detected by the ISR is removed from the interrupt endpoint's buffer queue, the queue becomes empty, and the ISR is in the idle state. When the ISR is listening for interrupt information from the registered interrupt endpoint, if the registered interrupt endpoint is in the idle state, the ISR switches from the run state to the receive blocked state and enters the thread waiting queue of the registered interrupt endpoint to listen for and retrieve the corresponding interrupt information. When the ISR's registered interrupt endpoint is in the receive state, if an interrupt is triggered at the registered interrupt endpoint, the ISR switches from the receive blocked state to the run state. In other words, when the interrupt endpoint is in the receiving state, after the interrupt is triggered, the interrupt service process retrieves the thread that is blocked and suspended in the waiting queue on the interrupt endpoint, sets an interrupt message for it, wakes it up and adds it to the executable scheduling queue, waiting to be scheduled for execution.
[0071] Optionally, in one implementation of this application, there may be one or more interrupt service processes registered at each interrupt endpoint. That is, it may be a one-to-many mode where one interrupt endpoint forwards interrupt information corresponding to multiple interrupt service processes and serves multiple application nodes, or a one-to-one mode where one interrupt endpoint forwards interrupt information corresponding to only one interrupt service process and serves only one application node.
[0072] Optionally, in one implementation of this application, each interrupt service process registers one or more corresponding interrupt endpoints. That is, an interrupt service process can monitor interrupt information at only one interrupt endpoint or monitor interrupt information at multiple interrupt endpoints, thereby fulfilling the requirement of transmitting interrupt information to the corresponding application node.
[0073] As mentioned above, the interrupt handling system provided in this application includes a hardware device and a microkernel operating system. The microkernel operating system includes a microkernel and user-mode processes. The microkernel includes an interrupt management node and at least one interrupt endpoint. The user-mode processes include at least one interrupt service process and at least one application node corresponding to each interrupt service process. Each interrupt service process is registered with a corresponding interrupt endpoint.
[0074] The hardware device is used to send the received interrupt information to the interrupt management node in the microkernel. The interrupt information includes interrupt type identification information.
[0075] The interrupt management node is used to receive interrupt information, determine the interrupt type corresponding to the interrupt information based on the interrupt type identifier information included in the interrupt information, and determine the interrupt endpoint corresponding to the interrupt information based on the interrupt type and the correspondence between the interrupt type and the interrupt endpoint.
[0076] The interrupt service process acts as a receiver of interrupt information, listens for registered interrupt endpoints, and when it detects interrupt information at a registered interrupt endpoint, it retrieves the interrupt information from the registered interrupt endpoint and sends the retrieved interrupt information to the corresponding application node so that the application node can perform the corresponding interrupt handling based on the interrupt information.
[0077] Furthermore, the interrupt scheduling node is used to create interrupt endpoints, register interrupt endpoints with interrupt service processes, and forward interrupt information.
[0078] In summary, the interrupt handling scheme based on the interrupt handling system provided in this application can be understood as a method for interrupt distribution based on endpoints in a microkernel system. This method enables interactive functions of interrupt listening and notification between the microkernel and user-space interrupt service processes. It mainly includes three parts: endpoint creation and interrupt registration, interrupt listening, and interrupt notification and caching. The core of this scheme is to transmit interrupt information between the microkernel and application nodes (such as user-space device driver service programs) through an endpoint mechanism. The user-space interrupt service process is responsible for listening to the endpoint to receive interrupt information from the kernel and ultimately distributing it to each node. Each node is responsible for its associated interrupts and performs appropriate processing and response. Furthermore, this scheme supports not only a one-to-many mode (one endpoint forwarding multiple types of interrupts and serving multiple nodes) but also a one-to-one mode (one endpoint forwarding only one type of interrupt and serving only one node). Thus, by shifting the responsibility of interrupt handling from the kernel center to each node, flexibly selecting interrupt distribution modes, and leveraging the ability to attach additional information, the efficiency of interrupt handling in the microkernel operating system is improved, while also enhancing scalability.
[0079] Specifically, the interrupt handling method based on a microkernel operating system provided in this application has the following six main technical advantages: 1. It solves the defect of existing methods that cannot attach additional information when notifying interrupts. 2. It simplifies interrupt management; the microkernel only needs to maintain the interrupt vector table, reducing intervention in interrupt management. 3. It enables the listening and receiving of all registered interrupt notifications through a single endpoint. 4. When there is no interrupt listener, it can cache triggered interrupt information to ensure no loss of capability. 5. When no interrupt is triggered, the listener is blocked and suspended in the endpoint's waiting queue, ensuring the exclusivity of listening. 6. It enables diverse interrupt reception, improving the system's adaptability and scalability.
[0080] This application also provides an electronic device, including the above-described interrupt handling system, for implementing the above-described interrupt handling method.
[0081] For example, such as Figure 6 As shown, Figure 6 This is a schematic diagram of the structure of an electronic device. For example... Figure 6 As shown, the electronic device may include: transceiver 121, processor 122, and memory 123.
[0082] Processor 122 executes computer execution instructions stored in memory, causing it to perform the interrupt handling method described above. Processor 122 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.
[0083] The memory 123 is connected to the processor 122 via the system bus and completes communication between them. The memory 123 is used to store computer program instructions.
[0084] Transceiver 121 can be used to obtain the task to be run and its configuration information.
[0085] The system bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus. Transceivers are used to enable communication between database access devices and other computers (e.g., clients, read-write libraries, and read-only libraries). Memory may include random access memory (RAM) and may also include non-volatile memory.
[0086] Furthermore, the electronic device provided in this application may be, for example, a vehicle, a server, a user mobile terminal, or other electronic devices.
[0087] This application also provides a computer-readable storage medium storing computer instructions / programs. When the computer instructions / programs are run on the processor of an electronic device, the processor of the electronic device executes the interrupt handling method described above.
[0088] In some possible implementations, various aspects of the methods provided in this application can also be implemented as a program product, which includes program code. When the program product is run on the processor of an electronic device, the program code is used to cause the processor of the electronic device to perform the steps of the methods in the various exemplary embodiments of this application described above. For example, the electronic device can perform the interrupt handling method described in the implementation of this application.
[0089] This application also provides a computer program product, which includes a computer program / instruction stored in a computer-readable storage medium. At least one processor can read the computer program / instruction from the computer-readable storage medium, and when the at least one processor executes the computer program / instruction, it can implement the technical solution of the interrupt handling method in the above-described implementation.
[0090] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.
[0091] It should be noted that, in addition to the specific implementations described above, those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. Although the description of this application is presented in conjunction with preferred implementations, this does not mean that the features of this invention are limited to that implementation. On the contrary, the purpose of describing the invention in conjunction with implementations is to cover other options or modifications that may be derived from the claims of this application. To provide a thorough understanding of this application, many specific details are included in the above description, and this application may also be implemented without using these details. Furthermore, to avoid confusion or obscuring the focus of this application, some specific details will be omitted in the description. It should be noted that, unless otherwise specified, the implementations and features of the implementations in this application can be combined with each other.
[0092] Although this application has been illustrated and described with reference to certain preferred embodiments, those skilled in the art should understand that the above description is a further detailed explanation of the application in conjunction with specific implementations, and should not be construed as limiting the specific implementation of the application to these descriptions. Those skilled in the art can make various changes in form and detail, including some simple deductions or substitutions, without departing from the spirit and scope of this application.
Claims
1. An interrupt handling method, characterized in that, An interrupt handling system is applied, comprising hardware devices and a microkernel operating system. The microkernel operating system includes a microkernel and user-mode processes. The microkernel includes an interrupt management node and at least one interrupt endpoint. The user-mode processes include at least one interrupt service routine and at least one application node corresponding to each interrupt service routine. Each interrupt service routine is registered with a corresponding interrupt endpoint. The method includes: In the event of an interrupt, the hardware device sends corresponding interrupt information to the interrupt management node in the microkernel, and the interrupt information includes interrupt type identification information. The interrupt management node in the microkernel receives the interrupt information, determines the interrupt type corresponding to the interrupt information based on the interrupt type identifier information included in the interrupt information, and determines the interrupt endpoint corresponding to the interrupt information based on the interrupt type and the preset correspondence between interrupt types and interrupt endpoints, and sends the interrupt information to the corresponding interrupt endpoint. The interrupt service process acts as an interrupt listener receiver, listening to the registered interrupt endpoints. When interrupt information is detected at a registered interrupt endpoint, the process obtains the interrupt information from the registered interrupt endpoint and sends the obtained interrupt information to the corresponding application node, so that the application node can perform corresponding interrupt processing based on the interrupt information.
2. The method according to claim 1, characterized in that, The interrupt endpoint has information buffering capabilities, and the method further includes: If the interrupt endpoint receives the interrupt information and determines that an interrupt has been triggered, and if it determines that no interrupt service process is listening for the interrupt information, then the interrupt information is cached in the interrupt cache queue corresponding to the interrupt endpoint in a linked list format.
3. The method according to claim 2, characterized in that, The interrupt endpoint's operating states include an idle state, a transmit state, and a receive state. The method further includes: The interrupt endpoint adjusts its running state based on whether the interrupt service process is listening for and receiving the interrupt information and whether an interrupt has been triggered.
4. The method according to claim 3, characterized in that, The interrupt endpoint adjusts its running state based on whether the interrupt service process is listening for and receiving interrupt information and whether an interrupt has been triggered, including: When no interrupt service process is listening for interrupt information as an interrupt listener and no interrupt is triggered, the interrupt endpoint is in the idle state. When no interrupt service process is listening for interrupt information as an interrupt listener, but an interrupt is triggered, the interrupt endpoint is in the sending state. When an interrupt service process is listening for interrupt information as an interrupt listener, but no interrupt is triggered, the interrupt endpoint is in a receiving state; wherein, If the interrupt information exists at the interrupt endpoint, it is considered that an interrupt has been triggered; if the interrupt information does not exist at the interrupt endpoint, it is considered that no interrupt has been triggered.
5. The method according to claim 4, characterized in that, The interrupt service process, acting as an interrupt listener receiver, listens to the registered interrupt endpoints, including: When the interrupt endpoint registered by the interrupt service process is in an idle state, the interrupt service process is suspended and enters the receive blocking state when listening to the interrupt endpoint to obtain the interrupt information. It enters the thread waiting queue of the registered interrupt endpoint to listen for and obtain the corresponding interrupt information. When the interrupt endpoint registered by the interrupt service process is in the sending state, the interrupt service process directly obtains the corresponding interrupt information from the interrupt buffer queue of the registered interrupt endpoint when it is listening to the interrupt endpoint to obtain the interrupt information. When the interrupt endpoint registered by the interrupt service process is in the receiving state, when the interrupt service process is listening to the registered interrupt endpoint to obtain the interrupt information, the interrupt service process that was suspended in the receiving blocked state based on the interrupt trigger of the registered interrupt endpoint is woken up and added to the executable scheduling queue to listen for and obtain the corresponding interrupt information.
6. The method according to claim 5, characterized in that, The microkernel also includes an interrupt scheduling node, and the method further includes registering the interrupt service process with the interrupt endpoint in the following manner: The interrupt service process sends an interrupt registration request to the interrupt scheduling node in the microkernel. The interrupt registration request includes interrupt type identifier information of the interrupt type corresponding to the interrupt service process. The interrupt scheduling node in the microkernel determines the interrupt endpoint corresponding to the interrupt service process based on the interrupt type identifier information included in the interrupt registration request, completes the registration configuration between the interrupt service process and the interrupt endpoint, returns the corresponding configuration information to the interrupt service process, and stores the correspondence between the interrupt type corresponding to the interrupt service process and the interrupt endpoint registered by the interrupt service process in a vector table. The interrupt service process completes the corresponding registration configuration based on the configuration information.
7. The method according to claim 6, characterized in that, Each interrupt service process is registered with one or more interrupt endpoints, and / or each interrupt service process is registered with one or more corresponding interrupt endpoints.
8. The method according to claim 7, characterized in that, The application node is a user-mode device driver service program, and the interrupt information also includes interrupt content description information.
9. An interrupt handling system, characterized in that, The interrupt handling system includes hardware devices and a microkernel operating system. The microkernel operating system includes a microkernel and user-mode processes. The microkernel includes an interrupt management node and at least one interrupt endpoint. The user-mode processes include at least one interrupt service routine and at least one application node corresponding to each interrupt service routine. Each interrupt service routine is registered with a corresponding interrupt endpoint. The hardware device is used to send corresponding interrupt information to the interrupt management node in the microkernel in the event of an interrupt, and the interrupt information includes interrupt type identification information; The interrupt management node in the microkernel is used to receive the interrupt information, determine the interrupt type corresponding to the interrupt information based on the interrupt type identifier information included in the interrupt information, determine the interrupt endpoint corresponding to the interrupt information based on the interrupt type and the preset correspondence between interrupt types and interrupt endpoints, and send the interrupt information to the corresponding interrupt endpoint. The interrupt service process acts as an interrupt listener receiver, listening to the registered interrupt endpoints. When interrupt information is detected at a registered interrupt endpoint, the process obtains the interrupt information from the registered interrupt endpoint and sends the obtained interrupt information to the corresponding application node, so that the application node can perform corresponding interrupt processing based on the interrupt information.
10. An electronic device, characterized in that, Includes the interrupt handling system as described in claim 9, used to implement the interrupt handling method as described in any one of claims 1-8.