path: root/local/mib2c.conf

@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 $num = count_scalars@
  number of scalars within:         $num
@eval $num = count_tables@
  number of tables within:          $num
@eval $num = count_notifications@
  number of notifications within:   $num

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 count_scalars() > 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 count_tables() > 0@
**********************************************************************
		     GENERATING CODE FOR TABLES:
**********************************************************************

  Your tables will likely either fall into one of two categories:

    1) tables where the list of rows is external to the agent.
       This is suited to MIBs which monitor or manipulate external
       data (perhaps extracted from the operating system kernel
       or other system interfaces), and where rows are typically
       created or destroyed independently of the SNMP agent.

    2) tables where the list of rows is held by the agent itself.
       This is particularly suited to tables that are primarily
       manipulated via SNMP, or where the rows of the table are
       relatively static.

    3) Do not generate code for the tables.

  @prompt $ans Select the option that best fits you: @
  @if $ans != 3@
    @if $ans == 1@

      This style of table tends to use the iterator helper to instrument
      the external data, so it can be represented by an SNMP table.
      The main characteristic of this helper is the use of a pair
      of "iteration hook" routines to loop through the rows in turn
      (in the most natural order for the underlying data).
        There are a couple of different template configurations that
      can be used as a framework for this:

      1) One based around a single handler, that includes code to handle
         both GET and SET requests, as well as row creation and deletion.
         This template defines a suitable data structure, and implements
         the table as an internally-held linked list, but both of these
         are mainly for illustration, and could reasonably be replaced by
         code more appropriate for the table being implemented.
           The same template can be generated using
                 mib2c -c mib2c.iterate.conf $name
 
      2) An alternative framework, designed as an API wrapper on top of
         the basic iterator helper, that seeks to separate the standard
         processing of the syntax of a MIB table (which can be generated
         automaticall), from the semantics of a given table (which cannot).
           It generates a number of separate code files, but typically
         only one or two of these will need to be edited.  These contain
         separate 'get_column()' and 'set_column()' functions for each
         column in the table, plus some other routines for manipulating
         rows (plus the standard iterator hook routines).
           The same templates can be generated using
                 mib2c -c mib2c.iterate_access.conf $name
         (See the agent/mibgroup/example/netSnmpHostsTable.c file for example)

      3) An API layer (not based on the iterator helper) that attempts
         to reduce the amount of SNMP specific knowledge required to
         implement a module. It provides more APIs than 2, which are
         (hopefully) smaller and more specific, with less SNMP terminology.
           This API is also known as "MIBs for Dummies".  Numerous tables
         in the Net-SNMP agent have been re-written to use this API.
           The same templates can be generated using
                 mib2c -c mib2c.mfd.conf $name
         (See the agent/mibgroup/if-mib/ifTable/ifTable*.c files for examples)

      4) Do not generate code for the tables.

      If you are unsure which option to pick, choices 2) or 3) are perhaps
      more suited for those less familiar with the concepts behind the SNMP
      protocol operations, while choice 1) gives more control over exactly
      what is done.

     @prompt $ans Select the API style you wish to use: @
     @if $ans != 5@
       @if $ans == 1@
         using the mib2c.iterate.conf configuration file to generate your code.
         @run mib2c.iterate.conf@
       @elsif $ans == 2@
         using the mib2c.iterate_access.conf configuration file to
         generate your code.
         @run mib2c.iterate_access.conf@
       @elsif $ans == 3@
         using the mib2c.mfd.conf configuration file to
         generate your code.
         @run mib2c.mfd.conf@
       @else@
         WARNING: Unknown response.  Skipping code generation for tables.
       @end@
     @end@
    @else@
      @if $ans == 2@
      This style of table holds a list of the table rows internally
      within the agent itself.  Typically this will tend to include
      the column values for each particular row, and that is the
      model used by the generated template code.  But it should usually
      be possible to read in some or all of the column values from an
      external source, should this be necessary for a particular MIB table.
        There are a number of different template configurations that
      can be used as a framework for this:
      

      1) dataset storage: The data for the table is stored completely
         within the agent, and the user-visible code does not need to
         be concerned with the internal representation of an individual
         row.  This is most suited to MIB tables that are purely internal
         to the agent, rather than modelling external data, or using
         existing data structures.
           The same template can be generated using
                 mib2c -c mib2c.create-dataset.conf $name

      2) row-data storage: The data for the table is held by the agent,
         but using an arbitrary (user-provided) data structure for the
         representation of an individual row. This is suited for MIB
         tables 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 for SNMP requests.
           The same template can be generated using
                 mib2c -c mib2c.table_data.conf $name

      3) container storage: This is very similar to the previous row-data
         mechanism, but uses a different (and slightly more efficient)
         internal representation.  The main practical effect is to
         introduce a slight constraint on the form of the per-row data
         structure.
           The same template can be generated using
                 mib2c -c mib2c.container.conf $name

      All three of these templates generate a single code file, and
      use a "single handler" format for the driving code.

      4) sorted array:  The data for the table is stored in a sorted
         array.
         (manually mib2c -c mib2c.array-user.conf ${name})

      5) Net-SNMP container: (Also known as "MIBs for Dummies", or MFD.)
         The data for the table is stored via a
         generic interface. Various types of containers may be
         selected, including linked lists or binary arrays.
         (manually mib2c -c mib2c.mfd.conf ${name})

      6) Do not generate code for the tables.

      All APIs are fully functional with little-to-no required code
      to make the table operational on your end once the template
      code is produced.  The MFD and dataset APIs are a bit better
      documented, but the sorted array is probably better tested
      as it was used heavily in the net-policy sourceforge project.
      The MFD API is the successor to the array-user API, and several
      tables in the Net-SNMP agent have been re-written to use it.
      The dataset API is used inside the snmptrapd application for
      logging incoming traps.

      @prompt $ans Select the API style you wish to use: @
      @if $ans != 6@
        @if $ans == 1@
          using the mib2c.create-dataset.conf configuration file
          to generate your code.
          @run mib2c.create-dataset.conf@
        @elsif $ans == 2@
          using the mib2c.table_data.conf configuration file to
          generate your code.
          @run mib2c.table_data.conf@
        @elsif $ans == 3@
          using the mib2c.container.conf configuration file to
          generate your code.
          @run mib2c.container.conf@
        @elsif $ans == 4@
          using the mib2c.array-user.conf configuration file to
          generate your code.
          @run mib2c.array-user.conf@
        @elsif $ans == 5@
          using the mib2c.mfd.conf configuration file to generate your code.
          @run mib2c.mfd.conf@
        @else@
          WARNING: Unknown response.  Skipping code generation for tables.
        @end@
      @else@
        WARNING: Unknown response.  Skipping code generation for tables.
      @end@
    @end@
  @end@
 @end@ # != 3
@end@ # tables

@if count_notifications() > 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.                                  *
**********************************************************************