httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch>
Subject Re: Per-module / per-dir loglevel configuration
Date Mon, 24 May 2010 12:45:16 GMT
On Sunday 16 May 2010, Stefan Fritsch wrote:
> On Saturday 15 May 2010, William A. Rowe Jr. wrote:
> > On 5/15/2010 8:03 AM, Stefan Fritsch wrote:
> > > Yes, I think that's ok. In any case I would like to hide the
> > > mod_foo.c from the user as far as possible and use the name of
> > > the module struct (minus the trailing _module). The LogLevel
> > > directive in my patch already accepts foo, foo_module, and
> > > mod_foo.c as names for the module.
> > 
> > This is goodness; I'm still concerned about the mechanics of the
> > implementation, as I mentioned in Wicklow.  How to avoid the
> > developer needing to preset a define?
> > 
> > One way, admittedly as awkward as your design but meeting the
> > style guidelines, is something of an executed macro, e.g rather
> > than initially setting #define AP_MODULE_VAR authn_dbm_module,
> > it becomes something like AP_MODULE_NAME(authn_dbm_module).  If
> > we decide next time around it's a static, so be it.  If it is
> > the address of the module struct, great.
> What about making it a requirement to use a macro for the module
> struct definition? Something like
> 	        ...
> 	        }
> would then expand to
> 	extern module AP_MODULE_DECLARE_DATA foo_module;
> 	static int * const aplog_moduleindex = &foo_module->module_index;
> 	module AP_MODULE_DECLARE_DATA foo_module = {
> 		...
> 		}
> http_log.h would then contain:
> 	extern static int * const aplog_moduleindex;
> 	#define APLOG_MODULE_INDEX  *aplog_module_index
> Would compilers be able to optimize this variable away? In
> multi-file modules, one would use an additional macro
> which would expand to
> 	extern module AP_MODULE_DECLARE_DATA foo_module;
> 	static int * const ap_log_moduleindex = &foo_module-
> For 2.2.x it would be easy to define compatibility macros to make a
> module source compatible with both 2.2 and 2.4.
> > I still don't care for the approach, except perhaps for the
> > author af a multi source program.  Something will need to
> > associate foo_util.c to foo_module with the base source of
> > mod_foo.c.  But for single source mods, it's still too invasive.
> > 
> > I'm interested in how this puzzle can be generally solved with
> > __FILE__, with the module structure address, and at the load
> > module/register hooks phase.
> > 
> > We agree that mod_foo.c or foo_util.c should be hidden from the
> > user, but is there a way to associate the string address of
> > __FILE__ (as a constant, can we trust today that all compilers
> > will optimize this within a single source .c file?) at the module
> > registration phase?  With that list handy, -we- can go to the
> > trouble of mapping foo_module into an entry for mod_foo.c (and
> > foo_util.c, if necessary).
> I agree that this would be nice, but I haven't found a way so far.
> BTW, I wouldn't want to rely on the fact that the string address of
> __FILE__ is a single constant per file. It would be really annoying
> if httpd behaved differently with optimization turned off.

After thinking some more about it, I don't think it is possible in a 
way that is suitable for logging. Converting the __FILE__ string 
address into something that is suitable to determine the current log-
level (i.e. an int or a pointer to an int) will always require some 
relatively expensive operation like a hash or table look-up. And we 
don't want to have to do that in order to determine if we need to log 
or not.

I rather like the solution above with 
AP_DECLARE_MODULE/APLOG_USE_MODULE macros, as outlined above. The only 
disadvantage I see is that it is not possible to give a good error 
message with #error if the macros are missing in a source file. But it 
seems way more elegant than needing a #define AP_MODULE_VAR at the top 
of every file.


View raw message