httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: Quick Question: module structure initialization
Date Mon, 26 Oct 1998 08:45:41 GMT

In article <> you wrote:
> On Sat, 24 Oct 1998, Eric Prud'hommeaux wrote:

>> On Sat, 24 Oct 1998, Ralf S. Engelschall wrote:
>> > In other words: Is it safe when I add (inside the mod_ssl patch) two more hook
>> > pointers to the "module" structure definition in http_config.h but the module
>> > sources contain no explicit additional NULLs in their initialization of the
>> > "module" structure?
>> > 
>> > I hope this is the case because else it would be not possible to extend the
>> > set of hooks without requireing third party modules to change their structure,
>> > too. But NULLs for the additional hooks are needed or the stuff would
>> > segfault...
>> Could this be handled in the future (2.0) by having a macro that went into
>> the end of the module declaration?

> While I don't really know that this is a huge issue (since they are NULL
> if they aren't there), it does make it look a little ugly with various
> handlers tacked on the end.

> What you suggest could be one way to deal with it, perhaps with a few
> modifications.  But the thing that would have to be decided first is if we
> even want to keep up with the (exposed) module structure idea; in a lot of
> ways it would be cleaner to just make modules register their phases with
> explicit function calls.  Internally it could be implemented the same, but
> the struct isn't visable any longer then.

Yeah, that's exactly what we should do. The xxxx_module symbol should be no
longer the address of a static structure. Instead it should be the address of
a bootstrapping function which is called after the module is loaded (DSO) or
at least linked into the kernel list of modules. Then this function should
call register functions to link itself (its functions) into the various Apache
                                       Ralf S. Engelschall

View raw message