On 7 April 2011 00:48, Zimmer Hu <[email protected]> wrote:
> So, could somebody tell me what exactly netsnmp_extract_iterator_context
> returns?
You need to take a step back, and think about the general principles
of how the agent processes a request for a table entry.
There are essentially two tasks involved:
- identifying the relevant row of the table for a given request,
- and then looking at the particular column field(s) for that row.
Most of the table-related helpers are concerned with the first
aspect of this processing. They will identify the appropriate
row, and pass this in some way to the main handler routine,
which looks after the second part.
In the case of the iterator helper, the call 'netsnmp_extract_iterator_context'
is that "some way" mentioned above. This is the mechanism provided
for the handler to retrieve the appropriate row for this request.
The value is whatever was returned from the 'get_first' and
'get_next' hook routines via the 'data_context' parameter.
> From code in nsVacmAccessTable.c and nsLogging.c:
> I see first insert data_context into cache handler in SET
> and then extract it in GET.
That's not strictly accurate.
In particular, it's not "first SET, then GET".
Remember that the MIB handler will be called for each incoming request.
So the style (and ordering) of these calls will depend on what requests
are sent to it.
If the agent receives a GET (or GETNEXT) request, then it will
identify the appropriate row (using the 'get-first'/'get_next' hook
routines), and then invoke the handler in GET mode.
The handler uses 'netsnmp_extract_iterator_context' to retrieve
the relevant row structure, and returns the appropriate column
value(s).
If the agent receives a SET request for an existing row, then it will
again identify the appropriate row (using the 'get-first'/'get_next'
hook routines), and invoke the handler in SET mode.
The handler uses 'netsnmp_extract_iterator_context' to retrieve
the relevant row structure, and updates the appropriate column
value(s).
But if the agent receives a SET request to create a *new* row,
then the 'get_first'/'get_next' hook routines won't find an
appropriate (existing) row. The handler is still invoked in SET
mode, but 'netsnmp_extract_iterator_context' will return nothing.
The row is only created as part of processing the RowStatus column.
Now, remember that SET is a multi-pass process:
Reserve1, Reserve2, Action, Commit
(ignoring the error handling for now).
The get_first/next hook searching is only done once (during Reserve1),
since the row involved isn't going to change. The following passes
all use the same 'data_context' value from the hook routines.
But when creating a new row, the hook routines didn't return a 'data_context'
value - the row structure was created by the RowStatus column code.
So it's now *this* code which needs to make sure that the newly created
row is made available to the following passes.
Hence calling netsnmp_insert_iterator_context()
If you check the nsVacmAccessTable and nsLogging code, you'll
see that this routine is *only* invoked as part of processing
CreateAndGo or CreateAndWait assignments.
The netSnmpHostsTable uses a different mechanism for
passing the data between Reserve1 and the following passes,
so only uses netsnmp_extract_iterator_context() in the GET
and Reserve1 passes. Reserve2, etc don't call this routine,
so the row creation code doesn't need to associate the new row
structure with the request in this way.
And the MfD framework is a completely different beast altogether.
The description above is really only aimed at the handler-based
iterator approach.
OK?
Dave
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
