On Sun, 16 Jan 2005 21:39:44 -0800 [EMAIL PROTECTED] wrote: WC> The immediate issue concerns the initialisation of the enumeration WC> in which interfaces are described. The ifTable code will make WC> calls to SE routines, such as when the ifTable is initialised. WC> [...] WC> What concerns me most immediately is how the "interfaces" list WC> is initially created. It is hard to tell if the enumeration WC> is *instantiated* within the code of ifTable_cache_load(), or WC> if the *instantiation* occurs at some earlier point.
The secret to the ifIndex via the SE routines is in _access_interface_entry_save_name(). The ifIndexes are allocated as new interface names are encountered. This is a first-come-first-served process. Currently, it would almost certainly be the ifTable populating this data. Except that, IIRC, the se stuff isn't used on Linux. ioctl calls are used to coordinate ifNames and indexes. WC> Also, in the MFD on-line documentation, at URL WC> WC> http://www.net-snmp.org/tutorial/tutorial-5/toolkit/mfd/ WC> if-mib/ifTable/data_access.html WC> WC> the routine *_choose_proc_format* is not defined, and the meaning WC> and usage of constants like *NETSNMP_CACHE_PRELOAD* are not WC> defined. Hmmm... ok. Write up a bug report and I'll get that fixed. The proc format is just to handle the different file formats between Linux 2.2 and 2.4 kernels. CACHE_PRELOAD tells the cache registration routine to call the cache_load routine immediately, instead of waiting for the first request for the if-table. This ensures that, if the se based ifName/index mapping is used, it is available asap during startup. WC> One can follow the tutorial and compare with the code WC> provided in the IF-MIB implementation at ./agent/mibgroup/if-mib, WC> so as to glean useful detail. Yet, the if-mib implementation in WC> the Net-SNMP toolkit is quite different from that presented in WC> the tutorial. This is bound to result in confusion for users. The tutorial, as stated in the introduction, is a simplified version to serve as a simple example. Perhaps documenting the actual if-mib in the agent can be a future 'advanced' tutorial. WC> Other items not well documented include the defined constants WC> associated with SE usage, such as SE_DNE. I tend not to like WC> cryptic names, and DNE does not mean WC> anything to me. I think that one is Daves's, and I'd bet that DNE = Does Not Exist. WC> I will also argue for the inclusion of textual documentation that WC> facilitates understanding of cryptic names at each and every point WC> of such usage. This gets back to the nature of some (most?) programmers.. they like writing code, documentation. We welcome documentation contributions. We have started using doxygen, so things are *much* better than the used to be. WC> The writing of code is not a spectator sport, nor WC> is it well practiced where documentation is underexpressed, WC> underutilised. Again, you get what you pay for. We'll glady refund your purchase price. :-) If you want professional documentation, I hear SNMP Research has a nice toolkit. Anyway, we get the point that you are disappointed in the lack of documentation. No need to belabor the point. We don't mind you asking questions, and we'll try to explain, but it's very unlikely that we'll have time to sit and write out something to meet your criteria for good documentation. Unless, of course, you are willing to provide funding. :-) WC> I suspect that the call to find a name in an enumeration will WC> result in the insertion of that name into the enumeration if the WC> seach fails. Yet, I am in this case guessing, and this is a very WC> inefficient means to acquire knowledge of a tool. After all, my WC> guess could be incorrect. Further, the incorrectness of my WC> guess may not become known to me for some time, and by that time, WC> I may have written a lot of code which is consequently incorrect. That's why we give you the source. WC> Perhaps other users will find my comments and questions, and any WC> answers offered, to be of use in their study and usage of the WC> Net-SNMP toolkit. Which is why we have the lists to try and answer questions. Again, the questions are good ones, and I'm glad to answer them, but lighten up on the criticism. Out of time for today, will hit your other emails. tomorrow... -- 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-users> You are lost in a twisty maze of little standards, all different. ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
