module.c revision 30698f336503439d11933541bc5fac87b3f8b916
0N/A * The contents of this file are subject to the terms of the 0N/A * Common Development and Distribution License (the "License"). 0N/A * You may not use this file except in compliance with the License. 0N/A * See the License for the specific language governing permissions 0N/A * and limitations under the License. 0N/A * When distributing Covered Code, include this CDDL HEADER in each 0N/A * If applicable, add the following below this CDDL HEADER, with the 0N/A * fields enclosed by brackets "[]" replaced with your own identifying 0N/A * information: Portions Copyright [yyyy] [name of copyright owner] 0N/A * Copyright 2006 Sun Microsystems, Inc. All rights reserved. 0N/A * Use is subject to license terms. 0N/A#
pragma ident "%Z%%M% %I% %E% SMI" 123N/A * Update types. Single-index and all are mutually exclusive. 123N/A * Locking rules are straightforward. There is only one updater thread 123N/A * for each table, and requests for update that are received while 123N/A * another update is in progress are ignored. The single per-table lock 242N/A * protects all the data for the table, the valid_stamp and max_index 123N/A * tags for new data, and - importantly - all the hidden static data 123N/A * used by the Net-SNMP library. The result return callbacks are always 123N/A * called in the master agent thread; holding the table lock is 123N/A * therefore sufficient since only one table's callback can be run at 123N/A * any one time. Finer-grained locking is possible here but 123N/A * substantially more difficult because nearly all Net-SNMP functions 123N/A * In practice this is more than adequate, since the purpose of 242N/A * threading out the update is to prevent excessively time-consuming 123N/A * data collection from bottlenecking the entire agent, not to improve 123N/A * result throughput (SNMP is not intended to be used for applications 242N/A * requiring high throughput anyway). If the agent itself ever becomes 123N/A * multithreaded, locking requirements become limited to our local 123N/A * per-table data (the tree, max_index, and valid_stamp), and the 242N/A * implementation could be revisited for better performance. 0N/A * If name is the name of a module we have previously seen and indexed, return 0N/A * data for it. Otherwise, return NULL. Note that the module may not be 0N/A * valid; that is, it may have been removed from the fault manager since its 0N/A * information was last updated. 0N/A * If index corresponds to a module we have previously seen and indexed, return 0N/A * data for it. Otherwise, return NULL. Note that the module may not be 0N/A * valid; that is, it may have been removed from the fault manager since its 0N/A * information was last updated. 0N/A * If index corresponds to a valid (that is, extant as of latest information 0N/A * from the fault manager) fmd module, return the data for that module. 0N/A * Otherwise, return the data for the valid module whose index is as close as 0N/A * possible to index but not lower. This preserves the lexicographical 89N/A * ordering required for GETNEXT processing. 0N/A * Possible update the contents of a single module within the cache. This 0N/A * is our callback from fmd_module_iter. 0N/A * An fmd module we haven't seen before. We're obligated to index 0N/A * it and link it into our cache so that we can find it, but we're 81N/A * not obligated to fill it in completely unless we're doing a 0N/A * thorough update or this is the module we were asked for. This 0N/A * avoids unnecessary iteration and memory manipulation for data 89N/A * we're not going to return for this request. 0N/A * We allocate indices sequentially and never reuse them. 0N/A * This ensures we can always return valid GETNEXT responses 0N/A * without having to reindex, and it provides the user a 0N/A * more consistent view of the fault manager. * Update some or all module data from fmd. If thorough is set, all modules * will be indexed and their data cached. Otherwise, updates will stop once * the module matching index has been updated. * Returns appropriate SNMP error codes. * The current modinfo_update implementation offers minimal savings * for the use of index-only updates; therefore we always do a full * update. If it becomes advantageous to limit updates to a single * index, the contexts can be queued by the handler instead. * The Net-SNMP template uses add_indexes here, but that * function is unsafe because it does not check for failure. * only kind we do). They perform two functions: * - First, frob the request to set all the index variables to correspond * to the value that's going to be returned. For GET, this is a nop; * - Second, find and return the fmd module information corresponding to * the (possibly updated) indices. * These should be as fast as possible; they run in the agent thread. * If we have no index, we must make one. "index %lu; trying next column\n",
index));
"index %lu; stopping\n",
index));
* table_info->colnum contains the column number requested. * table_info->indexes contains a linked list of snmp variable * bindings for the indexes of the table. Values in the list * have been set corresponding to the indexes of the * request. We have other guarantees as well: * - The column number is always within range. * - If we have no index data, table_info->index_oid_len is 0. * - We will never receive requests outside our table nor * those with the first subid anything other than 1 (Entry) * nor those without a column number. This is true even