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

Abstract

The invention discloses a hardware event management method and device, electronic equipment and a storage medium, and particularly relates to the technical field of servers, and the method comprises the steps that a target controller informs a substrate management controller through a pulse signal after detecting a hardware event, the substrate management controller obtains event state information and broadcasts the event state information through a process bus, and the process bus broadcasts the event state information; the function module can subscribe the corresponding information according to needs and process the information independently without depending on single-process exclusive monitoring. The problems of centralized event processing, damage to modular design, high coupling degree, low independence and maintainability of functional modules, and limited system expansion capability and development efficiency caused by exclusive monitoring of a single process in the prior art can be solved. The technical effects of enhancing the modular design of the substrate management controller, reducing the system coupling degree, improving the independence and maintainability of the functional module, and enhancing the system expansion capability and development efficiency are achieved.

Description

Technical Field

[0001] The present disclosure relates to the field of server technology, and in particular to a hardware event management method and device, an electronic device, and a storage medium. Background Art

[0002] At the server hardware level, Complex Programmable Logic Devices (CPLDs) are responsible for high-speed signal acquisition and event triggering, typically interacting with the Baseboard Management Controller (BMC) through General Purpose Input / Output (GPIO) signals. Existing technologies have evolved the collaboration mechanism between CPLDs and BMCs from one-to-one notifications across multiple GPIOs to centralized register notifications for a single GPIO. This centralized management of multiple event states through event log registers significantly reduces GPIO resource usage and increases hardware design flexibility.

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

[0004] The present disclosure provides a hardware event management method and device, an electronic device and a storage medium, so as to at least solve the problem in the related art that the centralized processing method not only increases the system coupling degree, but also reduces the independence and maintainability of each functional module, thereby limiting the system's expansion capability and development efficiency.

[0005] This application provides a hardware event management method, including: Monitor notification signals of hardware events; In response to detecting the notification signal, obtaining event content; Parse the event content to obtain event status information of the changed hardware event, including event type and 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 according to the event status information.

[0006] Optionally, in response to detecting the notification signal, obtaining event content includes: In response to detecting the notification signal, the event content recorded in the event record register is read. The event content is recorded in the form of bits. Different bits record different event types, and different recorded values ​​of the bits record different event states.

[0007] Optionally, parse the event content to obtain event status information of the changed hardware event, including: Obtain the position information and value information of the target bit whose value in the event record register has changed; Determining 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 determining the event state of the changed hardware event based on the value information of the target bit and the predefined hardware event configuration file; The predefined hardware event configuration file includes a hardware event name, bit position information in an event record register, value information, and read / clear attributes.

[0008] Optionally, the event status information is sent to the corresponding functional module, including: Obtain the event status information required by each functional module; According to the predetermined event status information required, the event status information obtained by parsing is sent to the corresponding functional module.

[0009] Optionally, according to the predetermined event status information to be obtained, the event status information obtained by parsing is sent to the corresponding functional module, including: According to the predetermined event status information required, the event status information obtained by parsing is broadcast to the corresponding functional module through the message bus.

[0010] Optionally, the hardware event management method further includes: Based on the 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, value information, status attribute and read clear attribute.

[0011] Optionally, the hardware event management method further includes: In response to the message bus object being created, each functional module is started; According to the event status information that needs to be obtained, a message bus object path corresponding to each functional module is constructed, and the message bus object path points to the message bus object.

[0012] Optionally, according to the predetermined event status information to be obtained, the event status information obtained by parsing is broadcast to the corresponding functional module through the message bus, including: According to the event status information required by the reservation, the event status information obtained by parsing is sent to the message bus; According to the message bus object path, the event status information obtained by parsing is sent from the message bus to the corresponding functional module.

[0013] Optionally, according to the predetermined event status information to be obtained, the event status information obtained by parsing is sent to the message bus, including: Searching a predefined hardware event configuration file based on the parsed event status information, and determining a read and clear attribute corresponding to the parsed event status information; Configure the status attributes of the message bus object according to the read and clear attributes; The message bus object whose state attribute has changed is converted into event state information, and a bus broadcast signal is generated and sent to the message bus.

[0014] Optionally, configure the state properties of the message bus object based on the read and clear properties, including: If the read clear attribute is the first attribute value, then setting the status attribute of the corresponding message bus object 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 the preset value, the state attribute of the message bus object corresponding to the event state information obtained by parsing is set to the first state value.

[0015] Optionally, after setting the status attribute of the target object to true, the hardware event management method further includes: The state attribute is written as the first attribute into the corresponding bit in the event clear register to clear the event flag of the hardware event.

[0016] Optionally, execute the target processing flow based on the event status information, including: According to the event status information required to be obtained, the read and clear attributes and status attributes of the message bus object corresponding to each functional module are obtained; Based on the read clear attribute and the status attribute, it is determined whether each functional module executes the target processing flow, and the target processing flow is executed after it is determined to execute.

[0017] Optionally, based on the read clear attribute and the status attribute, determining whether each functional module executes the target processing flow includes: If the read clear attribute is the third attribute value and the state attribute is the first state value, then determining that the function module executes the corresponding target processing flow; If the read clear attribute is the fourth attribute value and the state attribute changes, the function module is determined to execute the corresponding target processing flow.

[0018] Optionally, after determining that the read clear attribute is the third attribute value and the state attribute is the first state value, the hardware event management method further includes: In response to the target processing flow being completed, the state attribute is set to a second state value to clear the event flag corresponding to the hardware event.

