It seems the code automagically generated by *mib2c* was considering those
inexistent functions *netsnmp_cache_free()* and *
netsnmp_table_registration_info_free()*.
I created another file using an updated mib2c conf (see
http://gist.github.com/1259707) and those functions were not present.
Howev
On Fri, 2011-09-30 at 08:33 -0400, Rodrigo Hjort wrote:
> Hello Magnus,
>
> Actually I'm using the Debian package libsnmp-dev (v5.4.2.1), and
> here's the requested instruction:
If that is the case then it isn't that but then I am quite confused as
it builds for me using libsnmp-dev 5.4.3~dfsg-2.
Hello Magnus,
Actually I'm using the Debian package *libsnmp-dev* (v5.4.2.1), and here's
the requested instruction:
*$ net-snmp-config --configure-options*
'--build=i486-linux-gnu' '--includedir=/usr/include'
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--localstatedir=/var'
'--libexec
On Thu, 2011-09-29 at 23:52 -0400, Rodrigo Hjort wrote:
> Hello coders,
>
> I'm trying to compile a custom SNMP subagent with caching
> capabilities, but I'm facing this issue:
>
> rodrigo@zangaro:~/cache$ make
> gcc -I. `net-snmp-config --cflags` -c -o example-demon.o
> example-demon.c
> gcc -I.
Hello coders,
I'm trying to compile a custom SNMP subagent with caching capabilities, but
I'm facing this issue:
rodrigo@zangaro:~/cache$ *make*
gcc -I. `net-snmp-config --cflags` -c -o example-demon.o example-demon.c
gcc -I. `net-snmp-config --cflags` -c -o pgstatDatabaseTable.o
pgstatDatabaseTa
On Thu, 2005-08-25 at 00:07 +0200, Anthony Novatsis wrote:
> I am not sure what initalisation code that you are referring to?
The code where you first register the table, and set up the
cache handler. I'd expect this to look something like:
init_myTable() {
Hello Dave,
Sorry, I didn't cc my message to net-snmp-coders, so I am resending it.
I am not sure what initalisation code that you are referring to? The
way I understand it, the myvoid pointer can only be set/accessed from
within the get_*_data functions. If there was some way to initalise
this
On Thu, 2005-08-18 at 20:06 +0200, Anthony Novatsis wrote:
> I know it is possible to use the cache and the table iterator
> handlers. However, I would like to know whether it is possible to
> retrieve the netsnmp_cache structure within the get_first_data_point
> function (without the use of a glo
Hello all,
I know it is possible to use the cache and the table iterator
handlers. However, I would like to know whether it is possible to
retrieve the netsnmp_cache structure within the get_first_data_point
function (without the use of a global variable ;) in order to access
the loaded cache dat
On Fri, 02 Jul 2004 09:49:46 +0100 Dave wrote:
DS> RS> What you've proposed is pretty much the way it works now, except
DS> RS> the default for the flag is no auto next.
DS>
DS> Except that I'm suggesting that we have a quick push to convert
DS> *all* the (internal) helpers as far as possible (and
DS> - By default, handlers return success/failure, but don't explicitly
DS> call the next handler in the chain. This is (normally)
DS> done by the main netsnmp_call_next_handler routine.
DS> (i.e. AUTO_NEXT becomes the default)
RS> Well, the problem ther
On Thu, 01 Jul 2004 11:15:10 -0700 Wes wrote:
WH> > On Thu, 1 Jul 2004 13:39:46 -0400, Robert Story (Coders)
WH> DS> - By default, handlers return success/failure, but don't explicitly
WH> DS> call the next handler in the chain. [...]
WH>
WH> Robert> Well, the problem there is that it's not
> On Thu, 1 Jul 2004 13:39:46 -0400, Robert Story (Coders) <[EMAIL PROTECTED]>
> said:
DS> Ok - maybe an example would help.[...]
DS>
DS> Robert> Some of the helper handlers, however, do care. Again, bulk_to_next
DS> is the best example. It needs to do something before and after [...
On Thu, 01 Jul 2004 12:41:19 +0100 Dave wrote:
DS> Robert> I don't think what I'm proposing takes away any flexibility.
DS>
DS> Ok - maybe an example would help.[...]
DS>
DS> Robert> Some of the helper handlers, however, do care. Again, bulk_to_next
DS> is the best example. It needs to do som
On Wed, 30 Jun 2004 15:20:06 -0700 Wes wrote:
WH> > On Wed, 30 Jun 2004 13:08:25 -0400, Robert Story (Coders)
WH> 2) However, Robert is wrong that it helps APIs.
Thems theres fightin' words. I would understand 'I disagree', but 'wrong'
seems a bit strong.
WH>Since we can not and
WH>s
t we shouldn't let [the cached data become invalid] mid-request.
DS> [...]
DS> Actually, having put it that way, I think you're probably right.
DS>
DS> So the cache handler probably needs to set an internal lock when it's
DS> first called (i.e. at the beginning of the fi
DS> I think the pipeline has some advantages - it's somewhat more flexible
DS> in terms of exactly when and where the next handler is called,
DS> and what (if anything) is done afterwards.
Robert> I don't think what I'm proposing takes away any flexibility.
Ok - maybe an example would help.
Suppo
her* of these
DS> netsnmp_cache *
DS> netsnmp_extract_cache_info(netsnmp_agent_request_info * reqinfo)
DS> void *
DS> netsnmp_extract_cache_data(netsnmp_agent_request_info * reqinfo)
DS> What do you think?
Robert> Add in code to make the cache name something uniq
> On Wed, 30 Jun 2004 13:08:25 -0400, Robert Story (Coders) <[EMAIL PROTECTED]>
> said:
DS> Robert> it stands at 2-1.
DS>
DS> Yes - I'm getting used to that :-(
Robert> Well, we've all been there. You just need to come work for us,
Robert> and then together we can rule the world! Mwuuuh
On Wed, 30 Jun 2004 15:52:23 +0100 Dave wrote:
DS> Having a set of handlers called "in sequence" is a perfectly reasonable
DS> alternative model. I'm unconvinced as to whether it's necessarily
DS> better than the current "pipeline" model, but it's certainly not a
DS> poor choice.
I'm not sure I
netsnmp_cache *cache;
DS> cache = netsnmp_agent_get_list_data(reqinfo, CACHE_NAME);
DS> return (cache ? cache->magic : NULL );
DS> }
DS> ------
DS>
DS> What do you think?
Add in code to make the cache name something unique (see recent addit
_agent_get_list_data(reqinfo, CACHE_NAME);
return (cache ? cache->magic : NULL );
}
----------
What do you think?
DS> The cache handler *already* had a handle to the cache, using the 'myvoid'
DS> pointer. So using the reqinfo list is just g
Robert> Replace 'eliminating the redundant loop' with 'eliminating an
Robert> unnecessary function call and reducing the stack depth.' (Have you
Robert> looked at a back trace from a low level handler? It's horrendous.)
No argument there!
Robert> I think that it's that it's a change from how
the fewer unnecessary function
calls we make, the better.
DS> But this feels somewhat less confusing than the AUTO_NEXT behaviour,
DS> which I really don't think is necessary.But I'm probably in a
DS> minority of one yet again.
Well, I don't know if any of the other core
ust extended the concept into the cache handler,
DS>
DS> But the only reason that the cache needed to be linked with the reqinfo
DS> parameter was that this was the only way that lower handlers could get
DS> hold of it.
Well, technically, the handler had to have requested the cache in th
hing
Robert> . This was an extension of your work...
Robert> I just extended the concept into the cache handler,
But the only reason that the cache needed to be linked with the reqinfo
parameter was that this was the only way that lower handlers could get
hold of it.
The cache handler *alr
Dave> But now the handler seems to return success or failure immediately,
Dave> without actually calling any lower-level handlers.
Dave> This seems to be at odds with my understanding of the handler design.
Robert> A while ago I added a 'flags' field to the mib handler structure.
Robert> One of
and double-check that the cache had been loaded. Which wouldn't
have always worked quite like you expected, for the reasons noted in the bug
report.)
I just extended the concept into the cache handler, attempting to optimize and
also to prevent the cache from being re-loaded mid-request. But
then passes control on to the next handler. I'm pretty sure that
DS> when I first wrote the original cache handler, it took this basic form.
DS>
DS> But now the handler seems to return success or failure immediately,
DS> without actually calling any lower-level handlers. At first si
Robert,
thanks for having a look at the caching problems.
But I'm a little concerned/confused about the cache handler
as it currently stands.
Firstly, there appears to be an inconsistency in the
way that the cache is referenced
At the beginning of the handler (and again in the C
30 matches
Mail list logo
