OK, I finally figured it out on my own. I'll post my findings here
for reference by my future self (who will undoubtedly forget) and
anyone else it might aid.
---
Using mib2c.raw-table.conf for a large table you have ordered access
to but don't want copied or cached into memory.
--------------------------------------------------------------------
- I didn't need to handle row create/remove, so I have no notes on
that (sorry).
- The 'indexes' param to the get/getnext routines works like this:
> Your table index is handed over in the 'indexes->val' union,
and size in 'indexes->val_len'. Suppose your defined table
index is an OCTET STRING of size 6 (MAC address). Then
'indexes->val_len' should be 6 and 'indexes->val.string' array
has your requested index.
> If your defined table has multiple indexes, then the second one
will be in 'indexes->next_variable' and so on.
(the rest is for getnext only:)
> If a table walk is happening, no index is passed and
'indexes->val_len' will be 0. This means retrieve the first
row. Once you do, be sure to set 'indexes->val_len' to the
right size and populate 'indexes->val' with the index of the
retrieved row (if there was one retrieved). You'll need to do
that for any row retrieved (not just the first).
> You do not need to worry about memory storage for
'indexes->val'. Those members are pre-loaded to point to the
'buf' array in indexes. That array is 40 bytes. If your index
is larger than that... I'm not sure what you do.
- Once you've retrieved your row data, you need to allocate the
struct the stub code defined for you (something like
'myFooTable_entry') with:
row = SNMP_MALLOC_STRUCT(myFooTable_entry);
netsnmp_assert(row);
Fill that in with your retrieved data and return the 'row' pointer
(or NULL if no row could be retrieved).
- There are 2 important changes to the "_handler" function:
> You need to
SNMP_FREE(table_entry);
after each
switch(table_info->colnum)
statement. Otherwise you'll leak memory.
> In the MODE_GETNEXT case, the stub code sets error
SNMP_NOSUCHINSTANCE if there was no 'table_entry' returned.
This is apparently wrong. I had to change this to set error
SNMP_ENDOFMIBVIEW for all columns.
---------
On 12/15/2015 09:44 AM, Joe Lorenz wrote:
> I'm trying to implement a MIB defining a very large (read-only) table
> (~250k rows).
> My data source API already provides get/get-next in correct order and
> data format. I expected it to be straightforward to map the appropriate
> handler actions, but I'm struggling with the details.
>
> It seemed like mib2c.raw-table.conf would be the right way to go,
> avoiding any caching or copying of the entire set of table data (which
> is a requirement). What I've been unable to find is any actual example
> that uses this mib2c config. I'm lost on what needs to be done with the
> various structures (indexes, etc.) especially for the get-next.
>
> The table is read-only. I have no need to implement row add/remove.
> I'm using version 5.7.2.1 of the software collection.
>
> If anyone can point me to an example or otherwise provide some hints,
> that would be most helpful.
>
> Many thanks,
> -Joe
------------------------------------------------------------------------------
_______________________________________________
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
