Re: ucd-snmp vs. net-snmp (foot print)

2009/8/3 Juliana Purjo <[email protected]>:
>                  But I fail to see the need
> to have separate buffers for each objects.

Remember that a single SNMP request may contain several different
MIB objects - possibly from different areas of the overall MIB tree.

   If the agent attempted to re-use a single shared buffer for implementing
multiple objects, then there is a very real danger that the processing for
one object could over-write the processing for another.   And introducing
multiple such buffers would then need some mechanism for indicating
which buffers were available.   Extra complexity, additional overheads,
and more to go wrong.

Given that in most environments, run-time size is not a significant concern,
using a separate buffer for each object feels to be a simpler, and more
(time-)efficient approach.



>      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,

No - that wouldn't work.
Although the agent itself is not multi-threaded, it is quite feasible for the
processing of multiple requests to be interleaved - particularly if they involve
one or more AgentX subagents, or similar "delegated" or "delayed" MIB
modules.


>> 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?

I have no idea.   Given that we do get occasional queries about support
for embedded systems, then possibly, yes.
But given that nobody can be bothered to feed back any of their experiences
in using this software on such systems, then perhaps no.

Remember that this is an Open Source project.  Nobody is paid to work
on the code, or gets any recompense for their involvement with it.
The bottom line is - if you need something doing, how badly?
Do you need it enough to do the work yourself?




>> 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.
>
> And I think in a perfect world, much of this tweaking work
> could be done by an intelligent linker...?

The question is more - what object files would need to be linked.
It's conceivable that an intellegent linker might be able to omit
unnecessary modules, but I'm not entirely convinced.
Particularly since the helper code ends up in a different library
from the MIB implementation code.   (And dynamic loading of
modules muddies the water further, since such a module might
require one of the hitherto unused helpers).

I'm inclined to think that such selection is best done as part of constructing
the build environment - perhaps by seeding the MIB module header files
with suitable "config_require" directives, and stripping down the default
list to the bare minimum.


Dave

------------------------------------------------------------------------------
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
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users