On 24 August 2011 06:43, sujata patra <[email protected]> wrote: > Apology If I resending it again.
Apologies would not be necessary if you did *not* resend such requests. Any support that I can offer for this project is done on a "spare time" basis, and the same holds true for most of the other developers. As such, you should post your question and WAIT for an answer. Nagging us for an immediate response is unlikely to be popular or effective. If you need a more rapid/reliable response, then I'm sure there are consultants available who can provide such a service for a suitable fee. Personally, I have more than enough to deal with in my normal paid job. And surely you wouldn't begrudge me a day spent with my nephew and neices? </rant> > Thanks. But what about get_first_data_point() and get_next_data_point() ? > They also need to access the tcp_head right ? next_data_point doesn't need to access the head - no. This is passed the "current location" in the list, so can move on to the next entry automatically. You are quite correct about get_first, though - this does indeed need to start at the beginning of the list. If you were looking to control direct access to the list head, then the obvious approach would be to define a function that returns this entry, and call that from the get_first hook. Though personally, if you're using a cache-based approach, then I can't see the point of working with the iterators at all. It's one of the less efficient implementation approaches. You're loading all of the entries into the agent anyway - why not hold them in a way that they can be accessed directly? That's the purpose of the table_tdata framework, which would be my personal helper-of-choice for most cases. Dave ------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
