Review request: br-msk-lua, br-msk-libprofiling

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Tue, 22 Dec 2009 16:34:35 -0800 (PST)

These are ready to merge to the trunk, but I need a reviewer before I can
proceed.

br-msk-libopendkim contains some performance improvements to libopendkim
that I found while experimenting with Daniel's code coverage and profiling
work. The changes cut out a huge number of calls to strlen() and make a
few other minor optimizations. "make check" on the library still passes
all tests. This will be a pretty short review.

br-msk-lua adds policy scripting hooks to the Lua interpreter. You need
to configure using "--with-lua" to enable the new code. There is a man
page called opendkim/opendkim-lua.3 that explains how it all works from
the user's perspective. opendkim/opendkim.conf.5 now describes the three
config file options that reference Lua scripts and how they are used.
opendkim/opendkim-lua.c contains all the interpeter hooks, and a number of
accessor/utility functions have been added to opendkim/opendkim.c; these
are called by the interpreter hooks to access data about a message or make
signing requests. The only thing I still want to do before releasing this
is to write a batch of Lua scripts that replicate all of the
currently-available policy and control functions to demonstrate the
versatility of the feature. The branch also includes a new directory
called "miltertest" that contains a Lua-based utility that knows the
milter protocol, which can thus be used to write unit tests for the filter
itself. See the miltertest/miltertest.8 man page for details. Within a
new directory opendkim/tests I have an example that performs a
simple/simple signing against a running filter (it even starts the filter
and shuts it down).

I'm really keen to merge br-msk-lua before starting down the
road of reworking the data structures around the previously-discussed
scalability feature issues, so that one should take priority if possible.
Doing them in the opposite order will make the merge a great deal more
difficult. Unfortunately there's quite a bit to go over in there.

Thanks, guys!
Received on Wed Dec 23 2009 - 00:34:57 PST