3.2. Event Model
If Resources are the nouns of HPI, Events are the verbs. Based on flags set on Resources, events will be generated by changes in RDR values. This section attempts to clarify what events mean in an HPI context.
There are 2 types of events in HPI, which are based solely on their level of persistence. Normal HPI Events are transient objects that sit on an event queue until processed by the user, at which time they disappear entirely. Some subset of these Events may be made persistent by inserting them into a System Event Log (SEL). The logic for which events end up in a SEL is entirely determined by the implementation.
3.2.1. HPI Events
HPI Events refer to the transient Events that are generated within the HPI infrastructure. The reason for HPI event generation can be many. The failure of a resource, the loss of redundancy of a resource, a sensor value exceeding a warning threshold, or many other reasons.
3.2.1.1. Sensor Events
Sensor Events are easily quantifiable. Event generation for a sensor is specified via saHpiSensorEventEnablesSet. This may include both assertion (crossing a threshold), and deassertion (returning to a "safe" value from the threshold). For all sensors that have events enabled, on any RPT update those sensor value will be compared to the set threshold, and events will be generated if appropriate.
3.2.2. Accessing Events
The method for accessing events is multi step process. First, a user must subscribe to events within a domain. When a subscription for events occurs, the user may specify whether they wish to see events that have already occured, or merely see events from the current time forward.
Events are then fetched by a polling function call saHpiEventGet. This function specifies a timeout that it is willing to wait for an event if one is not readily available. This timeout can be specified as SAHPI_TIMEOUT_BLOCK, which will cause the function to block until such time as an event is available. If any other timeout value is specified, and no event exists in the event queue during the timeout period, the function will return NULL.
 |
SLD: In a multiple tenant environment, how does one process events properly? If events are transient, the first processing should purge them. In OpenHPI's current model, this shouldn't be a problem, as events will all exist in all OpenHPI instances because they are in separate memory environments. However, if a daemon model were chosen, this would be an issue. |
3.2.3. System Event Logs
If a Resource has the SAHPI_CAPABILITY_SEL bit set, there is a System Event Log (SEL) associated with that resource. The SEL is a repository for events that can later be retrieved via HPI calls. SELs come in 2 flavors, Domain Level, and Resource Level.
A Domain Level SEL is implemented in software, and contains events associated with the domain. There is exactly one Domain level SEL per domain. These may have been generated because HPI has been told to monitor the temperature of a sensor, and on the latest polling for that data, the sensor exceeded the threshold. The important part to remember is that the events in the Domain level SEL are HPI originated, based on rulesets in HPI.
A Resource (which is not a domain) will have the SAHPI_CAPABILITY_DOMAIN bit turned on if that resource represents a piece of hardware which contains a hardware implemented SEL. For instance, most server mother boards have an SEL that monitors what the hardware considers critical events. This may include a fan failure, a boot failure, or other events. Unlike Domain level SELs, the decision mechanism for what events get generated in a Resource SEL are not under the control of HPI. They are hardcoded in the hardware directly.
There may be mechanisms for changing what events get generated in an Resource SEL. However, those controls are beyond the scope of HPI.
 |
SLD: Did I get this right? Seems odd, perhaps it is too late on friday |