On 8 January 2013 16:00, Kent Borg <kent.b...@csr.com> wrote:
> I don't think I understand. I am not interating over anything now, I am
> just getting handle_somevariableofmine() calls and I look reqinfo->mode to
> see what I am supposed to do. (I have a single template I feed to mib2c and
> it produces a long file of repetitious code, and I figure that is the way I
> am supposed to do things.)
What mib2c config template are you using?
I'd expect the code generated by most of those templates to be
something of the form:
int myTable_handler( ... ) {
switch (reqinfo->mode) {
case GET:
for ( request=request; request; request=request->next ) {
// handle 'request' varbind
}
break;
case SET_RESERVE1:
for ( request=request; request; request=request->next ) {
// handle 'request' varbind
}
break;
// etc, etc
}
}
It's that 'request' loop that jregovic is referring to.
This is important because the handler may be passed a *list*
of varbinds to process - it's not necessarily just one.
(Or you could have a single 'request' loop, containing the reqinfo->mode
switch - the overall effect is exactly the same)
That loop ought to be part of the framework that's generated for you.
Is that not the case.
> In each handler function, when I see the MODE_SET_RESERVE1, I do my
> pre-flighting to make sure the details make sense, then when I get the
> MODE_SET_COMMIT I actually store the data. I was thinking that intermediate
> results from the MODE_SET_RESERVE1 step could be reused in the
> MODE_SET_COMMIT. (I could just duplicate that work in COMMIT, it has no
> side effects, but that seems wrong.)
What sort of 'intermediate results' do you mean?
Can you give us a specific example?
> Is there something I should already be iterating over or are you describing
> an iteration I would do to connect up RESERVE1 stuff with COMMIT stuff?
No - the iteration is concerned with processing multiple varbinds that
arrive as part of a single SET request.
> Right now I am just using statics and it seems that net-snmp does not
> reenter my code and mix calls from more than one snmpset, but I don't know
> that this is guaranteed.
When the Net-SNMP agent is processing a SET request - it will finish this
(through multiple passes until it reaches FREE/UNDO/COMMIT as appropriate)
before starting to process the next.
I believe that SET processing also blocks GET/GETNEXT requests as well,
but would need to check the code to be 100% certain of this.
> I was expecting I would allocate a structure in RESERVE1 and hang it from
> something in reqinfo, then in later calls refer to it, and in COMMIT or
> FREE, deallocate it. But I don't see where to hang it.
You would associate the structure with 'request', not 'reqinfo'.
That holds the information about a particular varbind assignment
(as opposed to 'reqinfo' which holds information about the
request as a whole).
The easiest place to see this in action would be the RESERVE2 pass
of any table that includes a RowStatus column.
This typically looks something like the following:
case SET_RESERVE2:
for (request = requests; request; request = request->next) {
if (request->processed)
continue;
tinfo = netsnmp_extract_table_info(request);
switch (tinfo->colnum) {
case COLUMN_MTEOBJECTSENTRYSTATUS:
switch (*request->requestvb->val.integer) {
case RS_CREATEANDGO:
case RS_CREATEANDWAIT:
/*
* Create an (empty) new row structure
* [OMITTED]
*/
netsnmp_insert_tdata_row( request, row );
}
}
}
break;
Note the statement that comes after the OMITTED code.
This is taking the newly-created data structure, and hanging
it off the 'request' for this particular varbind.
If you've got other intermediate values that you need to
share between one pass and another, then you can hang
them off the 'request' structure in a similar way.
Dave
------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
