On 18/01/2008, Baltazar Francois <[EMAIL PROTECTED]> wrote:
> The problem is that I need one single handler function to process SET and
> GET commands for several tables of my MIB.
Why?
The usual model would be to register each table individually, with its
own handler function. This allows the table helper to deal with parsing
the indexes, etc.
All the varbinds for a given table would be processed together, but
the different tables would be handled separately. It would then be
up to the programmer to insert suitable coordination between these
table handlers (e.g. working with the same underlying data storage).
You _could_ use a single registration for the whole of the subtree
containing the various tables. But then you'd have to take care of
the index parsing, etc yourself. It's easier to have the table helpers
deal with this, and have several cooperating handler functions.
> In the case of scalar values, I used the following from your examples:
>
> [CODE
> START]-------------------------------------------------------------------------------------------------------------
>
> struct variable2 example_variables[] = {
> { EXAMPLESTRING, ASN_OCTET_STR, RONLY, var_example, 1, {1}},
> { EXAMPLEINTEGER, ASN_INTEGER, RWRITE, var_example, 2, {2,1}},
> ...
> };
That's using the old (v4) "traditional" API.
This puts most of the responsibility for processing tables onto the programmer.
We would tend to recommend that new MIB modules should use one of the
v5 handler-based approaches.
You *could* use a shared handler routine with this older API, by
specifying the same 'var_xxx' routine for all the table registrations,
and making sure that the initial constant values are distinct across
all the (shared) tables.
But it's probably easier to stick with the newer approach.
A bit more information about why you think you need to use a single
handler function would probably be useful. Let's see if we can
convince you that you don't.
Dave
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
