Chapter 5. OpenHPI Structure

This chapter is the first that gets into the nitty gritty of the basic mechanisms used by OpenHPI. It will come slower than the rest, but will be updated constantly.

5.1. OpenHPI Plugins

OpenHPI has two major parts, the core library (infrastructure), and the plugins. The plugin mechanism allows OpenHPI to support numerous hardware types without requiring any core changes to the library.

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.

Note

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.