Hardware event management method and device, electronic device and storage medium

Abstract

This application discloses a hardware event management method, apparatus, electronic device, and storage medium, particularly relating to the field of server technology. The method includes a target controller detecting a hardware event and notifying a baseboard management controller via a pulse signal. The baseboard management controller acquires the event status information and broadcasts it via a process bus. Functional modules can subscribe to corresponding information on demand and process it independently, without relying on a single process for exclusive listening. Therefore, it solves the problems in existing technologies where event processing is centralized, disrupts modular design, has high coupling, low independence and maintainability of functional modules, and limited system scalability and development efficiency due to the requirement of a single process for exclusive listening. This achieves the technical effects of strengthening the modular design of the baseboard management controller, reducing system coupling, improving the independence and maintainability of functional modules, and enhancing system scalability and development efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of server technology, and in particular to a hardware event management method and apparatus, electronic device and storage medium. Background Technology

[0002] At the server's hardware layer, Complex Programmable Logic Devices (CPLDs) are responsible for high-speed signal acquisition and event triggering, typically interacting with the Baseboard Management Controller (BMC) via General Purpose Input / Output (GPIO) signals. In existing technologies, the collaboration mechanism between CPLDs and BMCs has evolved from one-to-one notification across multiple GPIOs to centralized register notification via a single GPIO. Centralized management of multiple event states through event logging registers significantly reduces GPIO resource consumption and enhances hardware design flexibility.

[0003] Currently, because GPIO in Linux systems can typically only be exclusively monitored by a single process, event handling logic must be centralized in a single process, violating the modular design principles of the BMC. This centralized approach not only increases system coupling but also reduces the independence and maintainability of each functional module, limiting the system's scalability and development efficiency. Summary of the Invention

[0004] This disclosure provides a hardware event management method, apparatus, electronic device, and storage medium to at least address the problems in related technologies where centralized processing not only increases system coupling but also reduces the independence and maintainability of each functional module, limiting system scalability and development efficiency.

[0005] This application provides a hardware event management method, including:

[0006] Listen for notification signals indicating hardware events.

[0007] In response to the detection of a notification signal, retrieve the event content;

[0008] The event content is parsed to obtain the event status information of the hardware events that have changed. The event status information includes the event type and the event status.

[0009] The event status information is sent to the corresponding functional module. Different functional modules need to obtain different event status information and execute the target processing flow based on the event status information.

[0010] Optionally, in response to detecting a notification signal, the event content is retrieved, including:

[0011] In response to the detection of a notification signal, the event content recorded in the event log register is read. The event content is recorded in the form of bits, with different bits recording different event types and different record values ​​of bits recording different event states.

[0012] Optionally, the event content can be parsed to obtain the event status information of the hardware events that have changed, including:

[0013] Retrieve the position and value information of the target bit whose value has changed in the event log register;

[0014] Based on the location information of the target bit and the predefined hardware event configuration file, determine the event type of the changed hardware event; and based on the numerical information of the target bit and the predefined hardware event configuration file, determine the event state of the changed hardware event.

[0015] The predefined hardware event configuration file includes the hardware event name, bit position information in the event log register, numerical information, and read / clear attributes.

[0016] Optionally, the event status information can be sent to the corresponding functional module, including:

[0017] Obtain the event status information that each functional module is required to acquire;

[0018] Based on the predetermined event status information, the parsed event status information is sent to the corresponding functional module.

[0019] Optionally, based on the predetermined required event status information, the parsed event status information is sent to the corresponding functional module, including:

[0020] Based on the predetermined event status information, the parsed event status information is broadcast to the corresponding functional modules via the message bus.

[0021] Optionally, hardware event management methods also include:

[0022] Based on a predefined hardware event configuration file, a message bus object corresponding to the hardware event is created. The attribute information of the message bus object includes the hardware event name, bit position information in the event record register, numerical information, status attributes, and read / clear attributes.

[0023] Optionally, hardware event management methods also include:

[0024] Once the message bus object is created, all functional modules are started.

[0025] Based on the event status information required, construct the message bus object path corresponding to each functional module, with each message bus object path pointing to a message bus object.

[0026] Optionally, based on the predetermined required event status information, the parsed event status information is broadcast to the corresponding functional modules via the message bus, including:

[0027] Based on the predetermined event status information, the parsed event status information is sent to the message bus;

[0028] According to the message bus object path, the parsed event status information is sent from the message bus to the corresponding functional module.

[0029] Optionally, based on the predetermined required event status information, the parsed event status information is sent to the message bus, including:

[0030] Based on the parsed event status information, the predefined hardware event configuration file is searched to determine the read / clear attributes corresponding to the parsed event status information.

[0031] Configure the status properties of the message bus object based on the read clear properties;

[0032] The message bus object whose state attributes have changed is converted into event state information, and a bus broadcast signal is generated and sent to the message bus.

[0033] Optionally, configure the status properties of the message bus object based on the read / clear attributes, including:

[0034] If the read clear attribute is the first attribute value, then set the status attribute of the corresponding message bus object according to the event status information obtained from parsing;

[0035] If the read clear attribute is the second attribute value and the record value in the event content is the preset value, then the parsed event state information will be used to set the state attribute of the corresponding message bus object to the first state value.

[0036] Optionally, after setting the state property of the target object to true, the hardware event management method also includes:

[0037] Write the status attribute as the first attribute to the corresponding bit in the event clear register to clear the event flag of the hardware event.

[0038] Optionally, the target processing flow is executed based on the event status information, including:

[0039] Based on the event status information required by the plan, obtain the read / clear attributes and status attributes of the message bus object corresponding to each functional module;

[0040] Based on the read and clear attributes and status attributes, determine whether each functional module should execute the target processing flow, and execute the target processing flow after determining that it should be executed.

[0041] Optionally, based on reading the clear attributes and status attributes, determine whether each functional module executes the target processing flow, including:

[0042] If the clear attribute is the third attribute value and the status attribute is the first status value, then the functional module will execute the corresponding target processing flow.

[0043] If the read clear attribute is the fourth attribute value and the status attribute changes, then the functional module will execute the corresponding target processing flow.

[0044] Optionally, after determining that the read / clear attribute is the third attribute value and the status attribute is the first status value, the hardware event management method further includes:

[0045] In response to the completion of the target processing flow, the status attribute is set to the second status value to clear the event flag of the corresponding hardware event.