[0019] Optionally, the hardware event management method further includes: Detect whether the target channel sends a notification signal. All hardware events send the notification signal generated by the target channel.

[0020] Optionally, after creating a message bus object corresponding to the hardware event based on the predefined hardware event configuration file, the hardware event management method further includes: Get the initial event content and use it to update the data of the message bus object.

[0021] This application also provides a hardware event management device, including: A monitoring unit, used to monitor notification signals of hardware events; an acquiring unit, configured to acquire event content in response to detecting the notification signal; A parsing unit, configured to parse the event content and obtain event status information of the changed hardware event, wherein the event status information includes the event type and 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.

[0022] Optionally, the acquisition unit is further configured to: In response to detecting the notification signal, the event content recorded in the event record register is read. The event content is recorded in the form of bits. Different bits record different event types, and different recorded values ​​of the bits record different event states.

[0023] Optionally, the parsing unit includes: The first acquisition module is used to obtain the position information and value information of the target bit whose value in the event record register has changed; a determination module for determining an event type of the changed hardware event based on the position information of the target bit and the predefined hardware event configuration file; and determining an event state of the changed hardware event based on the value information of the target bit and the predefined hardware event configuration file; The predefined hardware event configuration file includes a hardware event name, bit position information in an event record register, value information, and read / clear attributes.

[0024] Optionally, the sending unit includes: The second acquisition module is used to obtain the event status information that each functional module needs to obtain; The sending module is used to send the event status information obtained by parsing to the corresponding functional module according to the event status information required to be obtained.

[0025] Optionally, the sending module is further configured to: According to the predetermined event status information required, the event status information obtained by parsing is broadcast to the corresponding functional module through the message bus.

[0026] Optionally, the hardware event management device further includes: The creation unit is used to create a message bus object corresponding to the 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 and clear attributes.

[0027] Optionally, the hardware event management device further includes: The construction unit is used to start each functional module in response to the completion of the message bus object creation; and to construct the message bus object path corresponding to each functional module according to the predetermined event status information required, and the message bus object path points to the message bus object.

[0028] Optionally, the sending module is further configured to: According to the event status information required by the reservation, the event status information obtained by parsing is sent to the message bus; According to the message bus object path, the event status information obtained by parsing is sent from the message bus to the corresponding functional module.

[0029] Optionally, the sending module is further configured to: Searching a predefined hardware event configuration file based on the parsed event status information, and determining a read and clear attribute corresponding to the parsed event status information; Configure the status attributes of the message bus object according to the read and clear attributes; The message bus object whose state attribute has changed is converted into event state information, and a bus broadcast signal is generated and sent to the message bus.

[0030] Optionally, the sending module is further configured to: If the read clear attribute is the first attribute value, then setting the status attribute of the corresponding message bus object 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 the preset value, the state attribute of the message bus object corresponding to the event state information obtained by parsing is set to the first state value.

[0031] Optionally, the hardware event management device further includes: The writing unit is used to write the state attribute as the first attribute into the corresponding bit in the event clear register after the sending module sets the state attribute of the target object to true, so as to clear the event flag of the hardware event.

[0032] Optionally, the sending unit further includes: The third acquisition module is used to obtain the read and clear attributes and status attributes of the message bus object corresponding to each functional module according to the predetermined event status information to be obtained; The execution module is used to determine whether each functional module executes the target processing flow based on the read clear attribute and the status attribute, and execute the target processing flow after determining to execute.

[0033] Optionally, the execution module is further configured to: If the read clear attribute is the third attribute value and the state attribute is the first state value, then determining that the function module executes the corresponding target processing flow; If the read clear attribute is the fourth attribute value and the state attribute changes, the function module is determined to execute the corresponding target processing flow.

[0034] Optionally, the hardware event management device further includes: The setting unit is used to set the state attribute to the second state value in response to the completion of the target processing flow after determining that the read clear attribute is the third attribute value and the state attribute is the first state value, so as to clear the event flag of the corresponding hardware event.

[0035] Optionally, the hardware event management device further includes: The detection unit is used to detect whether the target channel sends a notification signal. All hardware events send notification signals generated by the target channel.

[0036] Optionally, the hardware event management device further includes: The updating unit is used to obtain the initial event content after creating the message bus object corresponding to the hardware event based on the predefined hardware event configuration file, and update the data of the message bus object using the initial event content.

[0037] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned hardware event management methods when executing the computer program.

[0038] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned hardware event management methods are implemented.

[0039] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned hardware event management methods when executed by a processor.

[0040] Through this application, since the target controller notifies the baseboard management controller through a pulse signal after detecting a hardware event, the baseboard management controller obtains event status information and broadcasts it through the process bus. The functional module can subscribe to the corresponding information on demand and process it independently without relying on the exclusive monitoring of a single process of GPIO. Therefore, it can solve the problems in the existing technology such as centralized event processing, destruction of modular design, high coupling, low independence and maintainability of functional modules, and limited system expansion capabilities and development efficiency caused by the fact that GPIO can only be exclusively monitored by a single process in the Linux system. The technical effect of strengthening the modular design of the baseboard management controller, reducing the system coupling, improving the independence and maintainability of functional modules, and enhancing the system expansion capabilities and development efficiency is achieved.

