Difference between revisions of "Template:FAQ:Coding 08"

Latest revision as of 16:28, 26 March 2014

Most of the mib2c config files are concerned with implementing MIB tables, and generate various alternative code templates. These basically fall into four distinct categories.

There are various alternative configuration templates for mib2c, mostly concerned with implementing MIB tables. These basically fall into four distinct categories.

'mib2c.raw-table.conf' is the lightest of the templates, and just provides a fairly basic table framework. Most of the work of implementing the table - detecting which row is required for a given request, retrieving or updating the relevant column values, and interacting with the underlying subsystem - are all left to the MIB programmer.

The second group of templates - 'table_data', 'container' and 'row' - all share the same basic model (although the internal details are rather different). The MIB implementer should define a data structure to represent a row of the table, and the helper then takes care of holding the table internally, as a collection of such per-row data structures. This includes identifying which row is required for a given request. Retrieving or updating the appropriate column value is left to the MIB programmer, although the generated framework includes most of the necessary code. Allied to this is a fourth "internal data" mib2c configuration file ('create-dataset') which handles the individual columns as well. This is the closest to a Plug-and-Play configuration, and the MIB implementer only needs to be concerned with any special processing, such as linking the table with the underlying subsystem.

The specific style of data access for these four schemes is:

1. table_data uses the agent/table_tdata.h style
2. container uses the agent/table_container.h style
3. row uses the agent/table_data.h style
4. create-dataset uses the agent/table_dataset.h style

The third style of mib2c config assumes that the table data is held externally to the helper - either within the MIB module code itself, or in the external subsystem. The generated code framework includes routines to "iterate" through the rows of the table, with the iterator helper simply deciding which row is required for a particular request. Once again, the MIB programmer must handle retrieving or updating the appropriate column value, although the generated framework includes most of the necessary code. There is a variant of this config ('iterate_access') which works in basically the same way. However this tries to separate out the standard processing, from the code that needs to be amended by the programmer for retrieving and updating the individual column values.

This is also the idea behind the final table-oriented mib2c config template - 'mib2c.mfd.conf' (or "MIBs for Dummies"). This is a much more flexible framework, which can be used with either internally held data, or iterating through an external representation. The distinguishing feature of this framework is that it separates out standard and table-specific processing, at a much finer level of detail than the others.

The other mib2c config templates are concerned with implementing scalar objects ('scalar', 'int_watch'), code to generating traps ('notify'), and various specialised requirements. There is also a template ('old-api') to generate code suitable for the previous v4 UCD agent - though this is not particularly complete or reliable. It's probably better to use a pure v4 mib2c environment (or switch wholeheartedly to the v5 style).