At 02:50 PM 11/1/2002, Greg Stein wrote: >On Fri, Nov 01, 2002 at 06:07:53PM -0000, [EMAIL PROTECTED] wrote: >>... >> +++ BaseAddr.ref 1 Nov 2002 18:07:52 -0000 1.22 >> @@ -60,3 +60,4 @@ >> mod_authz_groupfile 0x6FB10000 0x00010000 >> mod_authz_host 0x6FB00000 0x00010000 >> mod_authz_user 0x6FAF0000 0x00010000 >> +mod_logio 0x6FAE0000 0x00010000 > >For efficiency purposes, those numbers should be as close together as >possible. There is some cost to the gaps between a module and the next one >(and/or the overall mapped space). If in the future, a module grows and >causes an overlap, then it merely causes a relocation at load time. So there >isn't a worry about that.
Yes, there is. Data points that for whatever reason are not declared correctly with AP_DECLARE_DATA cannot be relocated, thus they cause a segv when the module relocates. There is another option, which is to rebase all DLLs after the server is configured, based on the modules actually loaded. I'll investigate that as an option. >I don't recall how to find the size of the module; only that the gaps are to >be avoided. You could also set yourself a periodic six month reminder to >reexamine the sizes. Of course. Within a given release, we want to keep them static. When we go to release 2.2 (and folks can no longer load something like logio built on 2.0.44-dev into a 2.0.43 server) then we rebase them all, accounting for the big movement in the new authz schema. And yes - I'll look at the core modules we load 'by default' and regroup them together. Bill
