Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (herse.apache.org: domain of jorton@redhat.com designates
 66.187.233.31 as permitted sender)
Date: Wed, 3 Jan 2007 10:30:50 +0000
From: Joe Orton <jorton@redhat.com>
To: dev@apr.apache.org
Cc: Justin Erenkrantz <justin@erenkrantz.com>
Subject: Re: [PATCH] Optimized MD5 implementation from OpenSSL
Message-ID: <20070103103050.GA10268@redhat.com>
Mail-Followup-To: dev@apr.apache.org,
	Justin Erenkrantz <justin@erenkrantz.com>
References: <20070102220102.GB3226@bourbon.ics.uci.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20070102220102.GB3226@bourbon.ics.uci.edu>
User-Agent: Mutt/1.4.2.1i

On Tue, Jan 02, 2007 at 02:01:02PM -0800, Justin Erenkrantz wrote:
> One of the bottlenecks that keeps popping up in Subversion is the speed of
> the MD5 checksums.  OpenSSL has put in some work to have optimized MD5
> implementations and with David's recent work to detect OpenSSL. we can just
> defer to their implementations.  For AMD64/EMT64 CPUs, we can leverage
> their optimized implementation (which goes from ~250MB/sec to ~370MB/sec).
> 
> However, the big annoying thing is that we declared apr_md5_ctx_t in 
> apr_md5.h so it's not an opaque value. Luckily for us though, 
> OpenSSL's MD5 context is smaller than APR's - so an ugly hack works.

This would need to have some severe future-proofing to be safe against 
any change to MD5_CTX in future versions of OpenSSL, e.g. only using it 
for the specific sizeof() that structure as currently defined.  (that 
would cover the cases where MD5_LONG is currently not 32-bit too)

1. is having an ENOTIMPL _set_xlate really an excusable regression?  

2. is it intended that the return values from the OpenSSL MD5_* 
functions are ignored?  (can those functions even use the OpenSSL error 
stack and all the mess that entails?)

3. does this mean that apr_md5_* can only be guaranteed to work after 
apu_ssl_init() has been called?

joe