On Thu, 2005-06-23 at 20:35, Bruce Shaw wrote: > It appears that we should be using the code from UCD-SNMP-MIB in both places > which is a Bad Thing, so I would be tempted to put it downstream somewhere > like agent/mibgroup/kernel_sunos5.c but that includes a whole bunch of stuff > we may not necessarily be interested in (eg. kstat). > > This again begs the question of a Hardware Abstraction Layer where we would > store the code for this kind of stuff and call it as needed by both MIBs.
Bruce - I'm hopefully about to make your day. I've just committed the first preliminary pieces of the Hardware Abstraction Layer, that we've both been talking about for so long. It only covers two types of hardware (CPU and memory), and it's only implemented for Linux-based kit - but it's a start. Have a look at 'agent/mibgroup/hardware' on the latest CVS tree. The next step is probably to move the equivalent bits of code for other architectures from the relevant HostRes/UCD files, until the MIB-specific code *just* contains references to these HAL-based data structures - at which point we can consolidate the various architecture-specific code in these MIB-specific files together into one. This will almost certainly need some adjusting to the initial HAL framework, but we needed to start somewhere. The most immediately obvious problem is the regular probing of CPU stats on some other architectures. I've got some ideas about how to tackle that in an architecture-independent manner, so as to implement the cooked CPU statistics consistently across all architectures, and implement the hrProcLoad object for the first time. Anyway, take a look at the basic framework, and see what you think. Dave ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Net-snmp-users mailing list [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