[0046] Optionally, hardware event management methods also include:

[0047] Detect whether the target channel sends a notification signal. All hardware events send the generated notification signals through the target channel.

[0048] Optionally, after creating the message bus object corresponding to the hardware event based on the predefined hardware event configuration file, the hardware event management method also includes:

[0049] Obtain the initial event content and use it to update the data of the message bus object.

[0050] This application also provides a hardware event management device, including:

[0051] The monitoring unit is used to listen for notification signals that occur during hardware events.

[0052] The acquisition unit is used to acquire event content in response to the detection of a notification signal;

[0053] The parsing unit is used to parse the event content and obtain the event status information of the hardware event that has changed. The event status information includes the event type and the event status.

[0054] The sending unit is used to send event status information to the corresponding functional modules. Different functional modules need to obtain different event status information and execute the target processing flow based on the event status information.

[0055] Optionally, the acquisition unit is also used for:

[0056] In response to the detection of a notification signal, the event content recorded in the event log register is read. The event content is recorded in the form of bits, with different bits recording different event types and different record values ​​of bits recording different event states.

[0057] Optionally, the parsing unit includes:

[0058] The first acquisition module is used to acquire the position information and value information of the target bit whose value has changed in the event log register;

[0059] The determination module is used to determine the event type of the changed hardware event based on the position information of the target bit and the predefined hardware event configuration file; and to determine the event status of the changed hardware event based on the numerical information of the target bit and the predefined hardware event configuration file.

[0060] The predefined hardware event configuration file includes the hardware event name, bit position information in the event log register, numerical information, and read / clear attributes.

[0061] Optionally, the transmitting unit includes:

[0062] The second acquisition module is used to acquire the event status information that each functional module is required to obtain.

[0063] The sending module is used to send the parsed event status information to the corresponding functional module according to the predetermined event status information.

[0064] Optionally, the sending module is also used for:

[0065] Based on the predetermined event status information, the parsed event status information is broadcast to the corresponding functional modules via the message bus.

[0066] Optionally, the hardware event management device also includes:

[0067] The creation unit is used to create a message bus object corresponding to a hardware event based on a predefined hardware event configuration file. The attribute information of the message bus object includes the hardware event name, bit position information in the event record register, numerical information, status attributes, and read / clear attributes.

[0068] Optionally, the hardware event management device also includes:

[0069] The building unit is used to start each functional module in response to the completion of message bus object creation; based on the predetermined event state information required, it builds the message bus object path corresponding to each functional module, and the message bus object path points to the message bus object.

[0070] Optionally, the sending module is also used for:

[0071] Based on the predetermined event status information, the parsed event status information is sent to the message bus;

[0072] According to the message bus object path, the parsed event status information is sent from the message bus to the corresponding functional module.

[0073] Optionally, the sending module is also used for:

[0074] Based on the parsed event status information, the predefined hardware event configuration file is searched to determine the read / clear attributes corresponding to the parsed event status information.

[0075] Configure the status properties of the message bus object based on the read clear properties;

[0076] The message bus object whose state attributes have changed is converted into event state information, and a bus broadcast signal is generated and sent to the message bus.

[0077] Optionally, the sending module is also used for:

[0078] If the read clear attribute is the first attribute value, then set the status attribute of the corresponding message bus object according to the event status information obtained from parsing;

[0079] If the read clear attribute is the second attribute value and the record value in the event content is the preset value, then the parsed event state information will be used to set the state attribute of the corresponding message bus object to the first state value.

[0080] Optionally, the hardware event management device also includes:

[0081] The write unit is used to write the first attribute status to the corresponding bit in the event clear register after the sending module sets the status attribute of the target object to true, so as to clear the event flag of the hardware event.

[0082] Optionally, the transmitting unit may also include:

[0083] The third acquisition module is used to acquire the read / clear attributes and status attributes of the message bus object corresponding to each functional module according to the predetermined event status information.

[0084] The execution module is used to determine whether each functional module should execute the target processing flow based on the read clear attributes and status attributes, and execute the target processing flow after determining that it should execute.

[0085] Optionally, the execution module is also used for:

[0086] If the clear attribute is the third attribute value and the status attribute is the first status value, then the functional module will execute the corresponding target processing flow.

[0087] If the read clear attribute is the fourth attribute value and the status attribute changes, then the functional module will execute the corresponding target processing flow.

[0088] Optionally, the hardware event management device also includes:

[0089] The setting unit is used to set the status attribute to the second status value after determining that the read clear attribute is the third attribute value and the status attribute is the first status value, in response to the completion of the target processing flow, so as to clear the event flag of the corresponding hardware event.

[0090] Optionally, the hardware event management device also includes:

[0091] The detection unit is used to detect whether the target channel sends a notification signal. All hardware events send the generated notification signals through the target channel.

[0092] Optionally, the hardware event management device also includes:

[0093] The update unit is used to obtain the initial event content and update the message bus object with data using the initial event content after creating the message bus object corresponding to the hardware event based on the predefined hardware event configuration file.

[0094] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described hardware event management methods when executing the computer program.

[0095] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described hardware event management methods.

[0096] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described hardware event management methods.

[0097] This application addresses the issue that, upon detecting a hardware event, the target controller notifies the baseboard management controller via a pulse signal. The baseboard management controller then acquires the event status information and broadcasts it via the process bus. Functional modules can subscribe to the corresponding information and process it independently as needed, without relying on a single process for exclusive GPIO monitoring. Therefore, it solves the problems in the prior art where GPIO in Linux systems can only be exclusively monitored by a single process, leading to centralized event processing, disrupted modular design, high coupling, low independence and maintainability of functional modules, and limited system scalability and development efficiency. This achieves the technical effects of strengthening the modular design of the baseboard management controller, reducing system coupling, improving the independence and maintainability of functional modules, and enhancing system scalability and development efficiency.

[0098] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0099] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0100] Figure 1 A flowchart illustrating a hardware event management method provided in an embodiment of this application;

[0101] Figure 2 This application provides a GPIO notification scheme in its embodiments.

[0102] Figure 3 This is a schematic flowchart of an interrupt handling method provided in an embodiment of this application;

[0103] Figure 4 This is a schematic diagram of an initialization process provided in an embodiment of this application;

[0104] Figure 5 This application provides an embodiment of a listening path construction process.

