On Tue, May 10, 2011 at 7:52 AM, Jim Jagielski <j...@jagunet.com> wrote:
>
> On May 9, 2011, at 5:06 PM, Jeff Trawick wrote:
>>
>> This patch disables hook probes for our two hooks which don't have args:
>>
>
>> /* which gen? */
>>
>> ugly but effective
>>
>
> +1 (on both counts ;)
>
>
>>
>> I rehashed that with the latest code and the ugly no-arg-hook patch
>> above. Attached is a .c file implementation and a corresponding
>> ap_hook_probes.h for this sample feature set. The .c file has to be
>> included from some httpd source file to get it linked in. It won't
>> work without the workaround for our two no-arg hooks.
>>
>> What's a cleaner way to add the code to the server, assuming that
>> somebody implementing hook probes needs to add
>>
>> 1) a .h file that gets included by ap_hooks.h
>> 2) a .c file that should be linked in to httpd
>>
>> ?
>>
>> Maybe --enable-hook-probes=/path/to/ap_hook_probes.{c,h}
>>
>> Alternately, the code that needs to get linked in could be implemented
>> with a drop-in modules/myprobes/{config.m4,mod_myprobes.c,etc.} and
>> then --enable the module statically.
>> <hook_probe_impl.c><ap_hook_probes.h>
>
> My thoughts are to hopefully make it as self-contained w/i a
> module as possible... That is, the dev must enable-hook-probes and
> then enable/link-in a module which implements them, so I'm
> more consdering the latter.
How about this:
1. --enable-hook-probes=dtrace:
use this to enable existing dtrace code; we'd remove the existing
dtrace configure option; dtrace hook probes and non-dtrace hook probes
necessarily conflict
the dtrace probe list has to be brought up to date and the user has to
add uncommitted build hacks to make it work; while I can't see
committing the build hacks that Theo had, I wouldn't like to see it
get into worse shape
2. --enable-hook-probes=api:
provide a simple API which allows a module to specify request hook
probe callbacks and/or connection hook probe callbacks; the API is
first-come-first-served, as this special mechanism to probe our
primary extensibility mechanism is not itself extensible in the usual
manner ;)
other hooks (those other than connection-based or request-based)
wouldn't be supported
distinguishing request vs. connection would help a little with type
safety and, for some such modules, allow bypassing one of these
categories if it isn't interesting to the module; I guess a module
which cared only for request hooks could coexist with one which cared
only for connection hooks
I predict ugly preprocessing work for this, unless the hook macros are
forked. On the bright side, it should be trivial to exploit the API
given the reduced set of probed hooks (request and/or connection) and
known context within a given probe (request_rec * or conn_rec *)
3.--enable-hooks-probes=custom: provide your own ap_hook_probes.h, do
what you want
Thoughts?
