Difference between revisions of "FAQ:Coding 08"
(Move FAQ text to a template page & 5.4 release synchronisation) |
|||
Line 1: | Line 1: | ||
− | = | + | = Which mib2c configuration file should I use? = |
− | {{FAQ: | + | <!-- NB: |
+ | There is a mismatch between the template numbering | ||
+ | for this entry, and the FAQ entries that refer to it. | ||
+ | This follows a review of the entries in the | ||
+ | Coding section. | ||
+ | --> | ||
+ | {{FAQ:Coding_09}} | ||
[[FAQ:Coding]] | [[FAQ:Coding]] | ||
{{FAQ:Coding}} | {{FAQ:Coding}} |
Latest revision as of 23:31, 28 December 2006
Which mib2c configuration file should I use?
The answer to that heavily depends on the characteristics of the
MIB objects being implemented. Of the handler-based table frameworks,
'tdata'
is more appropriate for tables that can be stored (or a copy
cached) within the agent itself, while 'iterate'
is more relevant to
reporting data from outside the agent.
The raw interface is only suitable in very specific circumstances,
so it's probably sensible to start with one of the other frameworks
first, and only look at this if none of the alternatives seem to work.
The decision between the handler-based configs and MfD
is more a
matter of the style of programming to use. Most of the frameworks
define a single handler routine to process an incoming request, so
all of the code is listed together, with the MIB programmer inserting
table-specific processing into this single block of code.
The MfD provides a series of individual object-specific routines,
each concerned with one very specific task, and hides as much as
possible from the programmer.
If you like to understand the broad thrust of what's happening, then one of the handler-based approaches would be the best choice. If you prefer to concentrate on the nitty-gritty of a given table, and are happy to trust that the rest of the processing will work correctly, then the MfD framework would be more appropriate.
For implementing a group of scalar objects, then the choice is
simple - use 'mib2c.scalar.conf'
.
Similarly, for generating traps
or informs, use 'mib2c.notify.conf'
. But note that this only assists
with the code to actually generate the trap. It does not address the
issue of when to send the trap. See the FAQ entry
How can I get the agent to generate a trap? for more information.
FAQ:Coding
- How do I write C code to integrate with the agent?
- How does the agent fetch the value of a MIB variable from the system?
- Mib2c complains about a missing "mib reference" - what does this mean?
- Mib2c complains about not having a "valid OID" - what does this mean?
- Why doesn't mib2c like the MIB file I'm giving it?
- Mib2c ignores my MIB and generates a pair of 'mib-2' code files. Why?
- What's the difference between the various mib2c configuration files?
- Which mib2c configuration file should I use?
- How can I have mib2c generate code for both scalars and tables?
- Are there any examples, or documentation for generating MIB modules?
- Where should I put the files produced by 'mib2c'?
- Why doesn't my new MIB module report anything?
- Why does the iterator call my get_{first,next} routines so often?
- How can I get the agent to generate a trap (or inform)?
- How can I get an AgentX sub-agent to generate a trap (or inform)?
- How can I get the agent to send an SNMPv1 (or SNMPv2c) trap?
- How can I get the agent to include varbinds with an SNMPv1 trap?
- How can I get the agent to send an SNMPv1 enterprise-specific trap?
- How can I get the agent to send an SNMPv3 trap (or inform)?
- Why does calling 'send_v2trap' generate an SNMPv1 trap (or vice versa)?
- How can I register a MIB module in a different (SNMPv3) context?