Difference between revisions of "Table"
(Created page with "{{helper|Table|code=agent/helpers/table.c|documentation=table|example=agent/helper/testhandler.c}} The table helper is designed to take care of common tasks associated with stor...") |
|||
(2 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
{{helper|Table|code=agent/helpers/table.c|documentation=table|example=agent/helper/testhandler.c}} | {{helper|Table|code=agent/helpers/table.c|documentation=table|example=agent/helper/testhandler.c}} | ||
− | The table helper is designed to take care of common tasks associated with storing date in a row/column fashion. In particular, it parses incoming request indexes into associated column numbers and row-indexes. | + | The table helper is designed to take care of common tasks associated with storing date in a row/column fashion. In particular, it parses incoming request indexes into associated column numbers and row-indexes. Many of the other more specific table helpers inject this helper themselves, so typically you only want to inject this handler yourself if you're not using any of the other table helpers and are doing all the processing yourself. For an example, see the ''my_test_table_handler()'' function in the {{code|agent/mibgroup/testhandler.c}} file which implements a multiplication table using this ''table helper''. |
+ | |||
+ | By creating a table handler and injecting it into your calling | ||
+ | chain, or by using the netsnmp_register_table() function to register your | ||
+ | table, you get access to some pre-parsed information. | ||
+ | Specifically, the table handler pulls out the column number and | ||
+ | indexes from the request oid so that you don't have to do the | ||
+ | complex work to do that parsing within your own code. | ||
+ | |||
+ | To do this, the table handler needs to know up front how your | ||
+ | table is structured. To inform it about this, you fill in a | ||
+ | table_registeration_info structure that is passed to the table | ||
+ | handler. It contains the asn index types for the table as well as | ||
+ | the minimum and maximum column that should be used. | ||
+ | |||
+ | == Registering a table == | ||
+ | |||
+ | The ''netsnmp_table_registration_info'' structure needs to be filled out with the information about the table you're implementing, including what type the indexes are and the valid column numbers: | ||
+ | |||
+ | netsnmp_table_registration_info *table_info; | ||
+ | table_info = SNMP_MALLOC_TYPEDEF(netsnmp_table_registration_info); | ||
+ | |||
+ | /* EG, two indexes: one integer, and one octet string */ | ||
+ | netsnmp_table_helper_add_indexes(table_info, ASN_INTEGER, ASN_OCTET_STRING, 0); | ||
+ | |||
+ | /* what are the valid column number's will return data for? */ | ||
+ | table_info->min_column = 3; | ||
+ | table_info->max_column = 10; | ||
+ | |||
+ | /* register it (note: the other non-table setup requirements are not shown) */ | ||
+ | netsnmp_register_table(..., table_info); | ||
+ | |||
+ | == Accessing the parsed column and indexes == | ||
+ | |||
+ | The column and index data is stored in the normal [[Agent Architecture|handler method for passing data]], and the ''table helper'' provides an easy to use ''netsnmp_extract_table_info()'' wrapper around the extraction. This means the data can be easily retrieved and used as follows: | ||
+ | |||
+ | netsnmp_table_request_info *table_info; | ||
+ | table_info = netsnmp_extract_table_table_info(request); | ||
+ | |||
+ | DEBUGMSGTL(("my_handler", "This is the column we got: %d\n", table_info->column); | ||
+ | DEBUGMSGTL(("my_handler", "This is the value of the first index (an integer): %d\n", table_info->indexes->val.integer); | ||
+ | |||
+ | The table_info->indexes is a linked list of all the index values extracted from the OID, stored in a varbind_list structure. | ||
+ | |||
+ | '''Note:''' make sure to check for NULL or empty data. If an incoming OID is not complete or is not parsaable based on the table rules, the ''table helper'' will not be able to extract all the needed data from the request OID. |
Latest revision as of 15:26, 17 July 2011
Net-SNMP MIB Helper | |
Table | |
Documentation: | doxygen API |
---|---|
Code: | agent/helpers/table.c |
Example: | agent/helper/testhandler.c |
Other Helpers: | Agent Helpers |
The table helper is designed to take care of common tasks associated with storing date in a row/column fashion. In particular, it parses incoming request indexes into associated column numbers and row-indexes. Many of the other more specific table helpers inject this helper themselves, so typically you only want to inject this handler yourself if you're not using any of the other table helpers and are doing all the processing yourself. For an example, see the my_test_table_handler() function in the agent/mibgroup/testhandler.c file which implements a multiplication table using this table helper.
By creating a table handler and injecting it into your calling chain, or by using the netsnmp_register_table() function to register your table, you get access to some pre-parsed information. Specifically, the table handler pulls out the column number and indexes from the request oid so that you don't have to do the complex work to do that parsing within your own code.
To do this, the table handler needs to know up front how your table is structured. To inform it about this, you fill in a table_registeration_info structure that is passed to the table handler. It contains the asn index types for the table as well as the minimum and maximum column that should be used.
Registering a table
The netsnmp_table_registration_info structure needs to be filled out with the information about the table you're implementing, including what type the indexes are and the valid column numbers:
netsnmp_table_registration_info *table_info; table_info = SNMP_MALLOC_TYPEDEF(netsnmp_table_registration_info); /* EG, two indexes: one integer, and one octet string */ netsnmp_table_helper_add_indexes(table_info, ASN_INTEGER, ASN_OCTET_STRING, 0); /* what are the valid column number's will return data for? */ table_info->min_column = 3; table_info->max_column = 10; /* register it (note: the other non-table setup requirements are not shown) */ netsnmp_register_table(..., table_info);
Accessing the parsed column and indexes
The column and index data is stored in the normal handler method for passing data, and the table helper provides an easy to use netsnmp_extract_table_info() wrapper around the extraction. This means the data can be easily retrieved and used as follows:
netsnmp_table_request_info *table_info; table_info = netsnmp_extract_table_table_info(request); DEBUGMSGTL(("my_handler", "This is the column we got: %d\n", table_info->column); DEBUGMSGTL(("my_handler", "This is the value of the first index (an integer): %d\n", table_info->indexes->val.integer);
The table_info->indexes is a linked list of all the index values extracted from the OID, stored in a varbind_list structure.
Note: make sure to check for NULL or empty data. If an incoming OID is not complete or is not parsaable based on the table rules, the table helper will not be able to extract all the needed data from the request OID.