I don't disagree (or I certainly don't disagree completely) with anything that has been said so far. But I think it's easy to assign disproportionate angst to this or that problem.
For example, and that's all this is, but one of the most serious issues I think we have in the openssl code is that macros are (ab)used heavily because the we have a legacy rule against the use of inlines. One of the other guys can probably remember why this is (I don't), but I would suspect that it *is* related to support for some obscure platform or toolchain. My point is that if we collapse the issue down to "trimming the list of supported platforms", we could overlook the actual benefits in many cases. In this example, we may miss the fact that the no-inlines rule is in fact no longer justified. I've been in the bowels of the linux kernel over the last few years (though nothing compared to Ted), and it's vivid to me how inlines, however evil they might appear to some people, are still much less evil than macros. (In nearly all cases.) A similar example is for symbols like NO_SYS_UN_H. You'll find #ifdefs for that whenever there are headers and code that deal with domain sockets. I agree with Ted about the fact that it's much better to get rid of the #ifdefs where that stuff is used, and instead #ifdef it (or "arch/"-split it) in the one place where domain socket stuff is *declared*. "#ifdef the called, not the caller". Any sensible and pragmatic approach to reviewing the list of supported platforms should include an effort to qualify these kinds of downstream effects. (Ie. does removing or keeping a particular platform change anything? Or allow anything to be changed for the better?) Implicit in the discussion about platforms is the question of the build system. I have a number of thoughts on this too, but have refrained from doing anything about them so far because I could easily bite off more than I can chew, time-wise. In fact, I've heard that the use of ordinals might be avoidable even on windows, and it's clearly useless everywhere else (except VMS?), but it's a maintenance hassle all the time for everyone who is making updates (especially across more than one branch). A discussion about platforms ought to address this too. While I'm on a roll, another example. Things like crypto/dso/ really only exist to cover the fact that there is no notion of "arch/" in the code-base. I dare say there are a number of other places and abstractions where, if we used a more OS/kernel style of coding, things might simplify down. Loading and using a shared-library would have a single *internal* API, and that API itself would be implemented within the appropriate sub-directory of "arch" to suit the target platform. As things stand, we have an *exported* DSO API, which is pluggable by built-in and/or caller-provided modules, despite the fact that on a sensible system only one such module exists and there would be no reason for a caller to plug in a replacement. I wrote that DSO stuff, so I'm not hating on anyone but myself, but it was done that way because that's in keeping with how everything else is done, it seemed (and seems) to be the consistent thing to do. In other words, it's symptomatic of a more general issue. A discussion about platforms ought to address this sort of thing too. Which leads me I guess to a bigger issue, or meta-issue: compatibility. In addition to everything that has already been said, a major issue that I haven't seen mentioned is the fact that openssl has always been painstakingly backwards compatible at an API level. Many years ago, the use of OPENSSL_NO_DEPRECATED started cropping up (I don't recall if I started that or joined in), but all of those symbols are still there. In other words, we introduced the mechanism that *would* allow us to phase things out from one major release to the next but never actually pulled the trigger. (If you build with OPENSSL_NO_DEPRECATED, some legacy things disappear, and the idea is that in a major release all the "DEPRECATED" stuff could be amputated from the source. Rinse and repeat.) Again, if blame is to be had then I'll take a double. It may be that rounding up a list of platforms seems to be the easiest problem to attack and perhaps it inspires more motivation. It can't be bad exercise in and of itself. But I suspect that all it will do is clear away some modestly-bounded level of cruft, it is unlikely to repair structurally-important problems without harder discussions being had. (Coding assumptions like inlines, portability philosophy such as "modules"-vs-"arch", build system, backward compatibility, ...) On Tue, Jun 3, 2014 at 12:10 PM, Salz, Rich <rs...@akamai.com> wrote: > > especially Stephen Henson, who has kept it together in much the same way > as Keith Richards did the Stones. > > With no disrespect intended to either man, I have to say that this is an > analogy that never would have occurred to me in a million years. > > /r$ > > -- > Principal Security Engineer > Akamai Technologies, Cambridge, MA > IM: rs...@jabber.me; Twitter: RichSalz > >
