diff options
Diffstat (limited to 'local/mib2c.conf')
| -rw-r--r-- | local/mib2c.conf | 308 |
1 files changed, 308 insertions, 0 deletions
diff --git a/local/mib2c.conf b/local/mib2c.conf new file mode 100644 index 0000000..c71968c --- /dev/null +++ b/local/mib2c.conf @@ -0,0 +1,308 @@ +@open -@ +mib2c has multiple configuration files depending on the type of +code you need to write. You must pick one depending on your need. + +You requested mib2c to be run on the following part of the MIB tree: + OID: $name + numeric translation: $name.objectID +@eval $numS = count_scalars@ + number of scalars within: $numS +@eval $numT = count_tables@ + number of tables within: $numT +@eval $numN = count_notifications@ + number of notifications within: $numN + +First, do you want to generate code that is compatible with the +ucd-snmp 4.X line of code, or code for the newer Net-SNMP 5.X code +base (which provides a much greater choice of APIs to pick from): + + 1) ucd-snmp style code + 2) Net-SNMP style code + +@prompt $ans Select your choice : @ +@if $ans == 1@ +********************************************************************** + GENERATING CODE FOR THE 4.X LINE OF CODE (THE OLDER API) +********************************************************************** + + using the mib2c.old-api.conf configuration file to generate your code. + @run mib2c.old-api.conf@ + +@elsif $ans != 2@ +Invalid answer. +@else@ + @if $numS > 0 && $numT > 0@ +********************************************************************** + MIXED MIB TEMPLATE +********************************************************************** +The portion of the MIB tree that you have selected contains both +scalar objects and MIB tables. The automatically generated Net-SNMP +style code cannot handle both of these simultaneously (though you +could generate the two files separately, and then merge the two). + +Which code do you want to generate: + + 1) Scalar objects + 2) MIB tables + + @prompt $ans Select your choice : @ + @if $ans == 1 @ + @eval $numT = 0@ + @elsif $ans == 2@ + @eval $numS = 0@ + @else@ +Invalid answer + @eval $numS = 0@ + @eval $numT = 0@ + @end@ + @end@ +@if $numS > 0@ + +********************************************************************** + GENERATING CODE FOR SCALAR OBJECTS: +********************************************************************** + + It looks like you have some scalars in the mib you requested, so I + will now generate code for them if you wish. You have two choices + for scalar API styles currently. Pick between them, or choose not + to generate any code for the scalars: + + 1) If you're writing code for some generic scalars + (by hand use: "mib2c -c mib2c.scalar.conf $name") + + 2) If you want to magically "tie" integer variables to integer + scalars + (by hand use: "mib2c -c mib2c.int_watch.conf $name") + + 3) Don't generate any code for the scalars + + @prompt $ans Select your choice: @ + @if $ans == 1@ + using the mib2c.scalar.conf configuration file to generate your code. + @run mib2c.scalar.conf@ + @elsif $ans == 2@ + using the mib2c.int_watch.conf configuration file to generate your code. + @run mib2c.int_watch.conf@ + @elsif $ans != 3@ + WARNING: Unknown response. Skipping code generation for scalars. + @end@ +@end@ # scalars + +@if $numT > 0@ +********************************************************************** + GENERATING CODE FOR TABLES: +********************************************************************** + + The Net-SNMP agent API is extremely extensive and, in fact, lets + each programmer write agent code according to the style that works + best for them based on their experience and their preference. We're + going to ask you a serious of questions that will help mib2c + generate code that best suits *your* needs, as the programmer that + will be responsible for taking the code and further refining it. If + you don't like how the results look, you are always welcome to + re-run mib2c and select a different set of options. + + There are essentially two tasks involved in processing requests + for OIDs within a MIB table - firstly identifying the relevant row + of the table for a given request, and then returning (or updating) + the appropriate column value within that row. Many MIB tables model + the state of some external system (the kernel, a device, processes, + etc), and the MIB implementation module (the code we're about to + produce a template for) acts as an interface between this underlying + system and the SNMP side. Other tables hold data internally that is + only available within the agent itself, or at least the master copy + of the data is held within the agent. + + There are a number of different code templates that can be used to + implement MIB tables, using various approaches to these two tasks. + + There are three basic approaches to identifying the relevant row: + + 1) Pass the request through to the table-specific code, and + identify the requested row there (for both GET and GETNEXT + requests). This is typically the most efficient way to get + up-to-date information, but relies on suitable + (programmer-provided) code within the MIB handler. + Most importantly, you should be an expert to use this choice. + + This will produce code based on the table_dataset handler. + + 2) Have table-specific code to provide information about which + rows exist in the table (by iterating through them in turn), + but utilise standard helper code to select the appropriate + row for a given request. This is particularly suitable for + tables where the data is naturally stored in a "random" order + (or differently to the MIB table index), or where rows are + frequently added to or removed from the table. + + However searching for the requested row is not very efficient, + and performance can be slow - particularly for large tables with + many rows. + + 3) Hold a locally cached copy of the contents of the table (or at + least a cache of which rows are valid), and utilise standard + helper code to select the appropriate row. This is + significantly faster than the iterator-based approach, but + cached data is inevitably slightly "stale" with respect to the + data from the underlying system being managed. This approach, + since it relies on caching of data, is also results in a larger + memory footprint. It is less appropriate for tables where rows + are frequently added or removed externally to the agent (i.e., + not via SNMP requests). + + This approach can also be used where _all_ use of the table is + via SNMP, and there is no external "underlying system". In + this case, the local cache is the canonical version of the + table. + + 4) Do not generate code for the tables. + + @prompt $ans1 Select the option that best fits your requirements: @ + + @if ($ans1 == 2) || ($ans1 == 3)@ + + Having identified the appropriate row for a given request, there are + three basic styles of code for returning (or updating) the requested + column value from within this row: + + 1) A single handler routine, which contains all the code needed to + handle GET and SET requests for each of the column objects. + +@if $ans1 == 2@ + The code typically looks like a single function with a large 'case' + statement covering each of the columns. + + This will produce code based on the 'iterator' hepler. +@end@ + + 2) A set of individual routines, each of which is concerned + with a particular aspect of processing the request. + @if $ans1 == 2 @ + Each column object within the table has one routine for + retrieving the current value, and another for setting a new one. + + This will produce code based on the 'iterate_access' hepler. + @else@ + There is one routine for reporting values for GET requests, + and one routine for each stage of processing a SET request. + @end@ + + 3) A (different) set of individual routines, each of which is + smaller and more tightly focused than the code generated by + style 2. The aim here is to reduce the amount of SNMP specific + knowledge required to implement a module, and hide much of the + SNMP terminology and processing within standard generated code + (which can simply be used sight unseen). +@if $name !~ /Table$/i@ + However this style of code can only be generated when mib2c + is run on an individual MIB table. To use this approach, you + will need to re-invoke mib2c with the name of a single MIB table. +@end@ + + This will produce code based on the 'mfd' hepler ('MIB for Dummies'). + + 4) Do not generate code for the tables. + + (In all cases, GETNEXT requests are automatically converted + into the equivalent GET request, so the MIB specific code + need only be concerned with GET and SET requests.). + + @prompt $ans2 Select the code style you wish to use: @ + @end@ + + @eval $template = NONE@ + @if $ans1 == 1@ + @eval $template = "create-dataset"@ + + @elsif $ans1 == 2@ + @if $ans2 == 1@ + @eval $template = iterate@ + @elsif $ans2 == 2@ + @eval $template = iterate_access@ + @elsif $ans2 == 3@ + @eval $template = mfd@ + @elsif $ans2 != 4@ + WARNING: Unknown response. Skipping code generation for tables. + @end@ + + @elsif $ans1 == 3@ + @if $ans2 == 1@ + There are actually two alternative templates that use this + style of code - differing primarily in the data structure + used for representing a row of the table + + 1) The first is well suited for situations where there is a + natural existing data structure, or where the contents of + the table may need to be interpreted for some additional + purpose, other than simply implementing the table in SNMP. + + This will produce code based on the 'table_data' hepler. + + 2) The second is slightly more efficient, but introduces some + minor constraints on the form of the per-row data structure. + + This will produce code based on the 'container' hepler. + + @prompt $ans3 Select the row representation you wish to use: @ + + @if $ans3 == 1@ + @eval $template = table_data@ + @elsif $ans3 == 2@ + @eval $template = container@ + @else@ + WARNING: Unknown response. Skipping code generation for tables. + @end@ + @elsif $ans2 == 2@ + @eval $template = "array-user"@ + @elsif $ans2 == 3@ + @eval $template = mfd@ + @else@ + WARNING: Unknown response. Skipping code generation for tables. + @end@ + + @elsif $ans1 != 4@ + WARNING: Unknown response. Skipping code generation for tables. + @end@ + + @if $template ne NONE@ + The same template code can be generated using + mib2c -c mib2c.${template}.conf $name + @run mib2c.${template}.conf@ + @end@ +@end@ # tables + +@if $numN > 0@ +********************************************************************** + GENERATING CODE FOR NOTIFICATIONS: +********************************************************************** + +Would you like to generate code for sending notifications from within +the agent? + + @prompt $ans "y" or "n": @ + @if ("$ans" eq "y") or ("$ans" eq "yes")@ + using mib2c.notify.conf to generate code for sending notifications + @run mib2c.notify.conf@ + @end@ + +# GENERATING HEADER FILE DEFINITIONS +# +# To generate just a header with a define for each column number in +# your table: +# +# mib2c -c mib2c.column_defines.conf ${name} +# +# To generate just a header with a define for each enum for any +# column containing enums: +# +# mib2c -c mib2c.column_enums.conf ${name} + +@end@ # notifications +@end@ # new style code + +********************************************************************** +* NOTE WELL: The code generated by mib2c is only a template. *YOU* * +* must fill in the code before it'll work most of the time. In many * +* cases, spots that MUST be edited within the files are marked with * +* /* XXX */ or /* TODO */ comments. * +********************************************************************** |