X hits on this document

PDF document

February 10, 2006 - page 22 / 238





22 / 238



From the user’s point of view, the entity provides the central framework for sensors and controls. Sensors monitor entities. Entities may be present or absent. When you connect to an interface, OpenIPMI takes care of detecting the entities in the system and reporting them to you. You may register to be told when entities are added or removed from the local database. Note that an entity may be in the SDRs but not physically present in the system; the reporting from only gives the existance in the SDRs, not physical presence in the system. Physical presence it handled through a separate interface.

The user must know about two other OpenIPMI concepts: connections and domains. A connection provides the interface to the IPMI system. In essence, it is the BMC connection. You must allocate one or more connections and create a domain with them. OpenIPMI supports multple connections to a domain in some cases, but currently it requires some OEM support for this. A domain represents a set of devices on a bus (like IPMB) whose entities will be unique. For instance, a chassis with a lot of cards plugged could be a domain, each card could be an entity and then create it’s own sub-entities, but they will be designed so the entity id’s don’t collide.

OpenIPMI will automatically manage the connections, activating and deactating the proper connections (if the connections support that), detecting failures and switching over, etc.

Though the user doesn’t have know the inner details of IPMI addressing and messaging, they do need to know about entities and sensors. OpenIPMI mainly focuses on representing the entities and sensors in convenient ways. The user still needs to understand the capabilities of sensors, how the sensors advertise those capabilties, and the things that can be done to the sensors.

You may register with an entity to be told when its physical presence in the system changes. Some devices (like power supplies) are field-replaceable while the system is running; this type of device is called a hot-swappable FRU. They may have sensors that monitor them, but those sensors may not be active if the device is not physically present in the system.

Sensors and controls are also automatically detected and reported. This is done through entities; you register with an entity to be told when a sensor or control has been added or removed.


OpenIPMI Concepts

OpenIPMI is an event-driven library that is designed to be relatively operating system independent. If you have written control systems or things like that in the past, you will be quite familiar with event-driven systems and may skip to the next section. If not, you want to read this. Event-driven systems may seem a little unusual, but they are accepted practice and by far the best way to build control systems.




In an event-driven system, you never stop and wait for something to happen. If you are not used to this, you are probably used to writing code like this:

while (true) { wait_for_input(); perform_op1(); wait_for_op1_results(); perform_op2();


Document info
Document views1154
Page views1154
Page last viewedTue Jan 24 01:18:12 UTC 2017