httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Universal setting for APR_HOOK_PROBES_ENABLED
Date Sun, 08 May 2011 13:43:00 GMT
Agreed... In some ways it would be cool to actually implement
a ap_hook_probe_entry_* (ie: ap_hook_probe_entry_check_config)
(et.al., that is ap_hook_probe_invoke, ...) that actually moves
them into the actual function list itself instead of using
the macros at all.

This would involve, unfortunately, afaict, simply dropping
APR_HOOKs totally for an AP_HOOKs fork (instead of just AP_HOOKS
using APR_HOOKS)... To be honest, as much as I hate just
duplication of code, I kind of like this idea better since
it's easier for how we wish httpd would use hooks...

Comments? Ideas?

On May 8, 2011, at 7:58 AM, Jeff Trawick wrote:

> 
> 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
> do
> 
> * 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
> IIRC)
> ** 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
> files
> 
> 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:
>>> 
>>>  #ifdef APR_HOOK_PROBES_ENABLED
>>>  #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...
> 


Mime
View raw message