[0105] Figure 6 This is a schematic diagram illustrating a CPLD register and event notification process provided in an embodiment of this application.

[0106] Figure 7 This application provides a schematic diagram of the structure of a hardware event management device. Detailed Implementation

[0107] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0108] The hardware event management method, apparatus, electronic device, and storage medium of embodiments of the present disclosure are described below with reference to the accompanying drawings.

[0109] Figure 1 This is a flowchart illustrating a hardware event management method provided in an embodiment of the present disclosure.

[0110] like Figure 1 As shown, the method includes the following steps:

[0111] Step 101: Listen for notification signals indicating that a hardware event has occurred.

[0112] In the embodiments of this disclosure, please refer to Figure 2 , Figure 2 A GPIO notification scheme provided in the embodiments of this application, such as Figure 2 As shown, the BMC monitors hardware event notification signals from the CPLD. The CPLD, as a programmable logic device, continuously monitors the critical hardware status on the motherboard. When it detects a hardware event (such as a power state change, abnormal temperature, or abnormal fan operation), it generates a corresponding notification signal. This notification signal is transmitted via a dedicated GPIO interface and is in pulse form, used to trigger the BMC's response mechanism.

[0113] Upon system startup, the BMC initializes a monitoring mechanism for the aforementioned GPIO interfaces, continuously monitoring interface level changes to capture notification signals. This monitoring process continues throughout the system's runtime, ensuring real-time response to hardware event notifications.

[0114] Through a dedicated interface and a continuous monitoring mechanism, efficient capture of hardware event notifications is achieved, avoiding resource waste caused by multiple interfaces occupying resources. At the same time, it provides timely triggering conditions for subsequent event processing, ensuring the system's rapid response capability to hardware events.

[0115] Step 102: In response to the detection of a notification signal, obtain the event content.

[0116] In the embodiments of this disclosure, the acquisition of event content in response to the detection of a notification signal is specifically executed by the BMC. Upon detecting a hardware event notification signal sent by the CPLD via the GPIO interface, a data interaction process with the CPLD is immediately initiated to acquire the event content. The event content is stored in an event recording device within the CPLD. This device uses a bitmap format to centrally record multiple hardware events, with each bit corresponding to an independent hardware event. Setting or clearing a bit indicates the occurrence or termination of the event. The monitoring program accesses the event recording device through a preset communication interface (such as I2C) and reads all currently stored bit status data, using this as the acquired event content.

[0117] By reading the status data of the centralized event logging device, all currently occurring hardware event information can be obtained at once, avoiding the need to query each individual event, reducing the number of communications between the BMC and CPLD, improving the efficiency of event content acquisition, and providing a complete and accurate raw data foundation for subsequent event analysis.

[0118] Step 103: parse the event content to obtain the event status information of the hardware event that has changed. The event status information includes the event type and the event status.

[0119] In the embodiments of this disclosure, the parsing of event content is performed by the parsing module on the BMC side. This module receives the event content (such as bit state data stored in bitmap form) obtained in step 102, and extracts the event state information of the hardware events that have changed through preset parsing rules.

[0120] The parsing process specifically includes: the parsing module retrieves historical event content stored in the event log cache, compares the currently acquired event content bit by bit with the historical event content, and identifies the positions where the bit state has changed—these positions correspond to the hardware events that have changed. Then, based on the preset mapping relationship between bits and event types (i.e., each specific bit uniquely corresponds to one hardware event type), the event type to which the changed event belongs is determined; simultaneously, based on the current state of the bit (e.g., set to 1 or cleared to 0), the event state of the event (e.g., event occurred or event terminated) is determined. Through the above process, the parsing module finally generates event state information containing the event type and event state.

[0121] The technical benefits of this step are: by comparing historical and current event content, it accurately locates hardware events that have changed, avoids ineffective processing of unchanged events, and reduces system resource consumption; at the same time, by clarifying the event type and status through mapping relationships, it provides a standardized data foundation for distributing information to the corresponding functional modules, ensuring the accuracy and relevance of subsequent processing procedures.

[0122] Step 104: Send the event status information to the corresponding functional module. Different functional modules need to obtain different event status information, and execute the target processing flow according to the event status information.

[0123] In the embodiments of this disclosure, event status information is sent to the corresponding functional modules, which then execute the target processing flow. This process is completed collaboratively by the event distribution mechanism at the BMC end and each functional module. The event status information, including the event type and event status, is transmitted through an inter-process communication mechanism within the system. This communication mechanism supports both broadcasting and targeted distribution of information, ensuring that different functional modules only receive event status information relevant to their responsibilities.

[0124] Specifically, after obtaining the parsed event status information, the event distribution mechanism sends the information to the functional module responsible for handling that type of event, based on the preset correspondence between the event type and the functional module. Upon receiving the corresponding event status information, each functional module initiates a preset target processing flow according to the event status (such as whether the event has occurred or been resolved). For example, a cooling control flow for abnormal temperature events or a power management flow for abnormal power supply events. The specific operations of the flow are executed based on the severity of the event and the system's preset strategies.

[0125] The targeted distribution mechanism ensures that event status information is received only by the relevant functional modules, avoiding resource waste caused by redundant information transmission. At the same time, each functional module handles specific events based on its own responsibilities, realizing the specialization and division of labor in event handling, improving the accuracy and efficiency of system response, and enhancing the modularity and maintainability of the overall architecture.

[0126] In this disclosure, there are various specific implementation methods for the operation of "obtaining event content in response to detecting a notification signal". For clarity, the following lists some implementation methods, including but not limited to: in response to detecting a notification signal, reading the event content recorded in the event recording register, the event content is recorded in the form of bits, different bits record different event types, and different recorded values ​​of bits record different event states.

[0127] Specifically, when the CPLD Monitor on the BMC side detects a notification signal from the CPLD (i.e., a pulse signal from the GPIO interface), it immediately accesses the event log register inside the CPLD through a preset communication link (such as the I2C bus) to read the event content recorded therein.

[0128] The event recording register is a 32-bit hardware register that uses a bitmap to centrally record multiple hardware events. Each bit in the register uniquely corresponds to a preset hardware event type (e.g., bit 0 corresponds to an AC exception event, bit 1 corresponds to a CPU high temperature alarm event, etc.). The value of the bit (1 or 0) records the status of the event (1 indicates the event has occurred, 0 indicates the event has been resolved). When the CPLD monitoring program reads the register, it acquires all 32 bits of the complete data at once, thus obtaining a summary record of all current hardware events.

