DS> The other thing that might help is a move towards greater use of DS> the Hardware Abstraction Layer that I started to put in place a DS> couple of months ago. It currently only covers CPU and memory DS> (and only for Linux boxes), but it's a step in the right direction.
I noticed this when it went in, and the thing that surprised me was the directory hierarchy. I remember long threads discussing this, and I thought we had decided to keep the abstraction stuff with the associated MIB module (thus all the data_access directories in agent/mibgroup/*-mib/, and the corresponding include directory). If we are going to have centralized hardware abstraction, it would make sense to have the software abstraction centralized as well. In either case, I think we should do one or the other, not both. The directory hierarchy is bad enough as it is. So the question is, which do we go with? The individual data_access directories were introduced in 5.2, but I don't think directory structure falls under backwards compatibility, so I wouldn't scream bloody murder if we reverted to the idea of centralized data abstraction directories. -- Robert Story; NET-SNMP Junkie Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp> Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders> You are lost in a twisty maze of little standards, all different. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
