| @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. * |
| ********************************************************************** |