[0129] For events whose deactivation status cannot be detected by the CPLD (such as certain instantaneous trigger events), the corresponding bit in the event log register will remain in a 1 state until the BMC finishes processing and is cleared through the event clear register (32-bit, one-to-one with the event log register, only supports write operations). For events whose deactivation status can be detected by the CPLD, the corresponding bit will automatically update to 0 as the event status changes. However, in the "get event content" operation, the CPLD monitoring program only reads the current value of the event log register and does not involve operations on the event clear register, ensuring the integrity of the original event record.

[0130] In this disclosure, the specific implementation of the operation of "parseting the event content and obtaining the event status information of the changed hardware event" is diverse. For clarity, the following lists some implementation methods, including but not limited to: obtaining the position information and value information of the target bit that has changed in the event recording register; determining the event type of the changed hardware event based on the position information of the target bit and a predefined hardware event configuration file; and determining the event status of the changed hardware event based on the value information of the target bit and the predefined hardware event configuration file; wherein, the predefined hardware event configuration file includes the hardware event name, the bit position information in the event recording register, the value information, and read / clear attributes.

[0131] Specifically, when the CPLD Monitor program on the BMC reads the 32-bit value of the CPLD's internal event log register, it first compares the value bit by bit with the historical value read last time, identifies the bit that has changed (i.e., the target bit), and records the position information of these target bits (such as bit 0, bit 1, etc.) and the current value information (1 or 0).

[0132] Subsequently, the CPLD Monitor calls a predefined hardware event configuration file (this file is in JSON format and contains configuration items corresponding to each bit of the event logging register). For each target bit, the corresponding entry in the configuration file is matched based on its position information. The event type corresponding to the bit is determined by the "name" field contained in the entry (such as "ACFail", "ThermalTrip", etc.). At the same time, based on the current value of the target bit and the preset rules for the event type in the configuration file (a value of 1 indicates that the event has occurred, and a value of 0 indicates that the event has been cleared), the event status of the hardware event is determined. In addition, the configuration file also contains a "read_clear" field, which indicates whether the event needs to be manually cleared through the event clear register after BMC processing. Although this information does not directly participate in the determination of the event type and status, it provides necessary attribute basis for subsequent event processing.

[0133] In this disclosure, there are various specific implementation methods for the operation of "sending event status information to the corresponding functional module". For clarity, the following lists some implementation methods, including but not limited to: obtaining the event status information that each functional module is required to obtain; and sending the parsed event status information to the corresponding functional module according to the event status information that is required to obtain.

[0134] Specifically, after parsing the event status information (including event type and event status), the CPLD monitoring program on the BMC side distributes the information using the D-Bus (inter-process communication mechanism) in the system. Specifically, the CPLD Monitor creates a corresponding object path on the D-Bus based on the event type, with the path format " / com / otrd / cpld_monitor / event / {event name}", and associates it with the interface "com.otrd.cpld_monitor.event". The "Alert" attribute under this interface is used to update the event status in real time (a boolean type, true indicates the event has occurred, false indicates the event has been resolved).

[0135] Upon startup, each functional module (such as the temperature monitoring module and the power monitoring module) dynamically constructs a corresponding D-Bus object path based on the event types it is scheduled to handle, and subscribes to changes in the "Alert" attribute of that path using D-Bus's Match rules. Please refer to [link / reference]. Figure 3 , Figure 3 This is a schematic diagram of an interrupt handling process provided in an embodiment of this application, such as... Figure 3As shown, when the CPLD Monitor updates the "Alert" attribute value, the D-Bus automatically broadcasts the event status information to all functional modules that have subscribed to the signal. Upon receiving the signal, the functional module can then obtain the event status information it has pre-defined.

[0136] In this disclosure, the specific implementation of the operation of "sending the parsed event status information to the corresponding functional module according to the predetermined event status information" is diverse. For clarity, the following lists some implementation methods, including but not limited to: broadcasting the parsed event status information to the corresponding functional module through a message bus according to the predetermined event status information.

[0137] Specifically, the message bus adopts the D-Bus (Desktop Bus) mechanism. After parsing the event status information (including event type and event status), the CPLD monitoring program (CPLDMonitor) creates an object path corresponding to the event type on the D-Bus based on the predefined hardware event configuration file (path format: / com / otrd / cpld_monitor / event / {event name}), and associates it with the interface com.otrd.cpld_monitor.event. This interface contains an Alert attribute (boolean type, used to identify the event status) and a ReadClear attribute (corresponding to the read_clear field in the configuration file).

[0138] The CPLD Monitor registers a dedicated service name, com.otrd.CpldMonitor, on the D-Bus. When event status information is updated, it broadcasts a signal to the D-Bus using this service name. The signal content includes the object path corresponding to the event and the updated Alert attribute value. Upon startup, each functional module subscribes to signals under the corresponding object path according to its pre-defined event types using D-Bus's Match rules (matching conditions include object path, interface name, and Alert attribute). When the CPLD Monitor broadcasts a signal, the D-Bus only forwards the signal to functional modules that have subscribed to that event type, ensuring that each functional module only receives the event status information it pre-determines.

[0139] In this embodiment of the disclosure, the hardware event management method includes other specific implementation steps in addition to the foregoing content. To clearly present these components, the following detailed description of the relevant specific implementation methods is provided: Based on a predefined hardware event configuration file, a message bus object corresponding to the hardware event is created. The attribute information of the message bus object includes the hardware event name, bit position information in the event record register, numerical information, status attributes, and read / clear attributes.

[0140] Specifically, the predefined hardware event configuration file is a JSON file containing core configuration information for the hardware events, including: the bit position of the event record register identified by a numerical index (e.g., "0" represents bit 0), the name of the corresponding hardware event ("name" field, such as "ACFail"), and the attribute indicating whether the event needs to be read and cleared ("read_clear" field, a boolean value). Please refer to [link / reference]. Figure 4 , Figure 4 This is a schematic diagram of an initialization process provided in an embodiment of this application, such as... Figure 4 As shown, the CPLD Monitor program on the BMC side loads the configuration file during the initialization phase, parses each configuration information in it, and creates a corresponding message bus object on the message bus (i.e., D-Bus) for each hardware event based on this.

