Thanks Wes for the elaborate write-up.
On 05/14/18 14:07, Wes Hardaker via Net-snmp-coders wrote:
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.
Are there any features for which (C) is the only option because both (B)
and (A) are impossible? I have not yet encountered any such features.
Personally I think we should get rid of the include/net-snmp/machine and
include/net-snmp/system headers and also of any code in the form of
#ifdef ${uname}${version}.
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.
Some of the config_require() statements are guarded by symbols defined
in <net-snmp/net-snmp-config.h>. Is it guaranteed that
<net-snmp/net-snmp-config.h> is available and complete at the time the
config_require() analysis happens? Every time I rebuild the Net-SNMP
code base I notice that some of the configure checks happen after the
config_require() analysis has finished.
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.
Does this mean that some developers are working since considerable time
on a conversion of the build system to cmake but that that patch is not
yet publicly available? Will other developers have the chance to review
that patch before it gets applied?
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.
Personally I consider it very important to maintain backwards
compatibility for the *documented* Net-SNMP API. However, I'm not sure
we should support users who rely on symbols from
<net-snmp/{machine,system}/...> that are neither documented nor have a
NETSNMP_ prefix.
Thanks,
Bart.
------------------------------------------------------------------------------
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
