httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: [Patch] IfSymbol directive (bug 29003)
Date Fri, 21 May 2004 14:35:45 GMT
This has always been a thorn in my side :)  I actually proposed about 2 yrs
ago that we change from <IfModule source.c> to <IfModule structname>
since it's easier to identify the structname.  At that time, it appeared to be
challenging, and I had proposed a patch that would capture the structname
in the process of declaring it with STANDARD20_MODULE_STUFF.

But this turns out to be a much more trivial problem to solve.  I'd propose
we collect *both* the source.c from the module structure, as well as the
structname *at the time we loadmodule*!  (This is slightly more complicated
for compiled-in modules.)

I'm -0.5 against another named container <IfSymbol > - we recently kicked
around the issue of proliferating namespaces.  Because most sources for
module names end in .c (or .pl etc) there should be little overlap with the
structure names for modules.

The theory is trivial, it's much easier to say;

LoadModule foo_module modules/mod_foo.so
...
AddModule foo_module

then to figure out that mod_foo.c, foo.c, or foo_setup.c is the module which
declared that STANDARD20_MODULE_STUFF.  So each module will have
two entries in the lookup table, but that doesn't appear to be a huge problem.

The items you detail below are all interesting solutions to forcing the top
sourcefile name to be mod_php.c for example, but they don't get at the
real crux of the problem, which is that users shouldn't have to know source
names, and *already* know the structure name, by virtue of seeing the
LoadModule directive for the module documented, somewhere.

Thoughts?

Bill

At 10:59 PM 5/20/2004, Edward Rudd wrote:
>I've posted 2 patches and listed several solutions to my bug # 29003. 
>This bug is a feature request addressing the common issue where a module
>does not follow the standard naming of module source code names..
>(mod_modulename.c), but instead use something else (sapi_apache2.c).
>
>The first solution is to add an IfSymbol directive to search the symbol
>names of dynamically loaded modules. (via mod_so).
>
>The second is similar and patches IfModule to use an optional function to
>hook into mod_so's internal list of dynamically loaded modules as well.
>
>The third option is to create a STANDARD20_MODULE_STUFF_NAMED macro which
>one can specify the filename to store in the module structure (instead of
>__FILE__).
>
>The last solution I saw was to create a function to register aliases that
>the ap_find_linked_module function will search as well as the module
>structure. (ie.. register mod_php4.c to point to sapi_apache2.c ).
>
>Let me know your thoughts on these ideas.. and any other are welcome.
>I currently have patches attached to the bug for solutions 1 through 3.
>
>Regards,
>Edward Rudd



Mime
View raw message