[0141] The creation of message bus objects follows the D-Bus specification, specifically: each object has a unique object path in the format " / com / otrd / cpld_monitor / event / {hardware event name}" (e.g., " / com / otrd / cpld_monitor / event / ACFail"). This path is directly associated with the hardware event name. The interface associated with the object is "com.otrd.cpld_monitor.event". The attribute information defined in the interface corresponds one-to-one with the configuration file and event log register information, including: hardware event name (implicitly associated through the object path), bit position information in the event log register (corresponding to the numerical index in the configuration file), numerical information (associated with the current value of the bit in the event log register, 1 or 0), status attribute ("Alert" attribute, boolean type, converted from numerical information, 1 corresponds to true indicating that the event has occurred, 0 corresponds to false indicating that the event has been cleared), and read / clear attribute ("ReadClear" attribute, boolean type, directly mapped to the "read_clear" field in the configuration file).

[0142] In this embodiment of the disclosure, the hardware event management method includes other specific implementation steps in addition to the foregoing content. To clearly present these components, the relevant specific implementation methods are described in detail below: In response to the completion of message bus object creation, each functional module is started; according to the predetermined event status information to be obtained, the message bus object path corresponding to each functional module is constructed, and the message bus object path points to the message bus object.

[0143] Specifically, the creation of message bus objects is handled by the CPLD Monitor program on the BMC side. During its initialization process, the CPLD Monitor loads a predefined hardware event configuration file, parses event information, and creates the corresponding message bus object (including object path, interface, and attributes) on the D-Bus (message bus). Once the CPLD Monitor has completed the creation of all message bus objects and registered the service name (com.otrd.CpldMonitor) on the D-Bus, it activates the synchronization point cpld-monitor.target via the systemd mechanism. This synchronization point serves as the startup trigger condition for functional modules. Each functional module (such as the temperature monitoring module and power monitoring module) has "After=cpld-monitor.target" and "Wants=cpld-monitor.target" set in its startup configuration to ensure that it only starts after the message bus object is created, avoiding access failures due to incomplete object preparation.

[0144] After the functional module starts, it dynamically constructs the corresponding message bus object path based on the types of events it needs to process (i.e., the event status information it needs). The path construction follows the same format as when the CPLD Monitor creates message bus objects: " / com / otrd / cpld_monitor / event / {event name}", where the "event name" corresponds one-to-one with the name of the hardware event that the functional module needs to process (such as "ACFail", "ThermalTrip", etc.). This path directly points to the corresponding message bus object already created on the D-Bus, allowing the functional module to access the object's interface and attributes through this path, and thus subscribe to event status information change signals.

[0145] In this disclosure, the specific implementation of the operation of "sending the parsed event status information to the corresponding functional module according to the predetermined event status information" is varied. For clarity, the following lists some implementation methods, including but not limited to: sending the parsed event status information to the message bus according to the predetermined event status information; sending the parsed event status information from the message bus to the corresponding functional module according to the message bus object path.

[0146] Specifically, the message bus adopts D-Bus (inter-process communication mechanism). After parsing the event status information (including event type and event status), the CPLD monitoring program (CPLDMonitor) on the BMC side locates the corresponding message bus object created on D-Bus based on the bit position and name corresponding to the event type in the predefined hardware event configuration file (object path format is " / com / otrd / cpld_monitor / event / {event name}", associated interface "com.otrd.cpld_monitor.event"). CPLD Monitor updates the "Alert" attribute value of this message bus object (boolean type, set to true when the event occurs, and false when the event is resolved) through the standard interface method of D-Bus, and writes the parsed event status information into the message bus.

[0147] Please see Figure 5 , Figure 5 This application provides an embodiment of a listening path construction process, as follows: Figure 5 As shown, after startup, each functional module has constructed a corresponding message bus object path (consistent with the object path format created by CPLD Monitor) based on the event types it needs to process. It then subscribes to change signals of the "Alert" attribute under that path using D-Bus's Match rules (matching conditions include object path, interface name, and attribute identifier). When the message bus (D-Bus) detects an update to the "Alert" attribute value, it automatically addresses the object path and directs the signal of the attribute change to all functional modules that have subscribed to that path, enabling the functional modules to obtain the corresponding event status information.

[0148] In this disclosure, the specific implementation of the operation of "sending the parsed event status information to the message bus according to the predetermined event status information" is diverse. For clarity, the following lists some implementation methods, including but not limited to: searching a predefined hardware event configuration file based on the parsed event status information to determine the read / clear attribute corresponding to the parsed event status information; configuring the status attribute of the message bus object according to the read / clear attribute; converting the event status information of the message bus object whose status attribute has changed, generating a bus broadcast signal and sending it to the message bus.

[0149] Specifically, after parsing and obtaining the event status information (including the event type and the corresponding bit value), the CPLD Monitor will look up a predefined hardware event configuration file (JSON format) based on the event type. In this configuration file, each event type corresponds to a configuration item containing a "read_clear" field (i.e., the read clear attribute), used to indicate whether the event needs to be manually cleared via the event clear register after BMC processing (e.g., "read_clear" is set to true for the "ACFail" event, and false for the "ThermalTrip" event). Based on the found read clear attribute, the CPLD Monitor configures the status attribute ("Alert" attribute, Boolean type) of the corresponding message bus object on the message bus (D-Bus): for events with a read clear attribute of true, if the parsed value is 1 (event occurred), the "Alert" attribute is set to true, and a 1 is written to the corresponding bit in the CPLD's event clear register to clear the event record register's status (avoiding duplicate notifications); if the value is 0 (event canceled, only for events that the CPLD can detect and cancel), the "Alert" attribute is set to false. For events where the clear property is false, the "Alert" property is updated directly based on the numerical information (1 corresponds to true, 0 corresponds to false), without the need for manual clearing.

[0150] When the "Alert" attribute of a message bus object changes, the CPLD Monitor triggers the D-Bus signaling mechanism, converting the status attribute change into a bus broadcast signal. This signal contains the path of the message bus object corresponding to the event (e.g., " / com / otrd / cpld_monitor / event / ACFail"), the interface name ("com.otrd.cpld_monitor.event"), and the updated "Alert" attribute value. This signal is broadcast via the D-Bus bus to ensure that functional modules subscribed to that object path can receive the event status information.

