On Wed, 2005-10-19 at 19:08 +0100, Paul Davies wrote:
> I am also using the mib2c.array-user.conf as it lended itself better
> to some of my tables.
Robert's more familiar with that helper than I am, but I'll see
what I can do. He'll doubtless chip in when I go wrong.
> Again, I want to access the add and delete
> functions from an agent perspective and not a SNMP request.
That's precisely why I'm working on a generic table API - to clarify
exactly what operations might be needed to work with "an SNMP table".
Not just for processing SNMP requests, but in order to link this in
with the wider subsystem that it's monitoring/managing.
If you've got time, you might like to have a quick look at the file
'agent/helper/table_generic.c' (in the current main CVS code), and
let me know what you think.
> Again,
> I have issues in understanding how I can remove a row but this time
> because I have multiple indexes.
>
> CONTAINER_REMOVE requires a container and in order to get that
> CONTAINER_FIND requires an index. I can pass the indexes of a row
> into a function easily enough as char* parameters but then need to
> get it into netsnmp_index format.
i.e.
row = table_generic_row_get_byidx( table, index(es) );
table_generic_remove_row( table, row );
Yes?
> I have a table with 2 OCTET_STRING columns as indexes. myTable.h
> has a structure myTable_context_s that says that these two indexes
> are internal and the first entry is of course netsnmp_index index;
> The internal comment stumped me a little.
Part of the purpose of developing the generic API (and then applying
it to the individual table helpers) is to protect you from this sort
of detail. You shouldn't need to have to worry about how a particular
helper handles things internally.
> Does this netsnmp_index equate to my two OCTET_STRING indexes
Yes.
> and if so, how should that be represented. Supposing my 2 OCTET_STRINGS
> indexes are "Foo" and "Bar". Would it be represented as,
>
> netsnmp_index *index;
> oid index_oid[7];
>
> index = SNMP_MALLOC_TYPEDEF(netsnmp_index);
> index_oid[0] = 6; // because I am concatenating the indexes
No - this would be '3', being the length of the first string
value.
> index_oid[1] ='f';
> index_oid[2] ='o';
> index_oid[3] ='o';
> index_oid[4] ='b';
> index_oid[5] ='a';
> index_oid[6] ='r';
>
> index->oids = index_oid;
> index->len = 7;
But apart from the length error (and the confusion over lower/upper
case values with 'index_oid[1]' and 'index_oid[4]'), that's
certainly one possibility.
It depends on how the MIB table was defined.
If the table is defined using
INDEX { oneString, IMPLIED twoString }
then the code above would be correct. (Unnecessary when
the generic API routines become available, but correct).
If it's defined using
INDEX { oneString, twoString }
then 'index_oid' would need to contain 8 subidentifiers (not 7),
and include the length of the second string as well.
I.e.
index_oid[] = { 3, 'F', 'o', 'o', 3, 'B', 'a', 'r' };
[Insert additional plug for generic table API here too :-) ]
Dave
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
