5.1.1. Plugin ABI

Every plugin is a libtool dynamic library. The lt_dlopenext call is used to open and load the symbols from the plugin.

Every plugin must include a get_interface function which populates an oh_abi_v2 structure. This structure contains 35 function pointers, and is loaded only once per plugin. Many of the functions in the plugin ABI map very closely to those in the SA HPI, however they are named with more Linux friendly naming convention (i.e. add_sel_entry vs. saHpiEventLogEntryAdd).

The plugin ABI should not yet be considered stabalized, as there haven't been enough fully functional plugins to ensure that it can fulfill every possible type of plugin for the HPI 1.0 interface.

Once Plugins are loaded, their abi functions are stored in a global linked list. This allows multiple instances of the same plugin to share the same function pointers.

SLD: We should probably change this to a hash for faster access

5.1.2. Handlers

OpenHPI plugins are shared objects that are loaded by the plugin loader. Handlers are instances of those objects created by the oh_abi_v2.open function included in the plugin.

The handler open call is made during the saHpiSessionOpen function to generate a list of open handlers (stored in a global linked list). The handles include pointers to the function table for the handler, and a void * generated by the handler during its open call. This is the location for the handler to store persistent data, as this pointer is passed to every plugin abi call except for open. The contents of the pointer are currently not specified, however in future it may make sense to standardize the state struct which the handlers get during their processing.

In many ways the use of the function pointer table, and persistent instance data is a rudimentary OO design.