[0151] In this disclosure, the specific implementation of the operation of "configuring the status attribute of the message bus object according to the read clear attribute" is varied. For clarity, the following lists some implementation methods, including but not limited to: if the read clear attribute is a first attribute value, then the status attribute of the corresponding message bus object is set according to the parsed event status information; if the read clear attribute is a second attribute value and the record value in the event content is a preset value, then the parsed event status information is used to set the status attribute of the corresponding message bus object to the first status value.

[0152] Specifically, the first attribute value of the read clear attribute corresponds to the "read_clear" field being true in the predefined hardware event configuration file, meaning the event needs to be manually cleared after processing by the BMC; the second attribute value corresponds to the "read_clear" field being false, meaning the event status can be automatically detected and cleared by the CPLD. The status attribute of the message bus object is the "Alert" attribute (Boolean type) of the D-Bus object, with the first status value being true (indicating an event has occurred). When the read clear attribute is the first attribute value (true), the CPLD monitor sets the "Alert" attribute based on the parsed event status information (including the numerical information of the corresponding bit in the event recording register): if the numerical information is 1 (event has occurred), the "Alert" attribute is set to true; if the numerical information is 0 (event cleared, only applicable to special scenarios where the CPLD can detect the clearing), the "Alert" attribute is set to false. Simultaneously, for the case where the numerical information is 1, the CPLD monitor writes 1 to the corresponding bit in the CPLD's event clear register to clear the status of the event recording register and avoid repeated notification triggering.

[0153] When the read clear attribute is the second attribute value (false), the CPLD Monitor sets the "Alert" attribute of the message bus object to the first state value (true) only if the record value of the corresponding bit in the event content is the preset value (1, i.e., the event has occurred); if the record value is 0 (the event has been cleared), the "Alert" attribute is set to false (the second state value). This process does not require operation of the event clear register, as the CPLD can automatically detect event clearing and update the record register state.

[0154] In this embodiment of the disclosure, the hardware event management method includes other specific implementation steps in addition to the foregoing content. To clearly present these components, the relevant specific implementation methods are described in detail below: After setting the state attribute of the target object to true, the state attribute as the first attribute is written into the corresponding bit in the event clearing register to clear the event flag of the hardware event.

[0155] Specifically, the target object is the message bus object on the message bus (D-Bus) corresponding to the hardware event, and its status attribute is "Alert" (Boolean type). When "Alert" is set to true, it indicates that the corresponding hardware event has occurred. The first attribute corresponds to the attribute value where the "read_clear" field in the predefined hardware event configuration file is true, that is, the hardware event belongs to the type that the CPLD cannot detect and clear the status of (such as AC abnormal events), and the event flag needs to be manually cleared by the BMC after processing.

[0156] When the CPLD Monitor detects a hardware event (corresponding bit in the event log register is 1) and sets the "Alert" attribute of the message bus object to true, it immediately writes data to the CPLD's internal event clear register via a preset communication interface (such as I2C). The event clear register is 32 bits wide, corresponding one-to-one with the bits in the event log register, and only supports write operations. The CPLD Monitor writes a 1 to the corresponding bit in the event clear register based on the bit position of the hardware event in the event log register, triggering the clearing of that bit's status (from 1 to 0), thereby clearing the event flag of the hardware event.

[0157] It should be noted that this operation only applies to events where "read_clear" is true, and the action of writing to the event clear register will not trigger the CPLD's GPIO pulse signal (to avoid generating meaningless interrupts), ensuring that a notification signal is generated only when the hardware event actually occurs or is cleared.

[0158] In this disclosure, the specific implementation of the operation of "executing the target processing flow based on event status information" is diverse. For clarity, the following lists some implementation methods, including but not limited to: obtaining the read / clear attributes and status attributes of the message bus object corresponding to each functional module based on the predetermined event status information; determining whether each functional module should execute the target processing flow based on the read / clear attributes and status attributes, and executing the target processing flow after determining that it should be executed.

[0159] Specifically, after each functional module starts and completes the subscription to the message bus object path, it accesses the interface com.otrd.cpld_monitor.event of the corresponding message bus object (path: / com / otrd / cpld_monitor / event / {event name}) through the GetProperty method of D-Bus to obtain the object's read clear property (ReadClear, corresponding to the read_clear field in the predefined configuration file) and status property (Alert, boolean type). The read clear property indicates whether the event needs to be manually cleared, and the status property indicates whether the event has occurred (true for occurred, false for cleared).

[0160] Based on the above attributes, the functional module determines whether to execute the target processing flow according to the following logic: For events where the read clear attribute is true, the functional module subscribes only to signals where the Alert attribute changes from false to true (i.e., when the event occurs) through the D-Bus Match rules. When this state change is detected, the pre-defined target processing flow is immediately executed (e.g., triggering redundant power supply switching when the power supply is abnormal, starting fan speed regulation after the temperature exceeds the limit, etc.). After processing, the Alert attribute of the corresponding message bus object is set to false using the D-Bus SetProperty method to clear the event flag. For events where the read clear attribute is false, the functional module subscribes to all state changes of the Alert attribute (including changing from true to false, i.e., when the event is resolved). When the attribute value changes, the corresponding processing flow is executed according to the changed state (e.g., recording an alarm log when the event occurs, and updating the state to normal when the event is resolved), without needing to manually clear the Alert attribute.

[0161] In this disclosure, the specific implementation of the operation of "determining whether each functional module executes the target processing flow based on reading the clear attribute and the status attribute" is varied. For clarity, the following lists some implementation methods, including but not limited to: if the read clear attribute is a third attribute value and the status attribute is a first status value, then the functional module is determined to execute the corresponding target processing flow; if the read clear attribute is a fourth attribute value and the status attribute changes, then the functional module is determined to execute the corresponding target processing flow.

[0162] Specifically, the third attribute value of the read clear attribute corresponds to the "read_clear" field being true in the predefined hardware event configuration file, meaning the event needs to be manually cleared after processing by the BMC (such as an AC exception event); the fourth attribute value corresponds to the "read_clear" field being false, meaning the event status can be automatically detected and cleared by the CPLD (such as a CPU high temperature alarm event). The status attribute is the "Alert" attribute of the message bus (D-Bus) object, with the first status value being true (indicating an event has occurred). A change in the status attribute means that the "Alert" attribute value changes from true to false or from false to true.