[0041] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present disclosure, nor are they intended to limit the scope of the present disclosure. Other features of the present disclosure will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The accompanying drawings are provided to facilitate a better understanding of the present invention and do not constitute a limitation of the present disclosure. Figure 1 A flowchart of a hardware event management method provided in an embodiment of the present application; Figure 2 A GPIO notification solution provided in an embodiment of the present application; Figure 3 A schematic diagram of an interrupt processing flow provided in an embodiment of the present application; Figure 4 A schematic diagram of an initialization process provided in an embodiment of the present application; Figure 5 This is an intention of a monitoring path construction process provided by an embodiment of the present application; Figure 6 A schematic diagram of a CPLD register and event notification process provided in an embodiment of the present application; Figure 7 A schematic structural diagram of a hardware event management device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] The following description of exemplary embodiments of the present disclosure is made in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding. These details should be considered as merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

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

[0045] Figure 1 A flowchart of a hardware event management method provided by an embodiment of the present disclosure.

[0046] like Figure 1 As shown, the method comprises the following steps: Step 101: monitor the notification signal of the hardware event.

[0047] In the embodiments of the present disclosure, please refer to Figure 2 , Figure 2 A GPIO notification solution provided in an embodiment of the present application is as follows: Figure 2 As shown in the figure, the BMC monitors hardware event notification signals from the CPLD. As a programmable logic device, the CPLD continuously monitors the status of key hardware on the motherboard. When it detects a hardware event (such as a power status change, abnormal temperature, or abnormal fan status), it generates a corresponding notification signal. This notification signal is transmitted as a pulse signal through a dedicated GPIO interface, triggering the BMC's response mechanism.

[0048] The BMC initiates a monitoring mechanism for the GPIO interface upon system startup, continuously monitoring the interface's voltage level changes to capture notification signals. This monitoring process continues throughout the system's operating cycle, ensuring real-time response to hardware event notifications.

[0049] Through dedicated interfaces and continuous monitoring mechanisms, efficient capture of hardware event notifications is achieved, avoiding resource waste caused by multiple interface occupations. At the same time, timely trigger conditions are provided for subsequent event processing processes, ensuring the system's ability to respond quickly to hardware events.

[0050] Step 102: In response to detecting the notification signal, obtain event content.

[0051] In an embodiment of the present disclosure, the event content is obtained in response to the detection of a notification signal, which is specifically executed by the BMC. After the hardware event notification signal sent by the CPLD is detected through the GPIO interface, the data interaction process with the CPLD is immediately started to obtain the event content. The event content is stored in an event recording device inside the CPLD. The device uses a bitmap to centrally record multiple hardware events. Each bit corresponds to an independent hardware event, and the occurrence or release status of the event is indicated by setting or clearing the bit. The monitoring program accesses the event recording device through a preset communication interface (such as I2C) and reads all the bit status data currently stored therein as the acquired event content.

[0052] By reading the status data of the centralized event recording device, all current hardware event information can be obtained at one time, avoiding the need to query individual events one by one, 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 basis for subsequent event analysis.

[0053] Step 103: parse the event content to obtain event status information of the changed hardware event, where the event status information includes event type and event status.

[0054] In an embodiment of the present disclosure, the parsing of the event content is performed by a parsing module on the BMC side, which receives the event content obtained in step 102 (such as bit status data stored in bitmap form) and extracts the event status information of the changed hardware event through preset parsing rules.

[0055] The parsing process specifically involves the following: the parsing module accesses the historical event content stored in the event record cache, compares the currently acquired event content with the historical event content bit by bit, and identifies the locations where the bit state has changed—these locations correspond to the hardware events that have changed. Subsequently, based on the preset mapping relationship between bits and event types (i.e., each specific bit uniquely corresponds to a hardware event type), the event type to which the changed event belongs is determined; at the same time, based on the current state of the bit (e.g., set to 1 or cleared to 0), the event status of the event (e.g., event occurrence or event resolution) is determined. Through the above process, the parsing module ultimately generates event status information containing the event type and event status.

[0056] The technical effect of this step is: by comparing historical and current event content, the changed hardware events can be accurately located, invalid processing of unchanged events can be avoided, and system resource consumption can be reduced; at the same time, the event type and status can be clarified through mapping relationships, providing a standardized data basis for the subsequent distribution of information to the corresponding functional modules, ensuring the accuracy and pertinence of the subsequent processing flow.

[0057] 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.

[0058] In the disclosed embodiments, event status information is sent to the corresponding functional modules, which then execute the target processing flow. This is accomplished through the BMC's event distribution mechanism and the collaboration of each functional module. The event status information, including the event type and event status, is transmitted through the system's internal inter-process communication mechanism. This communication mechanism supports both broadcast and targeted information distribution, ensuring that different functional modules only receive event status information relevant to their responsibilities.

[0059] Specifically, after obtaining parsed event status information, the event distribution mechanism sends this information to the functional module responsible for handling that type of event based on the pre-set correspondence between event type and functional module. Upon receiving the corresponding event status information, each functional module initiates the pre-set target processing flow based on the event status (e.g., event occurrence or resolution). For example, this flow involves cooling control for abnormal temperature events or power management for abnormal power events. The specific actions of the flow are determined by the severity of the event and the system's pre-set policies.

[0060] Through the targeted distribution mechanism, event status information is ensured to be received only by relevant functional modules, thus avoiding the waste of resources 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 processing, improving the accuracy and efficiency of system response, and enhancing the modularity and maintainability of the overall architecture.

