Thanks a lot for your detailed explanation. I am able made the changes
________________________________
From: Dave Shield <[email protected]>
To: sujata patra <[email protected]>
Cc: net-snmp-coders <[email protected]>
Sent: Thursday, August 25, 2011 12:27 AM
Subject: Re: is there any way I can avoid global variable?
On 24 August 2011 17:25, sujata patra <[email protected]> wrote:
> I am confused looking at the structure definition of struct netsnmp_cache_s.
> It hooks the _load() and _free() with the root oid.
No - the OID that is stored as part of the cache structure has nothing to
do with when the load/free routines are triggered. This field is purely
concerned with the nsCacheTable registration - i.e. the mechanisms for
run-time configuration of caching behaviour.
The load hook is triggered by the cache_helper handler,
which is registered as part of the handler chain for *both* of the tables.
If you look at the ifXTable code that I pointed you to, almost the last
task within the _ifXTable_initialize_interface() routine is to retrieve
the (shared) cache structure, and insert the cache helper into the
handler chain, before registering the table.
It's that last netsnmp_register_table() call that connects the handler
chain (and hence the cache load/free routines) with the root OID of
the table. So when requests arrive for OIDs within that table, the
cache will be refreshed if it's out of date.
The OID in the cache structure will typically be set as one of the
two (or more) tables, but it doesn't have to be. You can set this
as anything you want - all it affects is the index of that row in the
nsCacheTable. You could set it to a completely unconnected
table, and the agent wouldn't care a jot.
(Though anyone looking at the nsCacheTable might get very
confused!)
> If the snmpcmd request is there only for the second table , it will not find
> any load function as there is no registration of _load() function for the
> second table.
No - that's not how it works.
> I am thinking to get the cache by calling netsnmp_cache_find_by_oid() and
> check the cache->expired from get_first_data_point().
No - you are missing the point of the cache helper.
The cache expired flag will be checked (and the load function called
if necessary)
by the cache helper handler - which is all done *before* the iterator handler is
reached (and hence long before the get_first_data_point() routine is called).
> If the cache expired, call the common _load() function of the two table.
> I hope that is okay to do .
No!
Please use the cache helper in the way that it has been designed.
Insert it into the handler chain, following the model that I pointed
you towards, and it *will* do what you need.
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