[hopefully mostly coherent rambling below?]
This is more of a "history of where we are and how we got here" than a
directive. But it's important we consider how we got here before making
major changes to the code base, especially surrounding changes that
break backward compatibility.
Long long ago, CMU-SNMP supported only a couple of sun-based
architectures.
I wrote a bunch of patches to that for supporting ultrix, HPUX and Irix
(if I recall) as well as adding some extension mechanisms (the config
exec, proc, etc). I released the patches independently.
CMU-SNMP ended up getting dropped and I released my patches and the
updated code under a new name "ucd-snmp", as I worked for UCDavis at the
time.
Later, I left Davis we renamed the project to the more generic and
proper "Net-SNMP" since it was being actively worked on by folks around
the net.
Through all this process and until now, one core principal we adhered to
was a heavy concentration on backward compatibility. One reason is that
over the years we've learned many lessons about how long people continue
using a particular branch of code because they take and extend the
package and are scared up updating. Out of this fear of moving upward
(we still get questions about UCD-SNMP 4.1 at random times) grew the
policy of trying to make it as easy as possible to move to a future
version to ensure that their software extensions would always work into
the future. Or at least they'd be given suitable warnings (IE,
deprecation would last at least 2 major updates before an API that was
broken was removed).
The struggle with all of this, of course, is that the code begins to
look a little crusty in spots while we try to maintain support for so
many operating systems that we don't even have the ability to test
against internally. Developing the code ended up in roughly the
following notions/priorities:
A) write a configure test for any struct/api/feature/etc that wasn't
portable across all platforms.
B) failing the ability to do that, see if you could determine it at
runtime (see agent/auto_nlist as a reference point).
C) Failing that, create and use ifdefs and put defaults and exceptions
into two specific places:
C1) hardware defines would go into include/net-snmp/machine headers
C2) OS based defines would go into include/net-snmp/system
This last step greatly cut down on the number of machine specific
ifdefs. Much more of the code used to look like:
#if defined(solaris) || defined(hpux9) || defined(freedbsd8) ...
and we greatly reduced those.
D) Ideally, compartmentalize code into files that could be included and
excluded at will via configure flags. The mib-modules are done this
way, as are the transports, SNMPv3 security modules, etc. You get to
compile in only te items you need. And the mib-module's hardware
abstraction layers (HAL) meant that the code that dealt with SNMP
representations could be put into one file, and all the system
dependent code could be put into OS or hardware specific files to
implement the abstraction layers. This is what lead to directories
of code files like agent/mibgroup/host/data_access, for example.
E) We would maintain a number of back-release branches to help support
those unwilling to move forward for one reason or another (often
because they forked the code for internal use and the merge of a
later branch didn't go as cleanly as they hoped). Thus, we have a
number of back branches and LTS branches which we've maintained much
longer than promised).
The advent of moving (slowly over time) to solutions like C and D meant
that the code became much easier to maintain while still supporting a
wide wide range of operating systems. No small task.
So, do we have to stay like this in the future? Not necessarily. We
could abandon all past release stability and proclaim that we're making
a separation point and that Net-SNMP 6.0 will be a break-API point. In
fact, we've talked about that multiple times in the past. And we've
even talked about it recently, and in fact since we have a large patch
implementing CMake support over autoconf still to apply and I always
figured that would be a good point to move to a new 6.0 release with a
completely redesigned build system. Even with this new build system,
some of us had a discussion for how long to support *both* configure and
cmake, even though we knew how painful that would be. And there is a
strong question of how well cmake will support all the embedded build
environments we know Net-SNMP is being used in.
But, I urge caution when we collectively decide who are target audience
is. We don't know, and have no way to measure, the usage of Net-SNMP on
architectures it's deployed on. I could wax philosophically on why I
think we have so little data, but won't. One major point worth noting
is that we are the defacto SNMP stack for every operating system but
windows. Almost.
And more importantly, we don't know what APIs and what #defines are
being used in code bases out in the wild. The original code, way way
way back when, was not properly architected to provide a public/internal
names space and we suffer from that still today.
So before we go forward and remove #defines because we think they aren't
needed, and before we remove include files in the
include/net-snmp/system directory because they're old operating systems,
I ask you to think about whether or not we're willing to let that
segment of a potential user base go so they'll no longer receive bug
fixes, etc. You may think "No one in their right mind is using OS/2
still, right?" Well, it turns out that's likely very untrue. One other
thing I do professionally is operate DNS servers. And one of the things
I see in our data all the time is continued requests for A6 records,
which was the original form of AAAA (IPv6) queries. A6 was obsoleted in
2002 and yet we still see traffic for it. Want to guess which operating
system last published a release in 2001? Probably more than one,
honestly. The point being, I think you'd be surprised at the number of
old boxes out there still being maintained and updated with add on
packages like Net-SNMP.
Should we abandon them and say "from the 6.0 line we're only supporting
X,Y and Z"? I don't know. But I do know we can't move forward without
reopening the discussion. One of the reasons that people took so so so
long (15+ years) to switch from UCD-SNMP to Net-SNMP is that we did just
what I'm talking about: we broke the API in a number of places and
people were afraid to move, even though we had configure options to
enable as much backward compatibility as possible.
They say knowing your audience is the first step to publishing
something. My view of the audience is that they're very skeptical of
new code, very pressed for time and very much want minor updates over
major ones because of these trust levels.
[Note that with all the above, we also had to deal with the desire to
keep SNMP code stacks small. We still get requests for people that
don't want any openssl code in their compiled system because auditing is
worse, and --enable-mini-agent is very popular still, as is
--enable-read-only and --enable-minimalist). In fact, most of those
features were actually paid for which is important to understand because
when multiple organizations put money up to make a code-base reduce as
small as possible it must lead to the conclusion that compiled code
reduction is an important element.]
--
Wes Hardaker
Please mail all replies to net-snmp-coders@lists.sourceforge.net
------------------------------------------------------------------------------
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