[0061] In the embodiment of the present disclosure, the specific implementation methods of the operation of "obtaining event content in response to detecting a notification signal" are diverse. For the purpose of clear explanation, the following lists, including but not limited to, some implementation methods: in response to detecting a notification signal, reading the event content recorded in the event record register, and the event content is recorded in the form of bits, different bits record different event types, and different recorded values ​​of the bits record different event states.

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

[0063] The event log register is a 32-bit hardware register that uses a bitmap format 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 abnormality event, bit 1 corresponds to a CPU high-temperature alarm event, etc.). The bit value (1 or 0) records the status of the event (1 indicates the event has occurred, 0 indicates the event has resolved). When reading, the CPLD monitoring program obtains the complete 32-bit data from this register at once, resulting in a summary record of all current hardware events.

[0064] For events whose release status the CPLD cannot detect independently (such as certain instantaneous trigger events), the corresponding bit in the event record register remains 1 until the BMC completes processing and clears it through the event clear register (32 bits, one-to-one with the event record register, and supports only write operations). For events whose release status the CPLD can detect, the corresponding bit automatically updates to 0 as the event status changes. However, during the "Get Event Content" operation, the CPLD monitoring program only reads the current value of the event record register and does not operate on the event clear register, ensuring the integrity of the original event record.

[0065] In the embodiment of the present disclosure, the specific implementation methods for the operation of "parsing the event content and obtaining the event status information of the changed hardware event" are diverse. For the purpose of clear explanation, the following lists but are not limited to some implementation methods: obtaining the position information and numerical information of the target bit whose value has changed in the event record register; determining 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 determining the event status of the changed hardware event based on the numerical 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 record register, the numerical information and the read and clear attributes.

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

[0067] The CPLD Monitor then calls the predefined hardware event configuration file (in JSON format, it contains configuration items that correspond one-to-one to each bit in the event record register). For each target bit, the corresponding entry in the configuration file is matched based on its location information. The event type corresponding to the bit (such as "ACFail," "ThermalTrip," etc.) is determined using the "name" field contained in the entry. At the same time, based on the current numerical value of the target bit and the preset rules for this 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 resolved), 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 determine the event type and status, it provides the necessary attribute basis for the subsequent event processing process.

[0068] In the embodiment of the present disclosure, there are various specific implementation methods for the operation of "sending event status information to the corresponding functional module". For the purpose of clear explanation, the following includes but is not limited to some implementation methods: obtaining the event status information that each functional module needs to obtain; according to the event status information that needs to be obtained, sending the parsed event status information to the corresponding functional module.

[0069] Specifically, after the BMC's CPLD monitor program (CPLD Monitor) parses event status information (including event type and status), it distributes this information via the system's D-Bus (inter-process communication) mechanism. Specifically, the CPLD Monitor creates a corresponding object path on D-Bus based on the event type. The path format is " / com / otrd / cpld_monitor / event / {event name}" and associates it with the interface "com.otrd.cpld_monitor.event." The "Alert" property of this interface is used to update the event status in real time (a Boolean value of true indicates an event has occurred, and false indicates the event has resolved).

[0070] When each functional module (such as the temperature monitoring module, power monitoring module, etc.) is started, it will dynamically build the corresponding D-Bus object path according to the event type it needs to process, and subscribe to the change signal of the "Alert" attribute under the path through the D-Bus Match rule. Figure 3 , Figure 3 A flowchart of an interrupt processing provided by an embodiment of the present application is shown as follows: Figure 3As shown in Figure 1, when the CPLD Monitor updates the "Alert" attribute value, D-Bus automatically broadcasts the event status information to all functional modules that subscribe to the signal. After receiving the signal, the functional modules can obtain the event status information they need.

[0071] In the embodiment of the present disclosure, the specific implementation methods of the operation of "sending the event status information obtained by parsing to the corresponding functional module according to the event status information required to be obtained in advance" are diverse. For the purpose of clear explanation, the following lists but are not limited to some implementation methods: according to the event status information required to be obtained in advance, the event status information obtained by parsing is broadcast to the corresponding functional module through the message bus.

[0072] Specifically, the message bus uses the D-Bus (Desktop Bus) mechanism. After parsing event status information (including event type and event status), the CPLD monitor (CPLDMonitor) creates an object path corresponding to the event type on D-Bus (the path format is / com / otrd / cpld_monitor / event / {event name}) based on a predefined hardware event configuration file. It also associates the interface com.otrd.cpld_monitor.event with the Alert attribute (a Boolean type used to identify the event status) and the ReadClear attribute (corresponding to the read_clear field in the configuration file).

[0073] 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 bus using this service name. The signal contains the object path corresponding to the event and the updated Alert attribute value. Upon startup, each functional module subscribes to the signal corresponding to the object path using D-Bus's Match rules, based on the event type it plans to handle. (Match criteria include the object path, interface name, and Alert attribute.) When the CPLD Monitor broadcasts a signal, the D-Bus bus forwards it only to the functional modules that have subscribed to that event type, ensuring that these functional modules receive only the event status information they need.

[0074] In the embodiment of the present disclosure, in addition to the aforementioned contents, the hardware event management method also includes other specific implementation steps. In order to clearly present these components, the relevant specific implementation methods are described in detail below: Based on the 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 and clear attributes.

