Difference between revisions of "Information Abstraction"

Latest revision as of 09:37, 10 January 2007

One of the main tasks to face in implementing a new MIB is retrieving the necessary information from the underlying system. This is particularly true when the MIB is to be implemented across a range of architectures and operating systems, which may have a series of different interfaces for accessing this information.

Many of the earliest Net-SNMP MIB modules illustrate this problem, often containing an impenetrable forest of conditionally-compiled code, and parallel versions of the same basic functions. "Information abstraction" is an attempt to bring this situation under control.

The idea is to separate the architecture-specific task of retrieving the necessary data, from the (hopefully standard) task of reporting it via SNMP. By defining a suitable common data structure for holding this information, the code for processing SNMP requests can be shared across all systems, with (typically) a series of separate files for individual operating systems.

MIB-specific abstraction

This is relatively straightforward when there is only a single MIB to be concerned with (or a group of closely-linked MIBs). The data structure can be modelled fairly closely on the MIB definitions, and the O/S and common code can be kept together. This approach is illustrated in the structure of the 'MfD' framework, with a 'data_access' subdirectory to hold the O/S-specific code, and (typically) a 'xxxTable' subdirectory for the shared SNMP handling.

Examples of this approach include the 'if-mib', 'ip-mib', 'ip-forward-mib', 'tcp-mib' and 'udp-mib' implementations.

MIB-independant abstraction

Things are a little more complex when the same information is potentially needed for more than one MIB. But the same basic concept can still be used.

By defining a suitable data structure (rich enough to handle the requirements of *both* MIBs), the architecture-specific code for retrieving this information and populating the combined data structure can be kept separate from the code for implementing each of the MIBs.

Such a situation can arise when a vendor-specific MIB (such as the UCD-SNMP-MIB) parallels or extends a standard MIB (e.g. Host Resources). These two implementations were developed completely separately using independent code, despite significant areas of overlap between the two MIBs. This meant that the same information could easily be retrieved using two different interfaces on the same architecture - potentially resulting in different values depending on which MIB was consulted. Or a particular architecture might only implement one MIB but not the other (and not necessarily consistently as regards which MIB was missing).

HAL

The "Hardware Abstraction Layer" (or HAL) is an attempt to address this, by consolidating the architecture-specific code from the 'ucd-snmp' and 'host' implementations into a common structure. This shared data can then be used by both UCD-SNMP-MIB and Host Resources MIB modules to implement the relevant tables. It also helps ensure that information is reported consistently across all operating systems.

Currently (v5.4), there are two types of hardware that have been treated in this way:

• cpu

  reporting statistics of processor activity

• memory

  reporting on memory and swap usage
  (plus a summary of how these values are retrieved)