On Tue, 21 Aug 2018 at 20:59, Magnus Fromreide <ma...@lysator.liu.se> wrote: [..] > I have been thinking about it but not gotten anywhere with it. > > Some mibs are utterly unrealistic to put outside of the agent, this is > mostly the ones that deal with internal state like 'snmp' and 'nsModuleTable'. > > Others should be possible to put outside the agent but there are dependencies > and other things that make it harder, this does include some rather surprising > subsystems like SMUX and AgentX even if it will require some further > modularization work in the core agent and maybe some squinting when reading > the rfc's as they sometimes are working against each other. > > I think this work would be worthwhile, not least due to it getting rid of all > the umpteen dependencies of libnetsnmpmibs.so and there is also a security > advantage if the network facing core agent can be reduced as much as possible. > > In any case the first obstacle for this is that the net-snmp build system > valiantly fights this mode of operation pretty hard so that need to be > redone. > > I have not gotten further down thi path but if you gain any new insights then > that is always nice to hear about.
OK, so looks like answer on my question is negative .. I've not been looking yet closer on snmpd code structure. I know that current net-snmp build framework is far from out of the book ac/am/lt framework and I think that it would be good first to bring it to kind of std ac/am/lt where some sets of the source files can be put as components used as part of the bigger fixed library or to link DSO modules. I think that I can try to prepare some set of patches lining whole net-snmp to use standard ac/am/lt then post those patches here to have some opinion of other people and *if* it will be ready then submit those initial corrections as git PR(s). When current build framework will be more clean separating MIB by MIB to build snmpd single MIB support as optionally loaded DSO can start. Biggest obstacle which I see ATM is fact that current code is used on many platforms so some cleanups must be done enough carefully to not break possibility to build net-snmp source tree on all those currently used platforms. I'm almost sure that cleaning build framework to use std ac/am/lt will make net-snmp even easier to keep it in healthy state on all possible platforms. Any other comments? PS. I don't want to promises to much (just started new contract and still don't know how much time I could have in next couple of weeks) but will try to back with some patches in week or two. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
