MIB Module ReWrites

Given the widespread use of the Net-SNMP agent in a variety of distributions and commercial applications, we have an implicit responsibility to maintain a stable collection of MIB modules.

Balanced against this is the desire to improve these MIB module implementations, tidying up the code, and addressing deficiencies or inconsistencies as they become apparant. Some of these problems can be handled by incremental changes as part of the normal development of the code. But sometimes it proves preferable to introduce a significant reworking of a given MIB module (or modules).

This page attempts to outline a procedure for managing such module re-writes in a responsible manner

Re-Write Policy

One significant issue is whether a given MIB module is typically part of a "default build":

  configure ; make ; make install

or whether it needs to be explicitly included using

  configure --with-mib-modules=xxx

The proposed policies for default and non-default MIB modules are as follows:

Default MIB modules

Any significant re-working of a MIB module that is part of the default build should be trialled for one full major release before being made active by default.

Once this re-write has been included in the default build, the previous module implementation should remain available for a minimum of one full major release before being considered for withdrawal.

In most cases, there is little to be gained by removing the code from the source tree, so such old implementations may well remain available indefinitely. But at a bare minimum, it should always be possible to mimic the default build of one major release, using the code from the next.

Non-default MIB modules

Backwards compatibility is less critical for MIB modules that are not part of a default build, and hence need to be explicitly activated. In this situation, it is reasonable to introduce a re-written version without waiting for a full major release cycle.

However, the previous code should still remain available for at least one full major release (and typically for longer).

Module re-write terminology

This basic policy implicitly defines two groups of MIB modules:

upcoming re-writes

the collection of MIB module(s) which are currently being trialled, with a view to including them as part of the default build with the next major release

recently re-written

the collection of MIB module(s) which were part of the default build of the previous release, but have now been replaced by the previous set of upcoming re-write modules

Build configuration

The standard mechanism for selecting which MIB modules should be included or excluded when compiling the Net-SNMP agent are the options

   configure --with-mib-modules=xxx --with-out-mib-modules=yyy,zzz

A suitable incantation will always be able to choose between recently re-written and/or upcoming MIB module re-writes. However, this may require a non-trivial understanding of the internal organisation of the MIB modules concerned, and the inter-relationships between them. It also assumes knowledge of which modules are candidates for re-writing (or have recently been re-written).

The 5.2.x release line introduced a new option

   configure --enable-mfd-rewrites

which was used to activate a particular subset of MIB module re-writes. It is proposed that this functionality should be subsumed within a more general configure option, which can then be used to control all upcoming and recently re-written MIB modules.

Invocation

There should be two basic modes of invoking this option:

   configure --enable-mib-rewrites    or
   configure --with-mib-rewrites

should activate all "upcoming re-writes". This would provide a simple mechanism for advance testing of any significant problems with the next major release.

   configure --disable-mib-rewrites    or
   configure --with-out-mib-rewrites

should re-activate all "recently re-written" MIB modules. This would provide a simple mechanism for reverting to the default build configuration of the previous major release.

Both of these options could also take a list of specific re-writes to apply or revert, without requiring detailed knowledge of the internal MIB module structure.

It would probably also be useful to provide an option

   configure --list-mib-rewrites

to display a list of both upcoming re-writes, and recently re-written modules, thus providing suitable values for the options outlined above.

Examples

The various release code lines include an (optional) lmSensors module, which would typically be included via the header directive

   config_require( ucd-snmp/lmSensors )

The current development code (which will eventually become 5.5) includes a re-written version (lmSensorsMib), designed to use the hardware/sensors module. This could be trialled in the 5.5 release line by changing this header directive to be:

   configure_new_require(  ucd-snmp/lmSensors,  ucd-snmp/lmSensorsMib)

This version would then become the default in the following release (5.6) by changing this header directive to be:

   configure_old_require(  ucd-snmp/lmSensors,  ucd-snmp/lmSensorsMib)

This could then be dropped in subsequent release lines (5.7 and above), reverting to the basic:

   config_require( ucd-snmp/lmSensorsMib )

or retained, to allow continued easy access to the previous code.

Note that this earlier version would always be accessible by running

   configure --with-mib-modules=ucd-snmp/lmSensors
             --without-mib-modules=ucd-snmp/lmSensorsMib

Note also that it would not be possible to support both "backwards compatibility" and "forwards trialling" in the same release code. The code could contain either config_old_require or config_new_require, but not both.

History

[ ] Draw up a table of which MIB modules were re-written, and when