[0075] Specifically, the predefined hardware event configuration file is a JSON format file, which contains the core configuration information of the hardware event, including: the bit position of the event record register identified by a numerical index (such as "0" represents the 0th bit), the name of the corresponding hardware event ("name" field, such as "ACFail"), and the attribute of whether the event needs to be cleared after reading ("read_clear" field, Boolean value). Figure 4 , Figure 4 This is a schematic diagram of an initialization process provided by an embodiment of the present application, such as Figure 4 As shown in the figure, the CPLD monitor program (CPLD Monitor) on the BMC side loads the configuration file during the initialization phase, parses each configuration information therein, and creates a corresponding message bus object for each hardware event on the message bus (i.e., D-Bus) based on the information.

[0076] The creation of message bus objects follows the D-Bus specification. Specifically, each object has a unique object path in the format of " / com / otrd / cpld_monitor / event / {hardware event name}" (for example, " / com / otrd / cpld_monitor / event / ACFail"). This path is directly associated with the hardware event name. The object is associated with the interface "com.otrd.cpld_monitor.event". The attributes defined in this interface correspond one-to-one with the configuration file and event record register information, including: the hardware event name (implicitly associated through the object path), the bit position in the event record register (corresponding to the numeric index in the configuration file), the value (associated with the current value of the bit in the event record register, 1 or 0), the status attribute (the "Alert" attribute, a Boolean type, converted from the value information; 1 corresponds to true when the event occurs, and 0 corresponds to false when the event is resolved), and the read clear attribute (the "ReadClear" attribute, a Boolean type, directly mapped to the "read_clear" field in the configuration file).

[0077] In the embodiment of the present disclosure, in addition to the aforementioned contents, the hardware event management method also includes other specific implementation steps. In order to clearly present these components, the relevant specific implementation methods are described in detail below: in response to the completion of the creation of the message bus object, each functional module is started; according to the predetermined event status information required 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.

[0078] Specifically, the CPLD Monitor on the BMC creates message bus objects. During initialization, it loads a predefined hardware event configuration file, parses event information, and creates corresponding message bus objects (including object paths, interfaces, and properties) on the D-Bus (message bus). Once the CPLD Monitor completes the creation of all message bus objects and registers the service name (com.otrd.CpldMonitor) on D-Bus, it activates the synchronization point cpld-monitor.target through the systemd mechanism. This synchronization point triggers the startup of functional modules. Each functional module (such as the temperature monitoring module and the power supply monitoring module) has "After=cpld-monitor.target" and "Wants=cpld-monitor.target" configured in its startup configuration to ensure that it starts only after message bus object creation is complete, preventing access failures due to object unreadiness.

[0079] After the function module starts, it dynamically constructs a corresponding message bus object path based on the event type it plans to handle (that is, the event status information it plans to handle). This path follows the same format as the CPLD Monitor uses when creating message bus objects: " / com / otrd / cpld_monitor / event / {event name}," where "event name" corresponds exactly to the hardware event name the function module plans to handle (such as "ACFail" or "ThermalTrip"). This path directly points to the corresponding message bus object created on the D-Bus, allowing the function module to access the object's interfaces and properties through this path and subscribe to event status change signals.

[0080] In the embodiments of the present disclosure, the specific implementation methods of the operation of "sending the event status information obtained by parsing to the corresponding functional module according to the event status information required to be obtained in advance" are diverse. For the purpose of clear explanation, the following lists but are not limited to some implementation methods: sending the event status information obtained by parsing to the message bus according to the event status information required to be obtained in advance; sending the event status information obtained by parsing from the message bus to the corresponding functional module according to the message bus object path.

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

