> Date: Sat, 1 Aug 2009 15:43:34 +0100
> Subject: Re: ucd-snmp vs. net-snmp (foot print)
> From: d.t.shi...@liverpool.ac.uk
> To: jpu...@live.com
> CC: net-snmp-users@lists.sourceforge.net
>
> 2009/7/30 Juliana Purjo <jpu...@live.com>:
> > Concerning MIB modules... Having looked at 4.2.x code base, I got an
> > impression there is some code repetition in the agent implementations.
>
> Almost certainly.
> One of the things driving the 5.x handler mechanism was the recognition
> that there was a lot of processing that is common across many MIB
> implementations. By introducing a chain of handlers to process a request,
> this has allowed the use of shared "helper" routines, which can consolidate
> this common processing into one block of code.
>
Sounds good. I really ought to have a better look into the v5.x net-snmp...
> > Also there seems to be quite a lot of static buffers (defined inside
> > functions) that are mostly sitting unused eating runtime memory?
>
> Quite likely.
> Static buffers typically offer a simpler, safer and more time-efficient
> approach than dynamic allocation for internal scratch working space.
> In most environments, the size costs are not particularly significant.
Static buffers are simple, efficient and very fine. But I fail to see the need
to have separate buffers for each objects. I do not know if it makes any sense,
but maybe we could have a function/API to get a pointer to a static buffer of
desired size, which the agent code would utilize instead of using private
static
buffers. According to my understanding, as net-snmp is not multithreaded,
(without knowing the architecture very well) I think it might work to reset
the static buffer "unused area" pointer in the beginning of each request,
and allow requesting multiple memory areas within one SNMP request;
the size of the whole buffer could be a constant. [We could easily insert checks
for overflow (sum of allocation sizes exceeding the total buffer size) and
(development time) debug statements to map how big buffer we at most need
in case somebody wants to tweak the buffer size; also buffer overflows
could be checked easily by filling the buffer with magic numbers in the
beginning of a request handling.]
> It would be fair to say that the Net-SNMP agent is not really geared
> towards embedded systems, where code size may well be of greater concern.
Is there interest towards such tweaks?
> > Is it quick to outline what kind of additional features are we talking here?
>
> Not really.
> The UCD line has been essentially dead for something like 6-7 years.
> (The 4.2.7 release was simply a housekeeping release, to pick up
> a number of bug fixes - 4.2.6 was the last "active" release on this line).
>
> I can't really recall everything (or even the more important stuff) we've done
> since 2002!
>
I understand.
> > Thinking of replacing v4 net-snmp, is it possible to disable most of this
> > new weigth (with appropriate ./configure invocation)?
>
> Not easily.
> You'd probably need to use configure to select the MIB modules you want
> to include, then manually tweak the Makefiles (such as 'helpers/Makefile')
> to omit anything that these don't actually use.
>
> But this isn't something that the current build environment handles
> automatically.
>
I understand. And I think in a perfect world, much of this tweaking work could
be done by an intelligent linker...?
>
> Dave
_________________________________________________________________
More than messages–check out the rest of the Windows Live™.
http://www.microsoft.com/windows/windowslive/
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
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
