2.3. OPENIPMI INCLUDE FILES
This does not apply to internal interfaces, especially ones that send messages. If you send a message to a MC, for instance, the MC can be NULL when the response comes back. Be very careful.
Note that the handlers don’t get called immediately with current state when you add a callback handler. So you must register for the event then query the current state.
Updated callbacks tell you when an object comes into existance, is destroyed, or if configuration information about an object has changed. On an entity, for instance, when an entity is first added, the entity update handler on the domain will be called with the entity. when an SDR is read and causes a change to the entity, the updated handler will be called again with the change. When the entity is deleted, it will be called again.
In general, you should add updated handlers whenever the thing you want to register against comes into existance. So for entities and the main event handler, you should register them in the setup_done callback for the domain. The entity update handler should register the update handlers for sensors, controls, and FRU information. It should register the event handlers for presence and hot-swap there, too.
Sensor and control update handlers should set up and register for events from the sensor.
Asynchronous callbacks tell you when asynchronous things happen in the system. For instance, a card gets plugged in and an entity becomes present. You will be told with the present callback on the entity. The hot-swap state of an entity changes. That is reported via the hot-swap state callback. Events because of sensors going out of range is another example.
Note that these are usually due to an IPMI event, but do not necessarily have to be caused by an IPMI event. For instance, if, during an audit, OpenIPMI discovers that it has the state wrong for something, it will report the correct state in a callback.
Synchronous callbacks are callbacks for things you request and are one-shot operations. For instance, if you want to know the current value of a sensor, you call call ipmi_reading_get() and you give it a handler to call when the reading has been fetched.
This is always done for things that OpenIPMI might have to send a message to do. If it is a result of OpenIPMI’s requirement to be able to work in non-threaded systems and still be responsive to operations while waiting.
OpenIPMI Include Files
OpenIPMI has a large number of include files. The ones dealing with internals are in the internal directory and are only needed for OEM code. The include file are classified by need in the sections below.