cvs commit: apache-1.3 ABOUT_APACHE
brian 98/04/10 12:43:12 Modified:.ABOUT_APACHE Log: In Roy's "swab the decks" message he unilaterally and without consultation moved several names from active to emeritae. Revision ChangesPath 1.11 +3 -3 apache-1.3/ABOUT_APACHE Index: ABOUT_APACHE === RCS file: /export/home/cvs/apache-1.3/ABOUT_APACHE,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- ABOUT_APACHE 1998/04/09 00:42:54 1.10 +++ ABOUT_APACHE 1998/04/10 19:43:11 1.11 @@ -71,6 +71,7 @@ Brian Behlendorf Organic Online, California Ken Coar MeepZor Consulting, New England, USA + Mark J. CoxC2Net Europe, UK Ralf S. EngelschallMunich, Germany. Dean GaudetTransmeta Corporation, California Rob HartillInternet Movie DB, UK @@ -79,21 +80,20 @@ Martin Kraemer Munich, Germany Ben Laurie Freelance Consultant, UK Doug MacEachernTOG Research Institute, Massachusetts + Aram W. Mirzadeh Qosina Corporation, New York Sameer Parekh C2Net, California Paul SuttonC2Net Europe, UK Marc SlemkoCanada Randy Terbush Zyzzyva ISP, Nebraska Dirk-Willem van Gulik Freelance Consultant, Italy + Andrew Wilson Freelance Consultant, UK Apache Emeritae (old group members now off doing other things) - Mark J. CoxC2Net Europe, UK Roy T. FieldingUC Irvine, California - Aram W. Mirzadeh Qosina Corporation, New York Chuck Murcko The Topsail Group, Pennsylvania David Robinson Cambridge University, UK Robert S. Thau MIT, Massachusetts - Andrew Wilson Freelance Consultant, UK Other major contributors
cvs commit: apache-1.3 STATUS
brian 98/04/10 05:31:44 Modified:.STATUS Log: Consensus reached. Comments on the vote will be kept in the CVS logs of course. Revision ChangesPath 1.289 +5 -95 apache-1.3/STATUS Index: STATUS === RCS file: /export/home/cvs/apache-1.3/STATUS,v retrieving revision 1.288 retrieving revision 1.289 diff -u -r1.288 -r1.289 --- STATUS1998/04/10 10:41:13 1.288 +++ STATUS1998/04/10 12:31:43 1.289 @@ -190,106 +190,16 @@ Closed issues: -Open issues: - -* Cleanup the symbol space now in the source for - 1.3b6 and thus for the 1.3.x release branch via the - apache-1.3/src/test/rename/rename.cf file as the configuration for the - renaming. The used prefix or prefixes are configureable in the file. - +1: -0: Ralf, Marc - - Notes: - - Marc: this is the wrong time for such a big change - -* What prefixes to use for the renaming: +* To avoid symbol clashes with third-party code compiled into the server, + we shall apply the prefix "ap_" to the following classes of functions: - Apache provided general functions (e.g., ap_cpystrn) - ap_xxx:+1: Ken, Brian, Ralf, Paul, Randy - - - Public API functions (e.g., palloc, bgets) -ap_xxx:+1: Ralf, Randy, Martin, Brian, Paul - +- Public API functions (e.g., palloc, bgets) - Private functions which we can't make static (because of cross-object usage) but should be (e.g., new_connection) - ap_xxx:+1: Randy, Brian, Paul, Ralf - -Notes: - - Ken: Veto rescinded. -- Ralf: My opinion for my decisions are the following ones: - 1. The short ap_ prefix is a good idea because its - a handy prefix while still Apache specific, so I - would use it for those symbols we deal most: API - symbols. - 2. There is a distinction needed between symbols - we want explicitly export (API) and those we are - forced to export (cross-object references). - Hence a the apx_ prefix. It's different from ap_ - but as short as it can while still providing the - needed information: "ap" for Apache and "x" for - internal cross-object symbol. - 3. When you are look at the code you notice that - we use _module for the names of the - module's dispatch structure. First, it always - was confusing in the past that a module named - mod_abc_def usually had a def_abc_module symbol - (e.g. mod_auth variants). Second the - src/Configure stuff has great guessing problems - due to this difference. Third, mod_so has - resolving problems. Fourth, the user who used - the "LoadModule" directive has the most - problems, because he had to write down the - correct symbol name. Fifth, the names - _module are too generic that we can keep - them while we rename all others. They need also - a renaming to be Apache specific. So, to make - them Apache specific, solve the confusion _AND_ - mark them special because of shared object - loading, I propose apm_ as the prefix, i.e. - name1_module bekomes apm_name1. That's short, - Apache specific and indicates (the "m") that - this is a module's bootstrap symbol. This - simplifies mod_so's LoadModule, src/Configure, - APACI's fnm.sh, etc. and makes less confusion to - the user while still providing the private - symbolspace. - -- Randy: I agree with Dean 100%. The work created to - keep this straight far outweighs any gain this - could give. - -- Ralf: I agree with Jim that although the short ap_ - prefix is good for API functions, it shouldn't be - used for all functions. That's too less. Some - distinction is really needed. At least between - really exported symbols (API) and symbols which are - just forced to be exported due to the way the - linker works (internal cross-object references) - -- Roy: A prefix should only be significant in the sense that - it allows us to avoid symbol conflicts. Within our own - symbol set, we always want to use the same prefix becaus
cvs commit: apache-devsite API-dict.html
coar98/04/10 05:17:41 Modified:.API-dict.html Log: Toying with an alternate format, and adding a little real documentation at the same time. Revision ChangesPath 1.5 +40 -7 apache-devsite/API-dict.html Index: API-dict.html === RCS file: /export/home/cvs/apache-devsite/API-dict.html,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- API-dict.html 1998/04/09 01:01:06 1.4 +++ API-dict.html 1998/04/10 12:17:40 1.5 @@ -1377,15 +1377,48 @@ definition/description + - make_sub_pool - - - -definition/description - - + make_sub_pool + +pool + *make_sub_pool(pool *p) + + + + This function creates a new pool area + for memory allocation. The + new area is considered to be a "child" of the pool + passed to the routine; this permits a hierarchy of related storage + areas. When a pool is destroyed (see + destroy_pool), + any sub-pools it may have are also destroyed recursively. + + + An example of when this hierarchy concept is useful can be found in the + http://www.apache.org/docs/mod/mod_autoindex.html"; + >automatic directory listing module. Since the module can't + tell in advance how many files it will have to list, nor how long the + names will be, nor what other functions might need to allocate memory + to process the request, it creates a sub-pool of the one associated + with the request, does the per-filename processing in + it, and clears it for each new file. + + + If the pointer passed to make_sub_pool is NULL, + a new top-level (i.e., parentless) pool is created. This + is generally not recommended, however, since the only record of a + pool's existence is the pointer returned - a simple logic error can + result in pools being created and lost, along with any allocations + made in them. Most pools are created to deal with per-request + processing, and hence should be sub-pools of the request's pool + (r->pool) to ensure that + they are properly cleaned up on request completion. + + + + make_table
cvs commit: apache-1.3 STATUS
rse 98/04/10 03:41:14 Modified:.STATUS Log: Munich, Germany: sunny wheater... Revision ChangesPath 1.288 +4 -18 apache-1.3/STATUS Index: STATUS === RCS file: /export/home/cvs/apache-1.3/STATUS,v retrieving revision 1.287 retrieving revision 1.288 diff -u -r1.287 -r1.288 --- STATUS1998/04/10 10:34:30 1.287 +++ STATUS1998/04/10 10:41:13 1.288 @@ -2,7 +2,7 @@ Release: -1.3b6: in development +1.3b6: in development; release proposed for Friday, April 17 1.3b5: Tagged APACHE_1_3b5 and released 2.0 : In pre-alpha development, see apache-2.0 repository @@ -149,9 +149,12 @@ * Ralf's add of the query (-q) option to apxs * Ralf's initial doc and Configuration.tmpl entry for mod_mmap_static * OS/2 tweak to deal with multiple .exe targets. [Brian Havard] +* Roy's reduce of logging level of "normal" warning messages +* Alexei's change Win32 IS_MODULE to SHARED_MODULE to match Unix way * Fixed ordering of argument checks for RewriteBase directive, PR#2045 * Ralf's cleanup of subdir movement to again allow correct breaks on error * Ralf's consistent add of "distclean" targets for the src/-Makefiles +* Build the libraries before building the rest of the tools * Ralf's and Martin's DSO support for all SVR4-derivate Unix platforms Available Patches: @@ -164,23 +167,6 @@ runs with DNS lookups turned off. In progress: - -* Ralf's and Martin's enhancement to the DSO support in Apache to be - able to support DSO under mostly all SVR4 variants, too. This would - be a major milestone for Apache's DSO support. It is done by - providing a Configuration.tmpl Rule which builds Apache into its own - libhttpd.so while the httpd program is just a stub. This implicitly - makes DSO working under SVR4 because under this platform there is no - generally available compiler switch to force the linker to export - global symbols (to make them available to the DSO modules). But when - Apache's core itself is in a shared object these symbols _are_ - available. BINGO! A nice side effect is that the usage of a - libhttpd.so can be nice under other platforms, too. Oh, BTW: This is - the trick Perl 5 already does to support DSO under SVR4, i.e. the - idea is just stolen from Perl 5 because this trick is the only - portable way to provide DSO support for program extensions under - SVR4 ;-) - Patch from Ralf is coming in the next days! * Ken's IndexFormat enhancement to mod_autoindex to allow CustomLog-like tailoring of directory listing formats
cvs commit: apache-1.3/src/support httpd.8
rse 98/04/10 03:34:37 Modified:.STATUS Makefile.tmpl configure src CHANGES Configuration.tmpl Configure Makefile.tmpl src/main http_main.c src/support httpd.8 Log: DSO support for SVR4-based Unix platforms = What it provides: - This patch is another milestone in the DSO support for Apache 1.3. It adds Dynamic Shared Object (DSO) support for mostly all SVR4-based Unix platforms (We cannot test all of them of course, but Martin has at least tested it under SINIX-SVR4). Why is this patch a little bit larger then one would expect? Mostly because this support goes hand in hand by providing a special variant of the Apache core program. Read on if you are interested. Background: --- Usually the DSO mechanism was designed to be used for loading library code dynamically into the address space of a running program. Here the library code is a stand-alone program which has no knowledge of the program it is loaded into. Technically speaking this means that no symbols of the loading program are references in the DSO. The resolving is done only the other way: Symbols of the library are resolved for the program (either automatically by ld.so when one uses DSO-based libraries or manually via dlopen()/dlsym() when using DSO-based program extensions. Now when you use the latter situation the DSO usually contains a program extension. This extension usually uses symbols from the program it extends: from the API. Same here for Apache: The core provides API symbols and the extensions are Apache modules which use those symbols. Now comes the problem: when you load a DSO via dlopen() the loader has to resolve the symbols in this DSO. Symbols from other DSO-based libraries can be resolved the same way ld.so does. No problem. But to be able to resolve the API symbols the loader must be able to access them. Technically speaking one would say the API symbols have to be "exported". This is not the same as just being a "global" symbol, although a lot of platforms treat this equally. Actually it is this way: When the linker creates an executable program it does not treats global symbols as exported symbols. But because this is needed for extending the program via DSO, modern linkers usually either provide a flag (-rdynamic under Linux, etc.) or are smart enough to do the exportation automatically (Solaris, FreeBSD, etc.) But as life goes, there are linkers out there who neither provide a flag to force exportation nor are smart enough to do it automatically. FOR INSTANCE THE LINKER UNDER SVR4! That's the problem this patch has to solve. Solution: - We have to make sure the global symbols from the Apache core program are forced to be exported by the linker. The obvious way is this: Create a dummy.so with dummy references for _ALL_ global symbols and link httpd against this DSO. This works but has some drawbacks: You have to make sure the dummy.c source is always in sync with the list of global symbols (ARGL!) and you have to make sure the Unix loader can find "dummy.so" when starting httpd (H). So Martin and I've searched for a better solution. And because I'm a Perl hacker I immediately tried to figure out why Perl is able to use the DSO mechanism without problems under SVR4 while Apache has such problems. The answer: Perl 5 uses a nifty trick. As we already know when program code stays in a DSO the global symbols have to be exportable. So, when we put the complete Apache core (the stuff httpd is usually build from) into a DSO we are finished. Because this is both portable and causes no sideeffects like having to sync a dummy.c source, etc. While the theory is simple, the correct solution was not such simple. Martin and I needed some iterations to provide this patch because we wanted to make it perfect and clean. That's why it's a little bit longer The Patch: -- The patch does the following: 1. It introduces a new Rule: SHARED_CORE 2. It makes the main() function from http_main.c configurable and sets it to ap_main if SHARED_CORE is active. 3. It adds two additional stand-alone main() functions to http_main.c which are triggered by SHARED_CORE_BOOTSTRAP and SHARED_CORE_TIESTATIC. 4. It splits the TARGET in Makefile.tmpl into subtargets. One for the standard way of creating just httpd from the .a files. And one for creating the alternative tuple: httpd/libhttpd.ep/libhttpd.so. The first one is SHARED_CORE_BOOTSTRAP+http_main.c, the second one is SHARED_CORE_TIESTATIC+httpd_main.c and the third one are the .a files which usually form the httpd. 5. The DSO section in Configure was extended to force SHARED_CORE under those platforms like SVR4 which essentially
cvs commit: apache-1.3/src Configuration.tmpl
marc98/04/09 20:34:22 Modified:src Configuration.tmpl Log: Be more explicit about when IRIXNIS=yes is required. On recent systems, libsun is empty and on some it has been rumored to cause problems if you link against it. Inspired by PR: 2050 Revision ChangesPath 1.97 +5 -3 apache-1.3/src/Configuration.tmpl Index: Configuration.tmpl === RCS file: /export/home/cvs/apache-1.3/src/Configuration.tmpl,v retrieving revision 1.96 retrieving revision 1.97 diff -u -r1.96 -r1.97 --- Configuration.tmpl1998/04/09 08:20:19 1.96 +++ Configuration.tmpl1998/04/10 03:34:22 1.97 @@ -63,7 +63,7 @@ # # The Configure script currently has only limited built-in # knowledge on how to compile shared objects because this is -# heavily platform-dependend. The current state is this: +# heavily platform-dependent. The current state is this: # # Out-of-the-box supported platforms: # Linux, FreeBSD, Solaris, SunOS, IRIX, OSF1, UnixWare @@ -109,8 +109,10 @@ # # IRIXNIS: # Only takes effect if Configure determines that you are running -# SGI IRIX. If you are, and you are using NIS, you should set this -# to 'yes' +# SGI IRIX. If you are using a (ancient) 4.x version of IRIX, you +# need this if you are using NIS and Apache needs access to it for +# things like mod_userdir. This is not required on 5.x and later +# and you should not enable it on such systems. # # IRIXN32: # If you are running a version of IRIX and Configure detects
