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
Contents
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