[0082] See also Figure 5 , Figure 5 This is a monitoring path construction process provided by the embodiment of the present application, such as Figure 5 As shown in the figure, after startup, each functional module has constructed a corresponding message bus object path (consistent with the object path format created by the CPLD Monitor) based on the event type it needs to handle. It then subscribes to the change signal of the "Alert" attribute under this path using the D-Bus match rule (the matching criteria include the 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 sends the attribute change signal to all functional modules subscribed to the path, allowing the functional modules to obtain the corresponding event status information.

[0083] In the embodiment of the present disclosure, for the operation of "sending the parsed event status information to the message bus according to the predetermined event status information required", the specific implementation methods are diverse. For the purpose of clear explanation, the following includes but is not limited to some implementation methods: searching for a predefined hardware event configuration file based on the parsed event status information, determining the read and clear attributes corresponding to the parsed event status information; configuring the status attributes of the message bus object according to the read and clear attributes; converting the event status information of the message bus object whose status attributes have changed, generating a bus broadcast signal and sending it to the message bus.

[0084] Specifically, after the CPLD Monitor parses event status information (including the event type and corresponding bit values), it searches a predefined hardware event configuration file (JSON format) based on the event type. Each event type corresponds to a configuration item in this configuration file, including a "read_clear" field (the read-clear attribute), which indicates whether the event needs to be manually cleared through the event clear register after BMC processing (for example, setting "read_clear" to true for an "ACFail" event and false for a "ThermalTrip" event). Based on the read-clear attribute found, the CPLD Monitor configures the status attribute (the "Alert" Boolean attribute) of the corresponding message bus object on the 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 the corresponding bit in the CPLD's event clear register is written to 1 to clear the event record register (to avoid duplicate notifications). If the value is 0 (event cleared, only for events that the CPLD can detect), the "Alert" attribute is set to false. For events where the read clear attribute is false, the "Alert" attribute is directly updated according to the numerical information (1 corresponds to true, 0 corresponds to false), without manual clearing.

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

[0086] In the embodiment of the present disclosure, the specific implementation methods of the operation of "configuring the status attribute of the message bus object according to the read clear attribute" are diverse. For the purpose of clearing the description, the following includes but is not limited to some implementation methods: if the read clear attribute is a first attribute value, 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 a second attribute value and the record value in the event content is a preset value, the status attribute of the corresponding message bus object is set to the first status value according to the event status information obtained by parsing.

[0087] Specifically, the first attribute value of the read-clear attribute corresponds to the "read_clear" field in the predefined hardware event configuration file being true, indicating that the event must be manually cleared after being processed by the BMC. The second attribute value corresponds to the "read_clear" field being false, indicating that the event status can be automatically cleared by the CPLD. The status attribute of the message bus object is the "Alert" attribute (Boolean type) of the D-Bus object, and its first status value is true (indicating that an event has occurred). When the read-clear attribute has the first attribute value (true), the CPLD monitor (CPLD Monitor) sets the "Alert" attribute based on the parsed event status information (including the value of the corresponding bit in the event record register). If the value is 1 (event has occurred), the "Alert" attribute is set to true; if the value is 0 (event has been cleared, applicable only in special scenarios where the CPLD can detect and clear the event), the "Alert" attribute is set to false. Furthermore, if the value is 1, the CPLD Monitor writes a 1 to the corresponding bit in the CPLD's event clear register to clear the event record register status and prevent repeated notification triggering.

[0088] When the clear attribute is read as the second attribute value (false), the CPLD Monitor sets the message bus object's "Alert" attribute to the first state value (true) only when the recorded value of the corresponding bit in the event content is the preset value (1, indicating an event has occurred). If the recorded value is 0 (the event has been resolved), 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 automatically detects the event resolution and updates the record register status.

[0089] In the embodiment of the present disclosure, in addition to the aforementioned contents, the hardware event management method also includes other specific implementation steps. In order to clearly present these components, the relevant specific implementation methods are described in detail below: After setting the status attribute of the target object to true, the status attribute is written as the first attribute to the corresponding bit in the event clear register to clear the event flag of the hardware event.

[0090] Specifically, the target object is a message bus object on the 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 "read_clear" field in the predefined hardware event configuration file being set to true, indicating that the hardware event is of a type that the CPLD cannot automatically detect and clear (such as an AC abnormality event). The event flag must be manually cleared after processing by the BMC.

[0091] When the CPLD monitor detects a hardware event (the corresponding bit in the event record register is set to 1) and sets the "Alert" property of the message bus object to true, it immediately writes data to the event clear register within the CPLD through a predefined communication interface (such as I2C). The event clear register is 32 bits wide, corresponds one-to-one with the bits in the event record register, and supports only write operations. Based on the bit position of the hardware event in the event record register, the CPLD monitor writes a 1 to the corresponding bit in the event clear register, triggering the clearing of the bit in the event record register (from 1 to 0), thereby clearing the event flag for the hardware event.

[0092] 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 GPIO pulse signal of the CPLD (to avoid generating meaningless interrupts), ensuring that the notification signal is generated only when the hardware event actually occurs or is released.

[0093] In the embodiment of the present disclosure, the specific implementation methods of the operation of "executing the target processing flow according to the event status information" are diverse. For the purpose of clear explanation, the following includes but is not limited to some implementation methods: according to the event status information required to be obtained in advance, the read and clear attributes and status attributes of the message bus object corresponding to each functional module are obtained; based on the read and clear attributes and status attributes, it is determined whether each functional module executes the target processing flow, and the target processing flow is executed after the execution is determined.

[0094] Specifically, after starting and completing the subscription to the message bus object path, each functional module accesses the corresponding message bus object (path: / com / otrd / cpld_monitor / event / {event name}) interface com.otrd.cpld_monitor.event through the D-Bus GetProperty method 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 is currently occurring (true indicates occurrence, false indicates resolution).

[0095] Based on the aforementioned properties, the functional module determines whether to execute the target processing flow according to the following logic: For events whose read-clear property is true, the functional module uses the D-Bus Match rule to subscribe only to signals where the Alert property changes from false to true (i.e., when the event occurs). Upon detecting this state change, the module immediately executes the predetermined target processing flow (such as triggering redundant power supply switching when a power anomaly occurs, or starting fan speed control when the temperature exceeds a limit). After processing is complete, the D-Bus SetProperty method is used to set the Alert property of the corresponding message bus object to false to clear the event flag. For events whose read-clear property is false, the functional module subscribes to all state changes of the Alert property (including changes from true to false, i.e., when the event is resolved). When the property value changes, the module executes the corresponding processing flow based on the changed state (such as recording an alarm log when an event occurs and updating the state to normal when the event is resolved). There is no need to manually clear the Alert property.

[0096] In the embodiment of the present disclosure, for the operation of "determining whether each functional module executes the target processing flow based on the read clear attribute and the status attribute", the specific implementation methods are diverse. For the purpose of clearing the description, the following lists, including but not limited to, some implementation methods: if the read clear attribute is the third attribute value and the status attribute is the first status value, then it is determined that the functional module executes the corresponding target processing flow; if the read clear attribute is the fourth attribute value and the status attribute changes, then it is determined that the functional module executes the corresponding target processing flow.

[0097] 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, indicating that the event must be manually cleared after BMC processing (such as an AC abnormality event). The fourth attribute value corresponds to the "read_clear" field being false, indicating that the event status can be automatically 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. The first status value is true (indicating that an event has occurred). A change in the status attribute refers to the "Alert" attribute value changing from true to false or from false to true.

[0098] When the read-clear attribute is set to the third value (true), the functional module uses the D-Bus match rule to subscribe only to signals whose "Alert" attribute in the corresponding message bus object path changes to the first state value (true). When the CPLD monitor (CPLD Monitor) updates the "Alert" attribute to true, the D-Bus bus sends a signal to the subscribed functional module. Upon detecting this state, the functional module immediately determines to execute the corresponding target processing flow (for example, the power supply monitoring module executes the backup power supply switching logic in response to an AC anomaly).

[0099] When the clear attribute is read as the fourth attribute value (false), the functional module subscribes to all state change signals for the "Alert" attribute under the corresponding message bus object path using the D-Bus match rule. Regardless of whether the "Alert" attribute changes from true to false (event resolved) or from false to true (event generated), the D-Bus bus forwards the signal to the functional module. Upon detecting the attribute change, the functional module determines the execution of the corresponding target processing flow (for example, the temperature monitoring module logs a high temperature alarm when "Alert" changes to true and updates the normal status log when it changes to false).

[0100] In the embodiment of the present disclosure, in addition to the aforementioned contents, the hardware event management method also includes other specific implementation steps. In order to clearly present these components, the relevant specific implementation methods are described in detail below: 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.

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

[0102] When 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 requires manual clearing and has occurred), it executes the corresponding target processing flow (for example, the power monitoring module activates the backup power supply switching logic in response to an AC abnormality event). 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" property from the first status value (true) to the second status value (false).