[0163] When the read clear attribute is the third attribute value (true), the functional module subscribes only to signals where the "Alert" attribute under the corresponding message bus object path changes to the first state value (true) through the D-Bus Match rules. When the CPLD Monitor updates the "Alert" attribute to true, the D-Bus sends a signal to the subscribed functional modules. After detecting this state, the functional module immediately determines to execute the corresponding target processing flow (such as the power monitoring module executing backup power switching logic for AC anomalies).

[0164] When the read clear attribute is the fourth attribute value (false), the functional module subscribes to all state change signals of the "Alert" attribute under the corresponding message bus object path through the D-Bus Match rules. Regardless of whether the "Alert" attribute changes from true to false (event cleared) or from false to true (event occurred), the D-Bus bus will forward the signal to the functional module. After detecting the attribute change, the functional module determines to execute the corresponding target processing flow (e.g., the temperature monitoring module records a high temperature alarm when "Alert" becomes true, and updates the normal status log when it becomes false).

[0165] In this embodiment of the disclosure, the hardware event management method includes other specific implementation steps in addition to the foregoing content. To clearly present these components, the following detailed description of the relevant specific implementation methods is provided: After determining that the read clear attribute is the third attribute value and the status attribute is the first status value, in response to the completion of the target processing flow, the status attribute is set to the second status value to clear the event flag of the corresponding hardware event.

[0166] Specifically, the third attribute value of the read clear attribute corresponds to the "read_clear" field being true in the predefined hardware event configuration file, meaning that the hardware event belongs to the type that needs to be manually cleared by the BMC (such as an AC exception event); the status attribute is the "Alert" attribute of the message bus (D-Bus) object, with the first status value being true (indicating that the event has occurred) and the second status value being false (indicating that the event flag has been cleared).

[0167] Once the functional module determines that the read clear attribute is the third attribute value and the status attribute is the first status value (i.e., the event needs to be manually cleared and has occurred), it executes the corresponding target processing flow (e.g., the power monitoring module initiates backup power switching logic for AC abnormal events). After the target processing flow is completed, the functional module accesses the message bus object corresponding to the event (path: / com / otrd / cpld_monitor / event / {event name}) through the D-Bus SetProperty method and sets its "Alert" attribute from the first status value (true) to the second status value (false).

[0168] This operation is fed back to the CPLD monitoring program (CPLD Monitor) via the D-Bus bus. After the CPLD Monitor recognizes the "Alert" attribute update, it confirms that the functional module has completed the event processing, and then writes 1 to the corresponding bit of the CPLD's event clear register (the event clear register is a 32-bit write-only register, which corresponds one-to-one with the bit of the event record register). Finally, it clears the event flag of the hardware event in the event record register (by setting the corresponding bit from 1 to 0) to ensure that the event will not trigger the notification repeatedly due to the flag not being cleared.

[0169] In this embodiment of the disclosure, the hardware event management method includes other specific implementation steps in addition to the foregoing content. To clearly present these components, the relevant specific implementation methods are described in detail below: Detecting whether the target channel sends a notification signal, and all hardware events send the generated notification signal through the target channel.

[0170] Specifically, the target channel is a dedicated GPIO (General Purpose Input / Output) pin used for transmitting event notification signals between the CPLD and BMC. This pin is the only physical channel through which the CPLD transmits hardware event information to the BMC. Please refer to [link / reference]. Figure 6 , Figure 6 This is a flowchart illustrating a CPLD register and event notification provided in an embodiment of this application, as shown below. Figure 6 As shown, the CPLD, as the main monitoring entity for hardware events, can capture various critical hardware events on the server motherboard in real time (such as abnormal power status, abnormal temperature, fan failure, etc.). When any hardware event occurs, the CPLD sends a notification signal to the BMC through this target channel. The signal is a pulse (level change) that lasts for 1ms. All notification signals for hardware events are transmitted through this single channel and do not depend on other additional channels.

[0171] At the BMC end, the CPLD Monitor is responsible for continuously monitoring the target channel. During system initialization, the CPLD Monitor configures the GPIO pin (including input mode settings and interrupt trigger mode configuration), then enters continuous monitoring mode to track level changes in the target channel in real time. When the CPLD sends a pulse signal through the target channel, the GPIO pin's level changes. The CPLD Monitor captures this change via an interrupt mechanism, confirming that the target channel has sent a notification signal, and thus triggering subsequent event content acquisition and processing.

[0172] In this embodiment of the disclosure, the hardware event management method includes other specific implementation steps in addition to the foregoing content. To clearly present these components, the following detailed description of the relevant specific implementation methods is provided: After creating a message bus object corresponding to a hardware event based on a predefined hardware event configuration file, the initial event content is obtained, and the message bus object is updated with data using the initial event content.

[0173] Specifically, after the CPLD Monitor creates message bus objects (including object paths, interfaces, and attributes) corresponding to all hardware events on the message bus (D-Bus) based on a predefined hardware event configuration file (JSON format), it immediately performs the initial event content retrieval operation. The initial event content comes from the CPLD's internal event record register (32-bit wide, each bit corresponding to one hardware event). The CPLD Monitor reads the initial value of this register through a preset communication interface (such as I2C). This value contains the current status of all hardware events (a bit of 1 indicates that an event has occurred, and a bit of 0 indicates that an event has been resolved).

[0174] Subsequently, the CPLD Monitor parses the initial event content according to the predefined hardware event configuration file: it iterates through each bit of the event record register, and determines the event type corresponding to each bit through the mapping relationship of "bit position - event type" in the configuration file (e.g., bit 0 corresponds to the "ACFail" event); then, combined with the initial value of the bit, it determines the initial state of the event (1 corresponds to the event occurring, 0 corresponds to the event being cleared). After parsing, the CPLD Monitor updates the status attribute ("Alert" attribute, boolean type) of the message bus object: for events with an initial value of 1, the "Alert" attribute of the corresponding message bus object is set to true; for events with an initial value of 0, it is set to false, while ensuring that the "ReadClear" attribute (read clear attribute) is consistent with the "read_clear" field in the configuration file (true or false).

[0175] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0176] Embodiments of this application also provide a hardware event management device. Figure 7 This is a schematic diagram of the structure of a hardware event management device provided in an embodiment of this application, as shown below. Figure 7 Shown, including:

[0177] The monitoring unit 21 is used to monitor notification signals of hardware events.

[0178] Acquisition unit 22 is used to acquire event content in response to the detection of a notification signal;

[0179] The parsing unit 23 is used to parse the event content and obtain the event status information of the hardware event that has changed. The event status information includes the event type and the event status.

