httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: Universal setting for APR_HOOK_PROBES_ENABLED
Date Sun, 08 May 2011 11:58:06 GMT
On Sat, May 7, 2011 at 7:33 PM, Jim Jagielski <> wrote:
> Here's my idea:
>  o create ap_hooks.h which moves the AP_IMPLEMENT_HOOKS* from
>   ap_config.h to itself.
>  o Fold in the APR_HOOK_PROBES_ENABLED logic as
>   described below.
>  o change configure to accept --enable-hooks-probes=<path>
>   which points to the location of the ap_hooks_probes.h
>   file.
>  o Adjust all files to include ap_hooks.h instead
>   of apr_hooks.h
> I'll start coding this tomorrow; my hope is to have this
> in for the next beta (as RM, I'm gonna hold off a T&R
> until then) since I think it's something that we want
> to really promote as a cool 2.4 feature.

sounds right in general; one of my prior patches (Oakland or Atlanta?)
had ap_hooks.h or similar

a potential concern is that by doing it that way (really, that's the
only way httpd can help out, whether the include of third-party code
is in ap_hooks.h or elsewhere) the provider of the probe macros is "on
the hook" to handle absolutely every hook, which can a bit tedious to

* having separate macros for every individual hook gives you type
safety and the ability to ignore some or, in general, have different
functionality for different hooks (e.g., connection-based vs.
request-based, ignoring everything else); but that gets out of date
(not a killer)
* having common macros for all hooks breaks because of challenges with
the parameter lists (a couple of hooks have 0 parameters!!!) and type
safety (first parm isn't always a pointer, though you can look at the
name of the hook)
** shall we give optional_fn_retrieve a server_rec & ?  (I suggested
this previously on-list, but only niq responded, and not possitively
** I forget what the other one was

but there's probably practical no way to individually select classes
of hooks (e.g., it would be nice to enable only for connection-based
and request-based) other than invasive preprocessor work within .c

should a distinction be made for core+bundled modules vs. third-party
code?  maybe the define to include the third-party .h file is for
internal CPPFLAGS only, so that it doesn't blow (or get the hook probe
implementer on the hook to handle stuff she's never heard of) when
building third-party modules against a probe-enabled build?

as far as potential bundled exploitation:

* DTrace is one flavor (not kept out of date, horrible build changes
never cleaned up/committed)
* it would be cool to have some teaching/debugging mode available at
configure time which resulted in a lot of crap written to the error
log during hook execution which a script could create a nice display
from, combining error and access log information
** perhaps enabled at runtime via -Dfoo
* another flavor I've played with is just maintaining
r->notes{"ActiveModule"} and r->notes{"RequestFailer"} for access from
mod_whatkilledus or access log, respectively

> On May 6, 2011, at 8:38 PM, Jim Jagielski wrote:
>> APR_HOOK_PROBES_ENABLED is pretty nice, the rub is that, esp
>> in httpd, we have lots of modules which go ahead and include
>> apr_hooks.h on their own, making the setup of "universal"
>> probe hooks difficult.
>> Anyone have ideas on how to make it easier, either in
>> APR directly or in httpd? Maybe making some kind of
>> httpd_hooks.h file that includes some local local_hooks_probes.h
>> file (depending on some config-time setting) assuming
>> APR_HOOK_PROBES_ENABLED is set (ie: --enable-hook-probes
>> sets APR_HOOK_PROBES_ENABLED and httpd_hooks.h is
>> basically:
>>  #include "local_hooks_probes.h"
>>  #endif
>>  #include "apr_hooks.h"
>> and no httpd files include apr_hooks.h directly...
>> That seems a very rough way to do it... :/

Born in Roswell... married an alien...

View raw message