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.

-------------------------------------------------------------------------
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

Reply via email to