[0180] The sending unit 24 is used to send event status information to the corresponding functional module. Different functional modules need to obtain different event status information and execute the target processing flow according to the event status information.

[0181] For a description of the features in the embodiments corresponding to the hardware event management device, please refer to the relevant descriptions in the embodiments corresponding to the hardware event management method, which will not be repeated here.

[0182] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described hardware event management method embodiments.

[0183] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described hardware event management method embodiments when it is run.

[0184] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0185] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described hardware event management method embodiments.

[0186] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described hardware event management method embodiments.

[0187] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0188] The foregoing has provided a detailed description of a hardware event management method, apparatus, electronic device, and storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A hardware event management method, characterized in that, include: Listen for notification signals indicating hardware events. In response to detecting the notification signal, the event content is obtained; The event content is parsed to obtain the event status information of the hardware event that has changed, and the event status information includes the event type and the event status; The event status information is sent to the corresponding functional module. Different functional modules need to obtain different event status information and execute the target processing flow based on the event status information. The step of obtaining event content in response to detecting the notification signal includes: reading the event content recorded in the event recording register in response to detecting the notification signal, wherein the event content is recorded in the form of bits, different bits record different event types, and different recorded values ​​of bits record different event states; Sending the event status information to the corresponding functional module includes: obtaining the event status information that each functional module is required to obtain; and broadcasting the parsed event status information to the corresponding functional module through a message bus according to the required event status information.

2. The hardware event management method according to claim 1, characterized in that, The step of parsing the event content to obtain the event status information of the changed hardware event includes: Obtain the position and value information of the target bit whose value has changed in the event log register; Based on the location information of the target bit and the predefined hardware event configuration file, the event type of the changed hardware event is determined; and based on the numerical information of the target bit and the predefined hardware event configuration file, the event state of the changed hardware event is determined. The predefined hardware event configuration file includes the hardware event name, bit position information in the event record register, numerical information, and read / clear attributes.

3. The hardware event management method according to claim 2, characterized in that, The method further includes: Based on a predefined hardware event configuration file, a message bus object corresponding to the hardware event is created. The attribute information of the message bus object includes the hardware event name, bit position information in the event record register, numerical information, status attributes, and read / clear attributes.

4. The hardware event management method according to claim 3, characterized in that, The method further includes: Upon completion of the message bus object creation, each functional module is started. Based on the predetermined event status information, construct the message bus object path corresponding to each functional module, and the message bus object path points to the message bus object.

5. The hardware event management method according to claim 4, characterized in that, The step of broadcasting the parsed event status information to the corresponding functional modules via a message bus, based on the predetermined event status information, includes: Based on the predetermined event status information required, the parsed event status information is sent to the message bus; According to the message bus object path, the parsed event status information is sent from the message bus to the corresponding functional module.

6. The hardware event management method according to claim 5, characterized in that, The step of sending the parsed event status information to the message bus according to the predetermined event status information includes: Based on the parsed event status information, the predefined hardware event configuration file is searched to determine the read / clear attribute corresponding to the parsed event status information; Configure the status attributes of the message bus object according to the read clear attribute; The message bus object whose state attributes have changed is converted into event state information, and a bus broadcast signal is generated and sent to the message bus.

7. The hardware event management method according to claim 6, characterized in that, The step of configuring the status attributes of the message bus object according to the read clear attribute includes: If the read clear attribute is the first attribute value, then the status attribute of the corresponding message bus object is set according to the event status information obtained by parsing; If the read clear attribute is the second attribute value and the record value in the event content is a preset value, then the parsed event state information will be set to the state attribute of the corresponding message bus object as the first state value.

8. The hardware event management method according to claim 7, characterized in that, After setting the state attribute of the message bus object to a first state value, the method further includes: Write the status attribute as the first attribute to the corresponding bit in the event clear register to clear the event flag of the hardware event.

9. The hardware event management method according to claim 1, characterized in that, The step of executing the target processing flow based on the event status information includes: Based on the event status information required by the plan, obtain the read / clear attributes and status attributes of the message bus object corresponding to each functional module; Based on the read clear attribute and the status attribute, determine whether each functional module should execute the target processing flow, and execute the target processing flow after determining that it should be executed.

10. The hardware event management method according to claim 9, characterized in that, The step of determining whether each functional module executes the target processing flow based on the read clear attribute and the status attribute includes: If the read clear attribute is a third attribute value and the status attribute is a first status value, then the functional module is determined to execute the corresponding target processing flow; If the read clear attribute is the fourth attribute value and the status attribute changes, then the functional module is determined to execute the corresponding target processing flow.

11. The hardware event management method according to claim 10, characterized in that, After determining that the read clear attribute is a third attribute value and the status attribute is a first status value, the method further includes: In response to the completion of the target processing flow, the status attribute is set to the second status value to clear the event flag of the corresponding hardware event.

12. The hardware event management method according to claim 1, characterized in that, The method further includes: The system detects whether the target channel sends the notification signal, and all hardware events send the generated notification signal through the target channel.

13. The hardware event management method according to claim 3, characterized in that, After creating the message bus object corresponding to the hardware event based on the predefined hardware event configuration file, the method further includes: Obtain the initial event content and use the initial event content to update the data of the message bus object.

14. A hardware event management device, characterized in that, include: The monitoring unit is used to listen for notification signals that occur during hardware events. The acquisition unit is configured to acquire event content in response to detecting the notification signal; The parsing unit is used to parse the event content and obtain the event status information of the hardware event that has changed, the event status information including the event type and the event status; The sending unit is used to send the event status information to the corresponding functional module. Different functional modules need to obtain different event status information and execute the target processing flow according to the event status information. The acquisition unit is further configured to: in response to detecting the notification signal, read the event content recorded in the event recording register, wherein the event content is recorded in the form of bits, different bits record different event types, and different recorded values ​​of bits record different event states; The sending unit is further configured to: obtain event status information that each functional module is required to acquire; and send the parsed event status information to the corresponding functional module according to the predetermined event status information, including: broadcasting the parsed event status information to the corresponding functional module through a message bus according to the predetermined event status information.

15. An electronic device, characterized in that, include: at least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the hardware event management method according to any one of claims 1-13.

16. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to execute the hardware event management method according to any one of claims 1-13.

17. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the hardware event management method according to any one of claims 1-13.

Images