On 2010-04-12 11:22, Tiago Vignatti wrote:
Once upon a time, back in 2007, Carl Worth was trying to boost render
(4c6abe1c). He prefered to use a "strong hash" to compare glyphs (19b3b1fd)
and used openssl library for this. Further, for the same purpose, people
started to set other SHA1 implementations in autoconf. And a lot of
alternatives appeared - six, to be precise. In the mean time, John Tapsell
commit a builtin implementation of SHA1. In the same day, Keith Packard
reverted, stating "X.org should not be providing a custom SHA1
implementation." (a39377cb). Now, users ended up with Xorg setting the default
as the openssl's one (libcrypto), which takes 88 kB of xserver's private RSS.
Besides that, we have a ridiculous "configure dot [...] ac stanza to work
out which lib to use is almost as long as sha1.c was", to quote daniels.
My simple argument against Keith's decision is simple: we can save 316 kB of
RSS in a standalone Xorg call. Therefore, I'm in favor to keep our own very
simple and shiny SHA1 implementation.
Nack.
Those platforms that use their own system libraries (libc, libmd,
CommonCrypto) probably don't want to use static code, especially if
their versions are optimized. As for Linux, the major distros don't
seem to ship either libmd or libsha1 (and libmd doesn't use libtool so
it's not very portable for e.g. Cygwin OOTB), so they will end up using
libgcrypt or openssl.
The libsha1 detection should probably be moved up to before libgcrypt,
but otherwise I think the current situation makes sense, that we go from
builtin implementations, to smallest/fastest to largest.
Yaakov
Cygwin/X
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
