> On Wed, 1 Jun 2005 18:45:23 -0700 (PDT) Surya wrote: > SP> What's the active code for ifTable? > SP> > SP> I see that > SP> 1. There are 2 files. interfaces.c, ifTable.c in > SP> mibgroup/mibII directory. > SP> 2. Also, under mibgroup/if-mib, there is code in > SP> directories data_access, ifTable. > SP> > SP> Which is active and which is preferred? > > interfaces.c is active unless --enable-mfd-rewrites > is specified AND the > platform is Linux. Then if-mib is used.
So, for now, I will use interfaces.c.. Hope its not going to be a big problem...later. When do you think there will be a complete migration to if-mib? > SP> I kind of understand the code in interfaces.c > but not > SP> the other code in if-mib yet. I am going through > the > SP> on-line manual but is there a more easier to > SP> understand document? > > Which on-line manual? The MFD tutorial would be most > applicable. Are you referring to the same tutorial link posted by Wes? > SP> I have read in the mailing list archives that > SP> interfaces.c might be the correct version..but > not > SP> preferred, is that still true? > > Well, the idea is that more platforms should be > ported to the if-mib style, and > then it might become the default. It moves the > platform specific code out of > the MIB code. > > SP> Information for the ethernet interfaces is > stored > SP> in the DB by other application [...], I would > SP> like SNMP to call the DB API to get the data and > this > SP> I was trying to do in the "SNMP GET leaf > SP> handler...call back function" .. > > For scalars, that should be easy. There should be a > 1-1 correspondence between > an OID and a DB record. Tables might be more > complicated, depending on whether > or not interfaces are static or they come and go. > > SP> Can you quickly point to me the code where I can > SP> register the call back function? > > I'm not sure that we have a handler the deals with a > callback function to get > the value, but one shouldn't be to hard to put > together. I have already implemented a few scalar variables. I need to read the tutorial thoroughly and then probably can understand your comments about tables. > SP> Finally, DB also sends some autonomous > notification to > SP> various subsystems or processes (not sub-agents) > on > SP> the line card. As per my design SNMP needs to > listen > SP> on a "known" message queue and when it gets such > SP> notifications it should trigger SNMP traps... > > Thats a slight problem, as the agent uses select() > for it's main loop, and > select doesn't work with message queues. So, you > have two options: a periodic > alarm to check the message queue, or use a pipe to > another thread/process which > can wait on the message queue and alert the agent > when it is ready. > BINGO!! I was thinking the same after looking at the select() call. But posted here to make sure I don't go on the wrong path. Your comments validate my thought. Thanks.. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