[0103] This operation is fed back to the CPLD monitor via the D-Bus bus. After the CPLD monitor recognizes the "Alert" attribute update, it confirms that the functional module has completed 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 that corresponds one-to-one with the event record register bits). Finally, the event flag of the hardware event in the event record register is cleared (the corresponding bit is set from 1 to 0), ensuring that the event does not trigger repeated notifications due to uncleared flags.

[0104] In the embodiment of the present disclosure, in addition to the aforementioned contents, the hardware event management method also includes other specific implementation steps. In order 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 notification signal generated by the target channel.

[0105] Specifically, the target channel is a dedicated GPIO (general purpose input and output) pin used to transmit event notification signals between the CPLD and the BMC. This pin is the only physical channel for the CPLD to transmit hardware event information to the BMC. Figure 6 , Figure 6 A flow chart of a CPLD register and event notification provided in an embodiment of the present application is shown as follows: Figure 6 As shown in the figure, CPLD, as the monitoring body of hardware events, can capture various key hardware events on the server motherboard in real time (such as abnormal power status, abnormal temperature, fan failure, etc.). When any hardware event occurs, CPLD sends a notification signal to the BMC through the target channel. The signal is in the form of a pulse (level change) lasting 1ms, and all hardware event notification signals are transmitted through this single channel without relying on other additional channels.

[0106] On the BMC side, 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 triggering configurations) and then enters a continuous monitoring state, monitoring the target channel's voltage level changes in real time. When the CPLD sends a pulse signal through the target channel, the GPIO pin's voltage level changes. The CPLD Monitor captures this change through the interrupt mechanism, confirming that the target channel has sent a notification signal, and triggering the subsequent event content acquisition and processing process.

[0107] In the embodiment of the present disclosure, in addition to the aforementioned contents, the hardware event management method also includes other specific implementation steps. In order to clearly present these components, the relevant specific implementation methods are described in detail below: After creating a message bus object corresponding to the hardware event based on a predefined hardware event configuration file, the initial event content is obtained, and the initial event content is used to update the data of the message bus object.

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

[0109] The CPLD Monitor then parses the initial event content based on the predefined hardware event configuration file. It iterates through each bit in the event record register and determines the event type corresponding to each bit using the bit position-event type mapping in the configuration file (e.g., bit 0 corresponds to the "ACFail" event). It then uses the initial value of the bit to determine the initial state of the event (1 for event occurrence, 0 for event resolution). After parsing, the CPLD Monitor updates the state attribute (the "Alert" attribute, a Boolean type) of the message bus object. For events with an initial value of 1, the corresponding message bus object's "Alert" attribute is set to true; for events with an initial value of 0, it is set to false. The CPLD Monitor also ensures that the "ReadClear" attribute (read clear attribute) remains consistent with the "read_clear" field in the configuration file (true or false).

[0110] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0111] The embodiment of the present application also provides a hardware event management device, Figure 7 A schematic diagram of the structure of a hardware event management device provided in an embodiment of the present application is shown in FIG. Figure 7 As shown, including: A monitoring unit 21 is used to monitor notification signals of hardware events; an acquiring unit 22 for acquiring event content in response to detecting the notification signal; The parsing unit 23 is used to parse the event content and obtain the event status information of the changed hardware event, where the event status information includes the event type and event status; The sending unit 24 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.

[0112] For the description of the features in the embodiment corresponding to the hardware event management device, please refer to the relevant description of the embodiment corresponding to the hardware event management method, and no further details will be given here.

[0113] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned hardware event management method embodiments.

[0114] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned hardware event management method embodiments when running.

[0115] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0116] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned hardware event management method embodiments are implemented.

