1) I updated my code a bit but for some reason the Table2_row_prep() routine is
never called when I perform a "snmpwalk" of Table2. Any ideas why
"Table2_row_prep()" is not being called at all (see the steps a-e below)?
Here are the two tables I am dealing with for testing:
Table1(ocStbHostAVInterfaceTable)
Table2(ocStbHostAnalogVideoTable)
a) I updated the Table1(ocStbHostAVInterfaceTable) data_context structure to
include the fields from Table2(ocStbHostAnalogVideoTable).
b) I updated Table2 "_ocStbHostAnalogVideoTable_container_init()" routine with
the following code only, which I believe should tell Table2 to use the same
cache as Table1(ocStbHostAVInterfaceTable):
if_ctx->cache =
netsnmp_cache_find_by_oid(ocStbHostAVInterfaceTable_oid,
ocStbHostAVInterfaceTable_oid_size);
if (NULL != if_ctx->cache) {
if_ctx->container = (netsnmp_container *) if_ctx->cache->magic;
return;
} else {
snmp_log(LOG_ERR, "error finding ocStbHostAVInterfaceTable cache\n");
}
c) I added printf statements to the "init_data", "container_init",
"container_load" and "row_prep" routines of Table1 and Table2 to verify the
flow through the code was correct when an SNMP request was performed.
d) When I start the SNMP agent the following flow is displayed. Does this
seem correct so far?
ENTER ocStbHostAnalogVideoTable_init_data()
EXIT ocStbHostAnalogVideoTable_init_data()
ENTER _ocStbHostAnalogVideoTable_container_init()
EXIT _ocStbHostAnalogVideoTable_container_init()
ENTER ocStbHostAVInterfaceTable_init_data()
EXIT ocStbHostAVInterfaceTable_init_data()
ENTER ocStbHostAVInterfaceTable_container_init()
EXIT ocStbHostAVInterfaceTable_container_init()
ENTER ocStbHostAVInterfaceTable_container_load()
EXIT ocStbHostAVInterfaceTable_container_load()
e) When I request a "snmpwalk" through Table1(ocStbHostAVInterfaceTable) then
all of the fields of Table1 seem to displayed appropriately, however, doing a
"snmpwalk" through Table2(ocStbHostAnalogVideoTable), returns nothing. I
simply get the Linux cursor back, without any error or anything. Actually,
none of my printf statements are displayed either, which means that the
Table2_row_prep() routine is not being called at all. Note: I realize the
"Table2_container_load()" routine is not being called (which is normal) since
Table2 is using the same cache as Table1. I actually commented out all of the
internal code in the "Table2_container_load()" routine, but I left the actual
routine visible. Basically, the routine simply does nothing now, it is just
empty.
2) In regards to "me" stating I will rebuild Table1 when the container_load()
routine is called, "you" stated "You don't 'have' to start from scratch, but
it's probably the easiest way".
If I wanted to start from scratch and repopulate Table1, then I need to make
sure to use the same index values for each row as I used before. In order to
do this, I would assume I would need to store each index value by calling the
"se_add_pair_to_slist" routine. Basically, I would need to link a unique text
string to each of the index values being stored so when it comes time to
repopulate the container (allocate new rows from scratch) then I can search for
the unique text string (using the "se_find_value_in_slist" call) to find which
index value was related previously then I can simply use that same index value
for the regeneration of the container Table .... correct?
Now, it would be nice if I did not have to regenerate the container used for
Table1 everytime the container_load() routine was called, however, I am not
sure how to do this? I thought Table1's container was freed(released) once the
cache has expired and a new snmp request is received, so regenerating the
container was necessary, but I guess I am wrong. How can a Table container be
maintained and not be required to rebuild itself when the container_load()
routine is called? If this will take a lot of effort to explain, then perhaps
we should wait to have this discussion in the future, after my basic stuff is
working. Although if this is an easy concept, then please explain.
3) You indicate that the "Table2_row_prep()" routine will be called for each
row in Table1. This is fine, since I can check whether the current row
actually relates to Table2 easily by checking the "type" value defined in
"Table1". If the row is not related to Table2, then you indicate I should
return MFD_SKIP. Yes, this seems straightforward, however (and you probably
know I would be asking this), what changes must I make to the table interface
code of each of the secondary tables in order for them to handle the new
MFD_SKIP return value? Actually by "interface code" do you mean the
"xxxxx_interface.c" files need to be updated, or
are you referring to some other code file which would need to be updated?
Based on the "ifTable" tutorial, I assumed MFD_SKIP was used in data "GET"
routines in which the data was not existing in the table, however, I guess
using this value can be used for other things as well.
4) One extra question for you:
Once I have this SNMP agent stuff figured out, my next goal will be to
implement a SNMP Client which will offer a set of APIs to be used by the
row_prep() routines of the SNMP agent to populate the rows of the tables
appropriately. Basically, these will be a set of procedures which can be
called by the row_prep() routines to get the proper data which is associated
with the current row being populated. It would be helpful if the SNMP client
API procedure could return "extra" data (client-specific index values, etc..)
to the agent (which can be stored) in which the agent could then pass back to
the SNMP Client (as input to the API routines) when rebuilding the Table via
the container_load() routine occurs. Basically, have the SNMP agent code store
data for the sole purpose of passing it back to the SNMP Client which will make
it easier for the client to obtain
the requested data.
Is storing "extra" data in the agent for the sole purpose of passing it back to
the client a common practice?
For example: Lets say the SNMP agent is populating row1 of the table. It will
call an API routine that my company is providing to get the data it needs to
populate the row. Now, inside this API routine, lets say it was necessary to
access a few company-defined internal tables in order to get to the data which
is being requested. It would be helpful that if the next time a request was
made for the same data, then the index values to the comapny-defined internal
tables couldbe provided in the interface to the API routine so lookup of the
data can be performed much quicker.
Robert Story <[EMAIL PROTECTED]> wrote: On Tue, 5 Jun 2007 08:29:17 -0700 (PDT)
Need wrote:
NH> I have Table1 (main table) and Table2 ("1394 table" which is an extension
of Table1). Lets say I have updated the Table2_container_init() routine to
indicate that Table2 should use the same cache that Table1 uses. Now, when
the first SNMP request is made and it is for Table2 (ex: "snmpwalk" request
perhaps) then the Table1_container_load() routine will be called. Is this all
correct so far?
Yep, _if_ the data isn't already loaded. It might be cached from a previous
call (to any of the tables).
NH> Inside the Table1_container_load() routine I will newly allocate all the
required rows as well as assigning an index to each of these rows. If this is
a subsequent call to Table1_container_load() then I will make sure to rebuild
the Table1 from scratch by allocating all new rows, but making sure to use the
same index values for each row as used before. Is this correct so far?
Yes, that is one way to do it. YOu don't _have_ to start from scratch, but
it's probably the easiest way.
NH> Lets say that Table1 has the following 4 rows (and 2 columns) populated so
far:
NH>
NH> index=1 type=1394
NH> index=2 type=DVI
NH> index=3 type=1394
NH> index=4 type=Tuner
NH>
NH> Now, since this SNMP request was for Table2, then the Table2_row_prep()
routine will eventually be called. This procedure's interface provides a
"row_context" data structure in which I can obtain the specific row index in
which this request is related. I can then simply populate this specific row
(from Table1) with the appropriate Table2 data .... is this correct?
Yes.
NH> For a "snmpwalk" request will the Table2_row_prep() routine be called only
twice and will the procedure interface supply row_conitext data for row 1 and 3
(since these are the indexes which relate to the 1394 Table2)?
No.
NH> I am not sure how the agent would know which rows of Table1 are being
used as extensions for Table2 data, so maybe you can clarify whether this
works or not.
It doesn't know, and this is exactly the point I was trying to make earlier.
NH> If is does not work like this then perhaps you can tell me how
I can determine which row from Table1 I need to populate with my Table2 data
when the Table2_row_prep() routine is called.
The row_prep routine will be called for _each_ row. Not a big deal if we're
talking a handful of rows, or you aren't too concerned about performance. This
is the point at which you have to deviate from the default code created by
mib2c. Normally row_prep is expected to return success or failure. What's
needed here is a return of MFD_SKIP, indicating that the current row should be
skipped if the type doesn't match the table.
It's trivial to write the code for row_prep, but the table interface code for
each of the secondary tables will have to be updated to handle this new return
value.
---------------------------------
You snooze, you lose. Get messages ASAP with AutoCheck
in the all-new Yahoo! Mail Beta. -------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
