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

 

> Date: Mon, 3 Aug 2009 08:34:28 +0100
> Subject: Re: ucd-snmp vs. net-snmp (foot print)
> From: [email protected]
> To: [email protected]
> CC: [email protected]
> 
> 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.


Also in embedded Linux, the executable size is more important than runtime memory size. The flash sizes are still measured in single digit megabytes... And the linked application size seems to be the same whether you have 100kb of static buffer or 1kb of static buffer, probably the number of static buffers also does not make a difference.


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


Okay, more complicated than I thought... I agree the implementation effort probably is not worth the trouble.

 

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


My meaning was more to ask whether the project is open for such help.


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


Out of personal curiosity I am interested in doing some experimentation... If this curiosity ever channels into action, I will let you know (just doing simple test compilation with bare minimum configuration would give some hint about the executable size difference, even doing this with the x86/x86_64 tool chain).


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


I remember very well this is an Open Source project, and I am very thankful for the work you and other people are doing to help this project, whether by answering uninformed questions or improving net-snmp...


> >> 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).


Yes, the linker could only optimize when statically linking the net-snmp... And this too is just hypothetical, meaningless babbling (unless done in a proper tool chain forum).


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

 

Okay.


> 
> 
> Dave


_________________________________________________________________
Share your memories online with anyone you want.
http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1

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