[0117] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps in any of the above-mentioned hardware event management method embodiments.

[0118] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may 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.

[0119] The above is a detailed introduction to a hardware event management method and device, electronic device and storage medium provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core idea of ​​the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A hardware event management method, characterized in that: include: Monitor notification signals of hardware events; In response to detecting the notification signal, obtaining event content; Parsing the event content to obtain event status information of the changed hardware event, wherein the event status information includes event type and event status; The event status information is sent to the corresponding functional module. Different functional modules need to obtain different event status information, and the target processing flow is executed according to the event status information.

2. The hardware event management method according to claim 1, wherein: The acquiring event content in response to detecting the notification signal includes: In response to detecting the notification signal, the event content recorded in the event record register is read, 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.

3. The hardware event management method according to claim 2, wherein: The parsing of the event content to obtain event status information of the changed hardware event includes: Obtaining position information and value information of a target bit whose value in the event record register has changed; Determining 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 determining the event state of the changed hardware event based on the value information of the target bit and the predefined hardware event configuration file; The predefined hardware event configuration file includes a hardware event name, bit position information in the event record register, value information, and read / clear attributes.

4. The hardware event management method according to claim 3, characterized in that: The sending of the event status information to the corresponding functional module includes: Obtain the event status information required by each functional module; According to the predetermined event status information required to be obtained, the event status information obtained by parsing is sent to the corresponding functional module.

5. The hardware event management method according to claim 4, characterized in that: The step of sending the event status information obtained by parsing to a corresponding functional module according to the predetermined event status information includes: According to the predetermined event status information required to be obtained, the event status information obtained by parsing is broadcast to the corresponding functional module through the message bus.

6. The hardware event management method according to claim 5, characterized in that: The method further comprises: Based on the predefined hardware event configuration file, a message bus object corresponding to the hardware event is created, wherein the attribute information of the message bus object includes the hardware event name, the bit position information in the event record register, the value information, the state attribute and the read clear attribute.

7. The hardware event management method according to claim 6, characterized in that: The method further comprises: In response to the message bus object being created, starting each functional module; According to the predetermined event status information required to be obtained, a message bus object path corresponding to each functional module is constructed, and the message bus object path points to the message bus object.

8. The hardware event management method according to claim 7, characterized in that: The event status information required to be obtained according to the predetermined event is broadcasted to the corresponding functional module through the message bus, including: According to the predetermined event status information required to be obtained, the event status information obtained by parsing is sent to the message bus; The event status information obtained by parsing is sent from the message bus to the corresponding functional module according to the message bus object path.

9. The hardware event management method according to claim 8, characterized in that: The step of sending the event status information obtained by parsing to the message bus according to the predetermined event status information includes: Searching the predefined hardware event configuration file based on the event status information obtained by parsing, and determining a read and clear attribute corresponding to the event status information obtained by parsing; According to the read clear attribute, configuring the state attribute of the message bus object; The message bus object whose state attribute has changed is subjected to event state information conversion, and a bus broadcast signal is generated and sent to the message bus.

10. The hardware event management method according to claim 9, characterized in that: The configuring the state attribute of the message bus object according to the read clear attribute includes: If the read clear attribute is the first attribute value, setting the status attribute of the corresponding message bus object 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 the preset value, the state attribute of the message bus object corresponding to the event state information obtained by parsing is set to the first state value.

11. The hardware event management method according to claim 10, characterized in that: After setting the state attribute of the message bus object to the first state value, the method further includes: The state attribute is written as the first attribute into the corresponding bit in the event clear register to clear the event flag of the hardware event.

12. The hardware event management method according to claim 4, characterized in that: The executing the target processing flow according to the event status information includes: According to the event status information required to be obtained, the read and clear attributes and status attributes of the message bus object corresponding to each functional module are obtained; Based on the read clear attribute and the state attribute, it is determined whether each functional module executes the target processing flow, and the target processing flow is executed after it is determined to execute.

13. The hardware event management method according to claim 12, wherein: The determining, based on the read-clear attribute and the status attribute, whether each functional module executes the target processing flow includes: If the read-clear attribute is a third attribute value and the state attribute is a first state value, determining that the function module executes a corresponding target processing flow; If the read clear attribute is a fourth attribute value and the state attribute changes, the function module is determined to execute a corresponding target processing flow.

14. The hardware event management method according to claim 13, wherein: After determining that the read clear attribute is the third attribute value and the state attribute is the first state value, the method further includes: In response to the target processing flow being completed, the state attribute is set to a second state value to clear the event flag corresponding to the hardware event.

15. The hardware event management method according to claim 1, wherein: The method further comprises: Detect whether the target channel sends the notification signal, and all hardware events send the generated notification signal through the target channel.

16. The hardware event management method according to claim 6, characterized in that: After creating a message bus object corresponding to the hardware event based on the predefined hardware event configuration file, the method further includes: The initial event content is obtained, and the data of the message bus object is updated using the initial event content.

17. A hardware event management device, characterized in that: include: A monitoring unit, used to monitor notification signals of hardware events; an acquiring unit, configured to acquire event content in response to detecting the notification signal; A parsing unit, configured to parse the event content and obtain event status information of the changed hardware event, wherein the event status information includes an event type and an 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.

18. 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. The instructions are 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 to 16.

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

20. A computer program product, characterized in that The invention comprises a computer program, which implements the hardware event management method according to any one of claims 1 to 16 when being executed by a processor.

Images