Of course supporting a platform is incurring some costs,
...that can be "shared" with the community:
this is one of its purpose.
I would like to point out that for some platform, devteam could propose
a "limited" support/usability "statement" :
Typically, for WCE on which I am regularly working :
The devteam, after integrating some patch, JUST CHECKING that it
compiles, seems logical, and has NO SIDE EFFECT on other platforms,
could state, " COMPILE, (known to) RUN for this and this scenario (to
be defined) and/or on this and this devices/configs (as indicated by
patch submitter),
BUT IS NOT GUARANTEED TO PASS SUCCESSFULLY the OFFICIAL OPENSSL TEST-SUITE".
This is very common : you could offer wide "compatibility" but LIMIT
your SUPPORT (by devteam) to some very few widely used platforms,
BUT letting a way for the community to continue to bring support for
some "low interest" platforms.
Forking is never a good idea : I have many times taken snapshots of
official openssl to resolve some wce compilation bugs, and of course I
do NOT want to re-invent the openssl wheel, and re-importing many times
my wce fixes in openssl snapshots was really a pain.
In the WCE particular case, I do my best to keep a full compatibility
between my code and the Desktop W32 main code, avoiding as much as
possible new #ifdef.
For example, on the 1.1.x snapshot of the 20140624 I am working on,
there is a very little amount of fixes for WCE : and most of them are
just fully compatible with W32 main stream.
For platform support in general :
I hope that there will be a specific porting guide, relying on isolating
platform specific code in specific source files.
For example, it is quite easy to get some win32 posix services
implementation, that almost completely avoid the use of #ifdef _WIN32
inside the openssl code :
just limiting #ifdef to some #include statements, that can be even
isolated in "big" pool include files.
For posix thread, you could use : http://www.sourceware.org/pthreads-win32/
For a general discussion on posix in win32, see also this M$ doc online
: http://msdn.microsoft.com/fr-fr/library/y23kc048.aspx
"Porting from UNIX to Win32"
Well these are just examples.
This is how I port stunnel to WCE these days : trying to limit #ifdef in
the code, and giving equivalent WCE services to w32 original code...
WCEcompat is also a very good example of porting without having to put
#ifdef everywhere...
Then, that way, it is easier for the devteam to be TOLERANT to some
ports, while at the same time legitimately claiming "NOT GUARANTED on
that platform":
because porting would be just a matter of replacing some standard module
by a specific-port one, something that would just require some Makefile
adaptation (already done for WCE...).
Yours sincerely
Pierre
Le 01/07/2014 16:34, Salz, Rich a écrit :
Hope you are right...but not sure..
Neither are we. That is why the current roadmap says that we're working on it.
It's important to realize that supporting a platform incurs a cost, and we need
to have some way of making the appropriate trade-offs. Clearly, we don't want
to end up where our libre colleagues are starting from, but the previous
approach that we'll take any platform or toolchain patches has contributed to
complexity and poor code quality.
/r$
--
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: rs...@jabber.me; Twitter: RichSalz
:��I"Ϯ��r�m���� (���Z+�7�zZ)���1���x ��h���W^��^��%��
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
