httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: Per-module / per-dir loglevel configuration
Date Sat, 15 May 2010 18:55:35 GMT
On 5/15/2010 8:03 AM, Stefan Fritsch wrote:
> On Friday 14 May 2010, Jeff Trawick wrote:
>>>> For selection by module, does the facility need to be more
>>>> granular than simply using the canonical source file name --
>>>> the name of the file that declares the module struct?
>>> I am not sure what you mean. Somehow it must be clear what module
>>> is to be used for logging.
>> I just meant: Is it okay that, for example, the foo module is
>> always known as mod_foo.c as far as logging concerned, whether the
>> current source file is mod_foo.c, foo_cmds.c, foo_proc.c,
>> etc.?  And you wouldn't be able to configure differenting logging
>> for mod_foo.c logging vs. foo_proc.c logging?
>> (It is okay with me, and perhaps that's what you were planning
>> anyway.)
> 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.

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).

View raw message