2 * Host Resources 'wrapper' interface
3 * calls the per-group interfaces from 'hr_*.h'
6 config_require(host/hr_system)
7 config_require(host/hr_storage)
8 config_require(host/hr_device)
9 config_require(host/hr_other)
10 config_require(host/hr_proc)
11 config_require(host/hr_network)
12 config_require(host/hr_print)
13 config_require(host/hr_disk)
14 config_require(host/hr_partition)
15 config_require(host/hr_filesys)
16 config_require(host/hr_swrun)
17 config_require(host/hr_swinst)
19 /* add the host resources mib to the default mibs to load */
20 config_add_mib(HOST-RESOURCES-MIB)
21 config_add_mib(HOST-RESOURCES-TYPES)
23 /*********************************************
25 * A few words about the design of the Host Resources
26 * implementation - particularly as regards the hrDevice
27 * group and hrDeviceIndex. This (and hrStorageIndex) make
28 * use of the non-consecutive nature of SNMP instance identifiers.
30 * hrDeviceIndex is structured in a 'major/minor' form,
31 * with the high end indicating the type of device
32 * (following the enumerations of hrDeviceType) and the low
33 * end being used to differentiate between devices of that type.
35 * The implementation of walking through the available devices
36 * uses a pair of arrays of functions - indexed by hrDeviceType
37 * These are used to perform any initialisation needed for that
38 * type of device, and to step through the instances of that type.
39 * This latter 'get_next' routing returns the hrDeviceIndex (including
40 * the hrDeviceType major number), or -1 if there are no further
41 * instances of that type.
42 * When all devices of a particular type have been processed, the
43 * initialisation function for the next device type is called,
44 * and so on until all devices have been proceesed.
46 * Similar arrays are used to provide type-specific functions to
47 * return the "common" device information (description, ID, status
48 * and error count), and to save any internal structures needed
50 * A final array is used to indicate whether hrDeviceIndexes are
51 * returned in a random order, or strictly increasing. In the
52 * latter case, this allows the search for a particular index to
53 * terminate as soon as the 'next' device is reached, without needing
54 * to check the rest of them. Similarly, once a particular type of
55 * device has been scanned, further types will not be examined unless
56 * a suitable index has not yet been found.
58 * The index used for hrFSIndex is also used as hrStorageIndex,
59 * for those storage areas corresponding to filestore.
60 * Additional storage areas (such as memory or swap space) are
61 * distinguished by index values greater than a defined constant.
62 * Currently these are individually defined entries, but other
63 * ranges could be implemented similarly.
64 * If hrFSIndex was re-implemented to reflect internal identifiers,
65 * it would be possible to reverse the sense of the current
66 * implementation, with non-filestore storage having indices
67 * less than a defined constant, rather than greater.
70 * Much of the detailed implementation of this group (as opposed to
71 * the implementation infrastructure outlined about) is likely to
72 * be very system-specific.
73 * The initial implementation (for HP-UX 9 and Linux) should be
74 * regarded as a 'proof of concept' example, rather than as
75 * finished, releasable code. This particularly hold for the
76 * disk device discovery code, which is gross in the extreme,
77 * and should never have seen the light of day!
78 * Hopefully this can be ripped out and given a quiet burial as
79 * soon as is decently possible.
81 * Now it's up to the rest of you to hammer this into some sort of
85 *********************************************/