httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r816029 [17/23] - in /websites/staging/httpd/trunk/content: ./ apreq/ apreq/docs/ apreq/docs/libapreq2/ contributors/ css/ dev/ dev/images/ dev/whiteboard/ docs-project/ docs/ images/ info/ info/css-security/ library/ mod_fcgid/ mod_ftp/ mo...
Date Sun, 06 May 2012 14:18:10 GMT
Added: websites/staging/httpd/trunk/content/dev/whiteboard/page_io
==============================================================================
--- websites/staging/httpd/trunk/content/dev/whiteboard/page_io (added)
+++ websites/staging/httpd/trunk/content/dev/whiteboard/page_io Sun May  6 14:18:02 2012
@@ -0,0 +1,166 @@
+
+From dgaudet@arctic.org Fri Feb 20 00:36:52 1998
+Date: Fri, 20 Feb 1998 00:35:37 -0800 (PST)
+From: Dean Gaudet <dgaudet@arctic.org>
+To: new-httpd@apache.org
+Subject: page-based i/o
+X-Comment: Visit http://www.arctic.org/~dgaudet/legal for information regarding copyright and disclaimer.
+Reply-To: new-httpd@apache.org
+
+Ed asked me for more details on what I mean when I talk about "paged based
+zero copy i/o". 
+
+While writing mod_mmap_static I was thinking about the primitives that the
+core requires of the filesystem.  What exactly is it that ties us into the
+filesystem?  and how would we abstract it?  The metadata (last modified
+time, file length) is actually pretty easy to abstract.  It's also easy to
+define an "index" function so that MultiViews and such can be implemented. 
+And with layered I/O we can hide the actual details of how you access
+these "virtual" files. 
+
+But therein lies an inefficiency.  If we had only bread() for reading
+virtual files, then we would enforce at least one copy of the data. 
+bread() supplies the place that the caller wants to see the data, and so
+the bread() code has to copy it.  But there's very little reason that
+bread() callers have to supply the buffer... bread() itself could supply
+the buffer.  Call this new interface page_read().  It looks something like
+this:
+
+    typedef struct {
+	const void *data;
+	size_t data_len; /* amt of data on page which is valid */
+	... other stuff necessary for managing the page pool ...
+    } a_page_head;
+
+    /* returns NULL if an error or EOF occurs, on EOF errno will be
+     * set to 0
+     */
+    a_page_head *page_read(BUFF *fb);
+
+    /* queues entire page for writing, returns 0 on success, -1 on
+     * error
+     */
+    int page_write(BUFF *fb, a_page_head *);
+
+It's very important that a_page_head structures point to the data page
+rather than be part of the data page.  This way we can build a_page_head
+structures which refer to parts of mmap()d memory.
+
+This stuff is a little more tricky to do, but is a big win for performance.
+With this integrated into our layered I/O it means that we can have
+zero-copy performance while still getting the advantages of layering.
+
+But note I'm glossing over a bunch of details... like the fact that we
+have to decide if a_page_heads are shared data, and hence need reference
+counting (i.e. I said "queues for writing" up there, which means some
+bit of the a_page_head data has to be kept until its actually written).
+Similarly for the page data.
+
+There are other tricks in this area that we can take advantage of --
+like interprocess communication on architectures that do page flipping.
+On these boxes if you write() something that's page-aligned and page-sized
+to a pipe or unix socket, and the other end read()s into a page-aligned
+page-sized buffer then the kernel can get away without copying any data.
+It just marks the two pages as shared copy-on-write, and only when
+they're written to will the copy be made.  So to make this work, your
+writer uses a ring of 2+ page-aligned/sized buffers so that it's not
+writing on something the reader is still reading.
+
+Dean
+
+----
+
+For details on HPUX and avoiding extra data copies, see
+<ftp://ftp.cup.hp.com/dist/networking/briefs/copyavoid.pdf>.
+
+(note that if you get the postscript version instead, you have to 
+manually edit it to remove the front page before any version of 
+ghostscript that I have used will read it)
+
+----
+
+I've been told by an engineer in Sun's TCP/IP group that zero-copy TCP
+in Solaris 2.6 occurs when:
+
+    - you've got the right interface card (OC-12 ATM card I think)
+    - you use write()
+    - your write buffer is 16k aligned and a multiple of 16k in size
+
+We currently get the 16k stuff for free by using mmap().  But sun's
+current code isn't smart enough to deal with our initial writev()
+of the headers and first part of the response.
+
+----
+
+Systems that have a system call to efficiently send the contents of a 
+descriptor across the network.  This is probably the single best way
+to do static content on systems that support it.
+
+HPUX: (10.30 and on)
+
+      ssize_t sendfile(int s, int fd, off_t offset, size_t nbytes,
+              const struct iovec *hdtrl, int flags);
+
+      (allows you to add headers and trailers in the form of iovec
+      structs)  Marc has a man page; ask if you want a copy.  Not included
+      due to copyright issues.  man page also available from 
+      http://docs.hp.com/ (in particular, 
+      http://docs.hp.com:80/dynaweb/hpux11/hpuxen1a/rvl3en1a/@Generic__BookTextView/59894;td=3 )
+
+Windows NT:
+
+	BOOL TransmitFile(     SOCKET hSocket, 
+	    HANDLE hFile, 
+	    DWORD nNumberOfBytesToWrite, 
+	    DWORD nNumberOfBytesPerSend, 
+	    LPOVERLAPPED lpOverlapped, 
+	    LPTRANSMIT_FILE_BUFFERS lpTransmitBuffers, 
+	    DWORD dwFlags 
+	   ); 
+
+	(does it start from the current position in the handle?  I would
+	hope so, or else it is pretty dumb.)
+
+	lpTransmitBuffers allows for headers and trailers.
+
+	Documentation at:
+
+	http://premium.microsoft.com/msdn/library/sdkdoc/wsapiref_3pwy.htm
+	http://premium.microsoft.com/msdn/library/conf/html/sa8ff.htm
+
+	Even less related to page based IO: just context switching:
+	AcceptEx does an accept(), and returns the start of the
+	input data.  see:
+
+	http://premium.microsoft.com/msdn/library/sdkdoc/pdnds/sock2/wsapiref_17jm.htm
+
+	What this means is you require one less syscall to do a
+	typical request, especially if you have a cache of handles
+	so you don't have to do an open or close.  Hmm.  Interesting
+	question: then, if TransmitFile starts from the current
+	position, you need a mutex around the seek and the
+	TransmitFile.  If not, you are just limited (eg. byte
+	ranges) in what you can use it for.
+
+	Also note that TransmitFile can specify TF_REUSE_SOCKET, so that
+	after use the same socket handle can be passed to AcceptEx.  
+	Obviously only good where we don't have a persistent connection
+	to worry about.
+
+----
+
+Note that all this is shot to bloody hell by HTTP-NG's multiplexing.
+If fragment sizes are big enough, it could still be worthwhile to
+do copy avoidence.  It also causes performance issues because of
+its credit system that limits how much you can write in a single
+chunk.
+
+Don't tell me that if HTTP-NG becomes popular we will seen vendors 
+embedding SMUX (or whatever multiplexing is used) in the kernel to
+get around this stuff.  There we go, Apache with a loadable kernel
+module.  
+
+----
+
+Larry McVoy's document for SGI regarding sendfile/TransmitFile:
+ftp://ftp.bitmover.com/pub/splice.ps.gz

Added: websites/staging/httpd/trunk/content/dev/whiteboard/process-model.html
==============================================================================
--- websites/staging/httpd/trunk/content/dev/whiteboard/process-model.html (added)
+++ websites/staging/httpd/trunk/content/dev/whiteboard/process-model.html Sun May  6 14:18:02 2012
@@ -0,0 +1,431 @@
+<html>
+<head>
+<title>Process Model Design</title>
+</head>
+<body bgcolor="#ffffff" text="#000000" link="#0000ff" vlink="#000080" alink="#ff0000">
+
+<h1>Process Model Design</h1>
+
+<hr><br>
+<p>Note:  Dean wrote the initial version of this with input from various other
+folks.  RST has since mailed Dean and convinced Dean that a lot of this is
+way overboard... and some day when Dean has a chance those extra arguments
+will appear here.  But for now, here's a start on this which is way overboard.
+<hr><br>
+
+<p>Start by reading the
+<a href="http://www.cs.wustl.edu/~jxh/research/research.html">JAWS papers</a>.
+They provide a good background for what we need to think about.
+
+<p>Apache's process models are currently implemented by
+<code>http_main.c</code>.  The addition of the WIN32 code has made it almost
+unreadable.  It needs abstraction and cleanup.  Specifically,
+<code>http_main</code> provides the following functionality:
+
+<ul>
+<li>request dispatch
+<li>timers
+<li>mutexes
+<li>shared memory
+<li>process/thread mgmt
+</ul>
+
+Most of the above are not abstracted sufficiently (i.e. timers, mutexes,
+shared memory).  And there are some missing things that will be needed
+for some of the process models.
+
+<p>Note that the beauty of Apache's current design is that outside of
+<code>http_main</code> very little code cares about how requests are
+dispatched.  The module API has also been designed such that essentially
+no synchronization needs to be done between running requests, for
+example there are (almost) no data structures that require mutexes.
+But the latter is not something that we absolutely need to maintain,
+because there are optimizations that set up data structures which require
+some synchronization... and opening up these potentials is one of the
+purposes of this paper.
+
+<h3>Definitions</h3>
+
+<dl>
+<dt>process
+<dd>A process is the "heaviest" unit of kernel scheduling.  Processes
+do not share address spaces or file resources except through explicit
+methods (such as inheriting file handles or share mem segments, or
+mapping the same file in a shared way).  Processes are pre-emptively
+multitasked.
+
+<dt>thread
+<dd>The term thread will refer <b>only to kernel supplied threads</b>.
+A thread is the "lightest" unit of kernel scheduling.  At least one
+thread exists within each process.  If multiple threads can exist
+within each process then they all share the same memory and file
+resources.  Threads are pre-emptively multitasked.
+
+<dt>fiber
+<dd>A fiber is a user-level "thread".  Fibers are <b>co-operatively
+multitasked</b>, with context switching occuring only at I/O points
+or at explicit yield points.  A fiber can be scheduled to run in any
+thread in the same process.  Typically fibers are implemented entirely
+by user-level libraries, under Unix the I/O would be handled by using
+select() multiplexing.  The term is borrowed from WIN32, which actually
+supplies a fiber interface in the API.  Fibers are very similar to
+"co-routines".  SunOS 4.x "light-weight processes" are fibers, but
+SunOS 5.x LWPs are actually threads.
+</dl>
+
+<h3>What process models are interesting?</h3>
+
+<p>The models vary in three dimensions: number of processes, number
+of threads within each process, number of fibers within each thread.
+In all models, a fiber is used to handle each request -- that is, most
+code in the server can treat the fiber as the only unit of execution
+worth worrying about.
+
+<p>I believe the following models are "interesting":
+
+<ul>
+<li>Single process, single thread, single fiber (SSS).  This is
+the current "inetd mode" and "-X" mode.  It should be easy to maintain
+as a special case of other models.
+
+<li>Multiple process, single thread, single fiber (MSS).  This is the
+current Unix model, and needs to be maintained for maximum portability.
+
+<li>Multiple process, single thread, multiple fiber (MSM).  In each
+process a user-level threads package handles context switches according
+to the completion of I/O.  This is typical "select-event threading"
+under Unix.  This is how Zeus and Squid work, and should be portable to
+essentially every Unix, with a performance advantage over MSS.
+In the MSM model there should be enough processes to exploit the available
+parallelism in the hardware.
+
+<li>Single process, multiple thread, single fiber (SMS).  This is probably
+the easiest to implement "multi-threaded" model.  One process has multiple
+kernel threads, each thread runs a single fiber.  This should be
+implementable under WIN32, OS2, and with POSIX threads.
+
+<li>Single process, multiple thread, multiple fiber (SMM).  This is
+probably the highest performing model.  Under WIN32 this can be achieved
+by using completion ports.  In this model the threads are used to
+run fibers whose I/O are ready; and only enough threads to exploit
+parallelism available in the hardware are used.  The JAWS papers show
+how well this model performs under NT.  It appears possible to implement
+this model under POSIX as well using pthreads, and extended signals,
+but the performance benefit is unknown.
+</ul>
+
+<p>Note that any single process model is subject to robustness issues
+depending on whether a single thread is terminated or an entire process
+is terminated when segfaults and such occur.  So the MMS and MMM models
+are also interesting, but shouldn't be much more work than SMS, SMM
+respectively given that we already need to support MSS and MSM.
+
+<h3>How do we implement fibers?</h3>
+
+<p>In order to abstract fibers so that we can implement all of the above
+models easily we need to abstract all I/O.  That is, we cannot allow
+code outside of the process model code itself to make any system calls.
+As mentioned, the majority of the code in the server will only need to
+know that it is running in a fiber, and not worry how that fiber gets
+time on a CPU.  In the multi-fiber models it would be death if one fiber
+was able to block a thread for an indeterminate time due to I/O (fibers
+can be compute intensive and cause problems -- but this is a separate
+issue solved by a yield primitive).  This is why we have to abstract
+I/O -- for example, in the MSM model all I/O will be done using
+non-blocking file descriptors, and the fiber will be suspended until
+a select() mask indicates that the event is ready.
+
+<p>Given the already existing abstractions (BUFF and the rput/rprintf/etc
+calls) this isn't too much different than what we have now.  Some specific
+things that need work:
+
+<ul>
+<li><b>Stack Usage:</b> This is perhaps the worst issue of all.
+Many routines assume they can allocate large amounts of stack space
+as temporary storge.  A fiber library allows systems to be built with
+thousands of fibers (contrast with threads, for which the OS starts to
+chunk after a certain number of threads because the context is still
+too heavy).  Fibers (and kernel threads for that matter) typically have
+a <i>static</i> sized stack.  One solution is to abstract string and
+URL operations a bit more and use pools more liberally.
+
+<li>FILE *, we can't use it.  BUFF is probably the best replacement.
+While things like sfio provide a useable replacement, we've discussed
+them in the past and decided that there are copyright and portability
+issues.
+
+<li>opendir/readdir/closedir.  On systems where it's availble we will
+have to use open()/getdents() to simulate opendir/readdir.  To see
+why consider NFS filesystems.  If a readdir() is performed on an NFS
+filesystem it could block for an indefinate amount of time -- we
+cannot allow that to happen in any multi-fiber model.  So we have
+to use open() and select() it for reading before using getdents().
+If this isn't available then we'll have to live with the blocking
+potential of readdir().  (It is available on BSD 4.4 systems,
+Linux, Solaris, IRIX, i.e. I doubt this is a big problem).
+
+<li>DNS resolver.  This sucks.  It's likely that we can ignore this
+problem for some cases because Solaris provides an asynchronous
+resolver, and so do glibc-2.x systems (i.e. Linux).  For those
+that don't we have the option of doing resolving in an external
+process via a pipe() so that we can select() on it.  Consult
+squid for some example code in this area, squid uses an external
+process in all of its implementations.
+
+<li>chown, chmod, unlink, ...  I'm not aware of any asynchronous
+way to do these, which means trouble on NFS in multi-fiber
+models.  One workaround is to run more threads than otherwise
+would seem necessary.  Another workaround is to maintain a pool
+of threads which only do these otherwise blocking activities.
+Consult squid 1.2 development for some example code in this area.
+
+<li>signals.
+</ul>
+
+<p>We need to specify this abstraction.  It should be as simple as
+saying "use <code>apio_open</code>" instead of "<code>open</code>",
+"<code>apio_read</code>" instead of "<code>read</code>", and so on.
+The <code>apio_*</code> functions have POSIX semantics.  (Note that
+we can't use <code>aio_*</code> because this is the prefix for POSIX
+asynchronous I/O functions.)
+
+<h4>Example: MSS, and MMS</h4>
+
+<p>The MSS and MMS models have the easiest fiber implementation:
+a fiber is the same as a thread.  In both of these models, the entire apio
+abstraction can consist of #define wrappers for the real POSIX
+functions.
+
+<h4>Example: MSM</h4>
+
+<p>In the MSM model we need to build an extensive apio library,
+and a fiber implementation.  This is a well studied problem
+though, "green threads" used by Sun's Java implementation is
+one example.
+
+<p>A fiber's context consists of:  its stack, its current pc (program
+counter), and its signal context (what handlers are registered, blocked
+signals, etc.).  We don't need to worry about what its registers and
+such are because all context switching is done via function calls and
+the C compiler will take care of those details for us.  An easy
+way to implement the pc/stack context is to use setjmp/longjmp.  Where
+available sigaltstack/sigstack provide an interesting method (thanks
+to RST for this one).  setjmp/longjmp actually save more context
+than necessary, but we can provide hand-tuned assembly for specific
+platforms (i.e. i386).
+
+<p>The apio library makes sure that all I/O is done non-blocking.
+When an I/O request is made it is delayed until a particular fd is
+ready for read or write.  The main scheduling loop for fibers
+builds a select() call, and issues it.  Then parses the results
+to figure out which fiber to schedule next.
+
+<h3>How do we initialize all of this?</h3>
+
+<p>The server goes through the following initialization steps:
+
+<dl>
+<dt>read_config
+<dd>The configuration is read, and probably re-read as it currently
+    is.
+<dt>main_process_init
+<dd>This happens before any other processes, threads, or fibers
+    are created.
+<dt>sub_process_init
+<dd>In all models this phase occurs every time a sub-process is
+    created.  In Sxx models this phase will only ever occur once.
+    In Mxx models this will occur many many times.  This phase
+    occurs in the context of the new sub-process; and occurs
+    before any extra threads are created in the new sub-process.
+<dt>thread_init
+<dd>This phase occurs every time a new thread is created.  In
+    xSx models it will only occur once per sub-process.  In xMx
+    models it will occur every time a thread is created.  This
+    phase occurs in the context of the new thread.
+    (Note: we may have special threads for the purpose of implementing
+    the asynchronous apio library, said threads will only ever
+    do I/O and do not go through this initialization phase.  Their
+    existance is abstracted away by the apio library itself.)
+<dt>fiber_init
+<dd>We have two choices for the xxM models.  We can create a fiber for
+    each request, in which case this phase is redundant.  Or we can
+    maintain pools of fibers.  I believe we'll want to maintain pools
+    of fibers.  So in anticipation of that, this phase exists and is
+    called once per new fiber in the context of the new fiber.
+</dl>
+
+<p>Note: There are other API phases that we need to consider in 2.0,
+but I don't think they're related to the process model discussion.
+
+<p>Note: each phase has a pool associated with it.  For example, the
+pool used for sub_process_initialization will be cleaned up when the
+sub-process dies.  In this manner modules can register cleanups
+with the correct scope without us needing to explicitly define
+cleanup phases.
+
+<h3>Shared Memory, Mutexes, Conditional Definitions</h3>
+
+<p>Some code and optimizations require the use of shared memory and
+mutexes.  We already have several methods of doing each in the MSS model,
+they need to be abstracted.  It should be possible to allocate shared
+memory and mutexes in any pool.  However in the MSS and MSM models it's
+imperitive that they occur during main_process_init.  So modules
+written using shared memory or mutexes that expect maximum portability
+will have to allocate during main_process_init.  This is not an absolute
+requirement, modules may only work in certain models, or may only
+have some features in certain models.
+
+<p>To make this possible we will provide compile time macros to determine
+the process model.  That is, even though on some systems we will
+have the option of building multiple process models, we will require the
+model to be a compile time decision, and we will allow modules to be
+dependant on the model they were compiled in.
+
+<p>We define:
+
+<ul>
+<li>APPM_MULTI_PROCESS = 1
+<li>APPM_MULTI_THREAD = 2
+<li>APPM_MULTI_FIBER = 4
+<li>APPM_MODEL = combination of above bits
+</ul>
+
+For example, MSM will have:
+
+<blockquote><pre>
+#define APPM_MODEL (APPM_MULTI_PROCESS | APPM_MULTI_FIBER)
+</pre></blockquote>
+
+And code can conditionally test things:
+
+<blockquote><pre>
+#if APPM_MODEL &amp; APPM_MULTI_PROCESS
+/* do something specific to multi process models */
+#endif
+
+#if APPM_MODEL == (APPM_MULTI_PROCESS|APPM_MULTI_FIBER)
+/* do something specific to MSM */
+#endif
+</pre></blockquote>
+
+<h3>The Main Loop</h3>
+
+<p>Hidden somewhere in the process model is the method by which a
+request is received and then dispatched into a fiber running inside
+some thread inside some process.  There is currently no API to
+tap into this, and because Apache is only an HTTP server it hasn't
+been an issue.  The closest thing to an API to tap into it is the
+<code>STANDALONE_MAIN</code> definition.  But to use that the user
+must supply a complete <code>standalone_main()</code> replacement, and
+use a different <code>child_main</code> (i.e. must supply a complete
+process model replacement).  This won't be feasible after the process
+model has been abstracted because there will be too many models to try
+to re-implement.
+
+<p>Other than the process model itself, standalone_main/child_main
+provide the following services:
+
+<ul>
+<li>open a network socket for listening, accept/dispatch requests
+<li>the scoreboard
+<li>monitor an <code>other_child</code> (the
+    <code>register_other_child</code> API)
+</ul>
+
+<h4>monitoring sockets</h4>
+
+<p>It should be easy to abstract the network functions.  In the Unix
+models it's sufficient to supply a few <code>fd_sets</code> for
+<code>select</code>, a <code>void *</code>, and a callback.  TODO:
+need to figure out the cleanest way to do this so that the WIN32 and
+OS2 models can implement it well.  Oh yeah, consider <code>poll()</code>
+while you're at it, because poll works better on sparse fd_sets.
+
+<h4>The Scoreboard</h4>
+
+<p>The scoreboard is very intimately tied to the process model.
+In theory some models may be able to run without a scoreboard at all.
+For example an all static content site running in MSM or SMM models
+should never need to spawn or destroy any threads/processes.  Such a
+server would spawn enough threads/processes initially to exploit the
+parallelism in the hardware, and no more.  In general there is
+likely to always be a scoreboard, but its use and contents may
+vary widely.
+
+<p>The scoreboard currently provides the following:
+
+<ul>
+<li>status of the server at a glance
+<li>an optimized alarm() implementation
+<li>data for a customized logging module, to log info about how long
+    a request takes for example
+</ul>
+
+<p>I propose that the first function will have to be supplied by a
+module which is process model dependant, and which uses unexported
+interfaces to the scorebard.  The second function is part of
+the process model itself, and is hidden behind the timeout API
+already.
+
+<p>The third function can be provided by an API like this:
+
+<blockquote><pre>
+typedef enum {
+    REQSTAT_MILLISECONDS	/* #msecs request took, unsigned long */
+    /* uhhh what other fields are of use to a module?? */
+} reqstat_t;
+
+/* returns 0, and stores result in *result if successful
+ * returns -1 and sets errno in the event of an error.
+ * possible errno values:  EINVAL -- not supported in this process model
+ */
+extern int get_reqstat(request_rec *r, reqstat_t index, void *result);
+</pre></blockquote>
+
+<h3>More Thoughts</h3>
+
+<p>I think the above is general enough to implement the interesting
+process models, and to implement optimizations that are available only
+in some of the multi-threaded models.  Note that nothing above
+is specific to HTTP, and I believe that we should strive to keep the
+abstraction so that the same libraries can be used to implement other
+types of servers (i.e. FTP, streaming video/audio, corba).
+
+<p>For many systems there will be multiple process model options.
+It's hard to say which one will be "best"... because some modules
+may work out better in different models.  This will complicate binary
+distribution of the server.  The compile time model choice should be
+made in the Configuration file.  If possible we want to avoid code
+duplication, so the os/osname/ directories are probably not where the
+models should be implemented.  We should probably have pm/unix-mss,
+pm/unix-msm, pm/win32-sms, etc.
+
+<p>Ben Hyde adds: "I always end up adding a priority scheme of some sort,
+and I find it is best if the priority is on the transaction and not on
+the thread.  I don't know how many systems I've had to rework that in."
+
+<p>Note that it's possible to implement an MSM model in which fibers
+can migrate from process to process by using a lot of shared memory,
+and file handle passing.  Maybe this is a good thing, maybe not.  I don't
+think anything above makes this impossible... but the MSM notation isn't
+specific enough to distinguish the two different models.
+
+<p>The whole reason to consider process models is for performance, but
+performance has to be balanced with portability.  I'm confident that
+with this design we should be able to implement the highest performing
+models with very little overhead, and not degrade performance on the
+lower models at all.
+
+<p>This design can be fleshed out and implemented somewhat "organically".
+Several people can be working on it at the same time because there are
+many models that need to be implemented.  Hopefully during this process
+we'll be able to hash out the actual API details.  I hope the above
+is enough to get people started.
+
+<h3>Other References</h3>
+
+<p><i>Implementing Lightweight Threads</i>, D. Stein, D. Shah, SunSoft Inc.
+(<a href="http://www.arctic.org/~dgaudet/apache/2.0/impl_threads.ps.gz">postscript</a>).
+
+</body>
+</html>

Added: websites/staging/httpd/trunk/content/dev/whiteboard/process_model
==============================================================================
--- websites/staging/httpd/trunk/content/dev/whiteboard/process_model (added)
+++ websites/staging/httpd/trunk/content/dev/whiteboard/process_model Sun May  6 14:18:02 2012
@@ -0,0 +1,23 @@
+See Dean's full proposal in process-model.html
+
+----
+
+There is a decent discussion of Win NT completion ports at:
+
+http://premium.microsoft.com/msdn/library/techart/html/servrapp.htm
+
+and a so-so discussion of Win32 multithreading performance at: 
+
+http://premium.microsoft.com/msdn/library/techart/html/threadli.htm
+
+The latter can be a bit trivial (eg. IO bounds tasks generally work better
+when concurrently executed in multiple threads, CPU bound tasks work best
+when serialized.  duh.) but has some useful stuff in.
+
+It appears that the best way for static content on NT is to use
+TransmitFile, completion ports, plus a cache of file handles.  Win32
+doesn't support all of that, but that isn't a big deal.
+
+Completion ports appear to be able to map into async IO (ie. aio_* 
+stuff) on Unix fine, however from what I understand some systems don't
+implement AIO for sockets.

Added: websites/staging/httpd/trunk/content/dev/whiteboard/some_reasons_for_layered_io
==============================================================================
--- websites/staging/httpd/trunk/content/dev/whiteboard/some_reasons_for_layered_io (added)
+++ websites/staging/httpd/trunk/content/dev/whiteboard/some_reasons_for_layered_io Sun May  6 14:18:02 2012
@@ -0,0 +1,37 @@
+This file is there so that I do not have to remind myself
+about the reasons for Layered IO, apart from the obvious one.
+
+0. To get away from a 1 to 1 mapping
+
+   i.e. a single URI can cause multiple backend requests, 
+   in arbitrary configurations, such as in paralel, tunnel/piped, 
+   or in some sort of funnel mode. Such multiple backend
+   requests, with fully layered IO can be treated exactly
+   like any URI request; and recursion is born :-)
+
+1. To do on the fly charset conversion
+
+   Be, theoretically, be able to send out your content using
+   latin1, latin2 or any other charset; generated from static
+   _and_ dynamic content in other charsets (typically unicode
+   encoded as UTF7 or UTF8). Such conversion is prompted by
+   things like the user-agent string, a cookie, or other hints
+   about the capabilities of the OS, language preferences and
+   other (in)capabilities of the final receipient. 
+
+2. To be able to do fancy templates
+
+   Have your application/cgi sending out an XML structure of
+   field/value pair-ed contents; which is substituted into a 
+   template by the web server; possibly based on information 
+   accessible/known to the webserver which you do not want to 
+   be known to the backend script. Ideally that template would
+   be just as easy to generate by a backend as well (see 0).
+
+3. On the fly translation
+
+   And other general text and output mungling, such as translating
+   an english page in spanish whilst it goes through your Proxy,
+   or JPEG-ing a GIF generated by mod_perl+gd.
+
+Dw.

Added: websites/staging/httpd/trunk/content/dev/whiteboard/stacked_io
==============================================================================
--- websites/staging/httpd/trunk/content/dev/whiteboard/stacked_io (added)
+++ websites/staging/httpd/trunk/content/dev/whiteboard/stacked_io Sun May  6 14:18:02 2012
@@ -0,0 +1,554 @@
+[djg: comments like this are from dean]
+
+This past summer, Alexei and I wrote a spec for an I/O Filters API... 
+this proposal addresses one part of that -- 'stacked' I/O with buff.c. 
+
+We have a couple of options for stacked I/O: we can either use existing
+code, such as sfio, or we can rewrite buff.c to do it.  We've gone over
+the first possibility at length, though, and there were problems with each
+implemenation which was mentioned (licensing and compatibility,
+specifically); so far as I know, those remain issues. 
+
+Btw -- sfio will be supported w/in this model... it just wouldn't be the
+basis for the model's implementation. 
+
+     -- Ed Korthof        |  Web Server Engineer --
+     -- ed@organic.com    |  Organic Online, Inc --
+     -- (415) 278-5676    |  Fax: (415) 284-6891 --
+
+---------------------------------------------------------------------------
+Stacked I/O With BUFFs
+	Sections:
+
+	1.) Overview
+	2.) The API
+		User-supplied structures
+		API functions
+	3.) Detailed Description
+		The bfilter structure
+		The bbottomfilter structure
+		The BUFF structure
+		Public functions in buff.c
+	4.) Efficiency Considerations
+		Buffering
+		Memory copies
+		Function chaining
+		writev
+	5.) Code in buff.c
+		Default Functions
+		Heuristics for writev
+		Writing
+		Reading
+		Flushing data
+		Closing stacks and filters
+		Flags and Options
+
+*************************************************************************
+		Overview
+
+The intention of this API is to make Apache's BUFF structure modular
+while retaining high efficiency.  Basically, it involves rewriting
+buff.c to provide 'stacked' I/O -- where the data passed through a
+series of 'filters', which may modify it.
+
+There are two parts to this, the core code for BUFF structures, and the
+"filters" used to implement new behavior.  "filter" is used to refer to
+both the sets of 5 functions, as shown in the bfilter structure in the
+next section, and to BUFFs which are created using a specific bfliter.
+These will also be occasionally refered to as "user-supplied", though
+the Apache core will need to use these as well for basic functions.
+
+The user-supplied functions should use only the public BUFF API, rather
+than any internal details or functions.  One thing which may not be
+clear is that in the core BUFF functions, the BUFF pointer passed in
+refers to the BUFF on which the operation will happen.  OTOH, in the
+user-supplied code, the BUFF passed in is the next buffer down the
+chain, not the current one.
+
+*************************************************************************
+		The API
+
+	User-supplied structures
+
+First, the bfilter structure is used in all filters:
+    typedef struct {
+      int (*writev)(BUFF *, void *, struct iovect *, int);
+      int (*read)(BUFF *, void *, char *, int);
+      int (*write)(BUFF *, void *, const char *, int);
+      int (*flush)(BUFF *, void *, const char *, int, bfilter *);
+      int (*transmitfile)(BUFF *, void *, file_info_ptr *);
+      void (*close)(BUFF *, void *);
+    } bfilter;
+
+bfilters are placed into a BUFF structure along with a
+user-supplied void * pointer.
+
+Second, the following structure is for use with a filter which can
+sit at the bottom of the stack:
+
+    typedef struct {
+      void *(*bgetfileinfo)(BUFF *, void *);
+      void (*bpushfileinfo)(BUFF *, void *, void *);
+    } bbottomfilter;
+
+
+	BUFF API functions
+
+The following functions are new BUFF API functions:
+
+For filters:
+
+BUFF * bcreatestack(pool *p, int flags, struct bfilter *,
+                    struct bbottomfilter *, void *);
+BUFF * bpushfilter (BUFF *, struct bfilter *, void *);
+BUFF * bpushbuffer (BUFF *, BUFF *);
+BUFF * bpopfilter(BUFF *);
+BUFF * bpopbuffer(BUFF *);
+void bclosestack(BUFF *);
+
+For BUFFs in general:
+
+int btransmitfile(BUFF *, file_info_ptr *);
+int bsetstackopts(BUFF *, int, const void *);
+int bsetstackflags(BUFF *, int, int);
+
+Note that a new flag is needed for bsetstackflags:
+B_MAXBUFFERING
+
+The current bcreate should become
+
+BUFF * bcreatebuffer (pool *p, int flags, struct bfilter *, void *);
+
+*************************************************************************
+		Detailed Explanation
+
+	bfilter structure
+
+The void * pointer used in all these functions, as well as those in the
+bbottomfilter structure and the filter API functions, is always the same
+pointer w/in an individual BUFF.
+
+The first function in a bfilter structure is 'writev'; this is only
+needed for high efficiency writing, generally at the level of the system
+interface.  In it's absence, multiple writes will be done w/ 'write'.
+Note that defining 'writev' means you must define 'write'.
+
+The second is 'write'; this is the generic writing function, taking a BUFF
+* to which to write, a block of text, and the length of that block of
+text.  The expected return is the number of characters (out of that block
+of text) which were successfully processed (rather than the number of
+characters actually written). 
+
+The third is 'read'; this is the generic reading function, taking a BUFF *
+from which to read data, and a void * buffer in which to put text, and the
+number of characters to put in that buffer.  The expected return is the
+number of characters placed in the buffer.
+
+The fourth is 'flush'; this is intended to force the buffer to spit out
+any data it may have been saving, as well as to clear any data the
+BUFF code was storing.  If the third argument is non-null, then it
+contains more text to be printed; that text need not be null terminated,
+but the fourth argument contains the length of text to be processed.  The
+expected return value should be the number of characters handled out
+from the third argument (0 if there are none), or -1 on error.  Finally,
+the fifth argument is a pointer to the bfilter struct containing this
+function, so that it may use the write or writev functions in it.   Note
+that general buffering is handled by BUFF's internal code, and module
+writers should not store data for performance reasons.
+
+The fifth is 'transmitfile', which takes as its arguments a buffer to
+which to write (if non-null), the void * pointer containing configuration
+(or other) information for this filter, and a system-dependent pointer
+(the file_info_ptr structure will be defined on a per-system basis)
+containing information required to print the 'file' in question.
+This is intended to allow zero-copy TCP in Win32.
+
+The sixth is 'close'; this is what is called when the connection is being
+closed.  The 'close' should not be passed on to the next filter in the
+stack.  Most filters will not need to use this, but if database handles
+or some other object is created, this is the point at which to remove it.
+Note that flush is called automatically before this.
+
+	bbottomfilter Structure
+
+The first function, bgetfileinfo, is designed to allow Apache to get
+information from a BUFF struct regarding the input and output sources.
+This is currently used to get the input file number to select on a
+socket to see if there's data waiting to be read.  The information
+returned is platform specific; the void * pointer passed in holds
+the void * pointer passed to all user-supplied functions.
+
+The second function, bpushfileinfo, is used to push file information
+onto a buffer, so that the buffer can be fully constructed and ready
+to handle data as soon as possible after a client has connected.
+The first void * pointer holds platform specific information (in
+Unix, it would be a pair of file descriptors); the second holds the
+void * pointer passed to all user-supplied functions.
+
+[djg: I don't think I really agree with the distinction here between
+the bottom and the other filters.  Take the select() example, it's
+valid for any layer to define a fd that can be used for select...
+in fact it's the topmost layer that should really get to make this
+definition.  Or maybe I just have your top and bottom flipped.  In
+any event I think this should be part of the filter structure and
+not separate.]
+
+	The BUFF structure
+
+A couple of changes are needed for this structure: remove fd and
+fd_in; add a bfilter structure; add a pointer to a bbottomfilter;
+add three pointers to the next BUFFs: one for the next BUFF in the
+stack, one for the next BUFF which implements write, and one
+for the next BUFF which implements read.
+
+
+	Public functions in buff.c
+
+BUFF * bpushfilter (BUFF *, struct bfilter *, void *);
+
+This function adds the filter functions from bfilter, stacking them on
+top of the BUFF.  It returns the new top BUFF, or NULL on error.
+
+BUFF * bpushbuffer (BUFF *, BUFF *);
+
+This function places the second buffer on the top of the stack that
+the first one is on.  It returns the new top BUFF, or NULL on error.
+
+BUFF * bpopfilter(BUFF *);
+BUFF * bpopbuffer(BUFF *);
+
+Unattaches the top-most filter from the stack, and returns the new
+top-level BUFF, or NULL on error or when there are no BUFFs
+remaining.  The two are synonymous.
+
+void bclosestack(BUFF *);
+
+Closes the I/O stack, removing all the filters in it.
+
+BUFF * bcreatestack(pool *p, int flags, struct bfilter *,
+                    struct bbottomfilter *, void *);
+
+This creates an I/O stack.  It returns NULL on error.
+
+BUFF * bcreatebuffer(pool *p, int flags, struct bfilter *, void *);
+
+This creates a BUFF for later use with bpushbuffer.  The BUFF is
+not set up to be used as an I/O stack, however.  It returns NULL
+on error.
+
+int bsetstackopts(BUFF *, int, const void *);
+int bsetstackflags(BUFF *, int, int);
+
+These functions, respectively, set options on all the BUFFs in a
+stack.  The new flag, B_MAXBUFFERING is used to disable a feature
+described in the next section, whereby only the first and last
+BUFFs will buffer data.
+
+*************************************************************************
+		Efficiency Considerations
+
+	Buffering
+
+All input and output is buffered by the standard buffering code.
+People writing code to use buff.c should not concern themselves with
+buffering for efficiency, and should not buffer except when necessary.
+
+The write function will typically be called with large blocks of text;
+the read function will attempt to place the specified number of bytes
+into the buffer.
+
+Dean noted that there are possible problems w/ multiple buffers;
+further, some applications must not be buffered.  This can be
+partially dealt with by turning off buffering, or by flushing the
+data when appropriate.
+
+However, some potential problems arise anyway.  The simplest example
+involves shrinking transformations; suppose that you have a set
+of filters, A, B, and C, such that A outputs less text than it
+recieves, as does B (say A strips comments, and B gzips the result).
+Then after a write to A which fills the buffer, A writes to B.
+However, A won't write enough to fill B's buffer, so a memory copy
+will be needed.  This continues till B's buffer fills up, then
+B will write to C's buffer -- with the same effect.
+
+[djg: I don't think this is the issue I was really worried about --
+in the case of shrinking transformations you are already doing 
+non-trivial amounts of CPU activity with the data, and there's
+no copying of data that you can eliminate anyway.  I do recognize
+that there are non-CPU intensive filters -- such as DMA-capable
+hardware crypto cards.  I don't think they're hard to support in
+a zero-copy manner though.]
+
+The maximum additional number of bytes which will be copied in this
+scenario is on the order of nk, where n is the total number of bytes,
+and k is the number of filters doing shrinking transformations.
+
+There are several possible solutions to this issue.  The first
+is to turn off buffering in all but the first filter and the
+last filter.  This reduces the number of unnecessary byte copies
+to at most one per byte, however it means that the functions in
+the stack will get called more frequently; but it is the default
+behavior, overridable by setting the B_MAXBUFFERING with
+bsetstackflags.  Most filters won't involve a net shrinking
+transformation, so even this will rarely be an issue; however,
+if the filters do involve a net shrinking transformation, for
+the sake of network-efficiency (sending reasonably sized blocks),
+it may be more efficient anyway.
+
+A second solution is more general use of writev for communication
+between different buffers.  This complicates the programing work,
+however.
+
+
+	Memory copies
+
+Each write function is passed a pointer to constant text; if any changes
+are being made to the text, it must be copied.  However, if no changes
+are made to the text (or to some smaller part of it), then it may be
+sent to the next filter without any additional copying.  This should
+provide the minimal necessary memory copies.
+
+[djg: Unfortunately this makes it hard to support page-flipping and
+async i/o because you don't have any reference counts on the data.
+But I go into a little detail that already in docs/page_io.]
+
+	Function chaining
+
+In order to avoid unnecessary function chaining for reads and writes,
+when a filter is pushed onto the stack, the buff.c code will determine
+which is the next BUFF which contains a read or write function, and
+reads and writes, respectively, will go directly to that BUFF.
+
+	writev
+
+writev is a function for efficient writing to the system; in terms of
+this API, however, it also works for dealing with multiple blocks of
+text without doing unnecessary byte copies.  It is not required.
+
+Currently, the system level writev is used in two contexts: for
+chunking and when a block of text is writen which, combined with
+the text already in the buffer, would make the buffer overflow.
+
+writev would be implemented both by the default bottom level filter
+and by the chunking filter for these operations.  In addition, writev
+may, be used, as noted above, to pass multiple blocks of text w/o
+copying them into a single buffer.  Note that if the next filter does
+not implement writev, however, this will be equivalent to repeated
+calls to write, which may or may not be more efficient.  Up to
+IOV_MAX-2 blocks of text may be passed along in this manner.  Unlike
+the system writev call, the writev in this API should be called only
+once, with a array with iovec's and a count as to the number of
+iovecs in it.
+
+If a bfilter defines writev, writev will be called whether or not
+NO_WRITEV is set; hence, it should deal with that case in a reasonable
+manner.
+
+[djg: We can't guarantee atomicity of writev() when we emulate it.
+Probably not a problem, just an observation.]
+
+*************************************************************************
+		Code in buff.c
+
+	Default Functions
+
+The default actions are generally those currently performed by Apache,
+save that they they'll only attempt to write to a buffer, and they'll
+return an error if there are no more buffers.  That is, you must implement
+read, write, and flush in the bottom-most filter.
+
+Except for close(), the default code will simply pass the function call
+on to the next filter in the stack.  Some samples follow.
+
+	Heuristics for writev
+
+Currently, we call writev for chunking, and when we get a enough so that
+the total overflows the buffer.  Since chunking is going to become a
+filter, the chunking filter will use writev; in addition, bwrite will
+trigger bwritev as shown (note that system specific information should
+be kept at the filter level):
+
+in bwrite:
+
+    if (fb->outcnt > 0 && nbyte + fb->outcnt >= fb->bufsiz) {
+        /* build iovec structs */
+        struct iovec vec[2];
+        vec[0].iov_base = (void *) fb->outbase;
+        vec[0].iov_len = fb->outcnt;
+        fb->outcnt = 0;
+        vec[1].iov_base = (void *)buff;
+        vec[1].iov_length = nbyte;
+        return bwritev (fb, vec, 2);
+    } else if (nbye >= fb->bufsiz) {
+        return write_with_errors(fb,buff,nbyte);
+    }
+
+Note that the code above takes the place of large_write (as well
+as taking code from it).
+
+So, bwritev would look something like this (copying and pasting freely
+from the current source for writev_it_all, which could be replaced):
+
+-----
+int bwritev (BUFF * fb, struct iovec * vec, int nvecs) {
+    if (!fb)
+        return -1; /* the bottom level filter implemented neither write nor
+                    * writev. */
+    if (fb->bfilter.bwritev) {
+        return bf->bfilter.writev(fb->next, vec, nvecs);
+    } else if (fb->bfilter.write) {
+        /* while it's nice an easy to build the vector and crud, it's painful
+         * to deal with partial writes (esp. w/ the vector)
+         */
+        int i = 0,rv;
+        while (i < nvecs) {
+            do {
+                rv = fb->bfilter.write(fb, vec[i].iov_base, vec[i].iov_len);
+            } while (rv == -1 && (errno == EINTR || errno == EAGAIN)
+                     && !(fb->flags & B_EOUT));
+            if (rv == -1) {
+                if (errno != EINTR && errno != EAGAIN) {
+                    doerror (fb, B_WR);
+                }
+                return -1;
+            }
+            fb->bytes_sent += rv;
+            /* recalculate vec to deal with partial writes */
+            while (rv > 0) {
+                if (rv < vec[i].iov_len) {
+                    vec[i].iov_base = (char *)vec[i].iov_base + rv;
+                    vec[i].iov_len -= rv;
+                    rv = 0;
+                    if (vec[i].iov_len == 0) {
+                        ++i;
+                    }
+                } else {
+                    rv -= vec[i].iov_len;
+                    ++i;
+                }
+            }
+            if (fb->flags & B_EOUT)
+                return -1;
+        }
+        /* if we got here, we wrote it all */
+        return 0;
+    } else {
+        return bwritev(fb->next,vec,nvecs);
+    }
+}
+-----
+The default filter's writev function will pretty much like
+writev_it_all.
+
+
+	Writing
+
+The general case for writing data is significantly simpler with this
+model.  Because special cases are not dealt with in the BUFF core,
+a single internal interface to writing data is possible; I'm going
+to assume it's reasonable to standardize on write_with_errors, but
+some other function may be more appropriate.
+
+In the revised bwrite (which I'll ommit for brievity), the following
+must be done:
+	check for error conditions
+	check to see if any buffering is done; if not, send the data
+		directly to the write_with_errors function
+	check to see if we should use writev or write_with_errors
+		as above
+	copy the data to the buffer (we know it fits since we didn't
+		need writev or write_with_errors)
+
+The other work the current bwrite is doing is
+	ifdef'ing around NO_WRITEV
+	numerous decisions regarding whether or not to send chunks
+
+Generally, buff.c has a number of functions whose entire purpose is
+to handle particular special cases wrt chunking, all of which could
+be simplified with a chunking filter.
+
+write_with_errors would not need to change; buff_write would.  Here
+is a new version of it:
+
+-----
+/* the lowest level writing primitive */
+static ap_inline int buff_write(BUFF *fb, const void *buf, int nbyte)
+{
+    if (fb->bfilter.write)
+        return fb->bfilter.write(fb->next_writer,buff,nbyte);
+    else
+        return bwrite(fb->next_writer,buff,nbyte);
+}
+-----
+
+If the btransmitfile function is called on a buffer which doesn't implement
+it, the system will attempt to read data from the file identified
+by the file_info_ptr structure and use other methods to write to it.
+
+	Reading
+
+One of the basic reading functions in Apache 1.3b3 is buff_read;
+here is how it would look within this spec:
+
+-----
+/* the lowest level reading primitive */
+static ap_inline int buff_read(BUFF *fb, void *buf, int nbyte)
+{
+    int rv;
+
+    if (!fb)
+        return -1; /* the bottom level filter is not set up properly */
+
+    if (fb->bfilter.read)
+        return fb->bfilter.read(fb->next_reader,buf,nbyte,fb->bfilter_info);
+    else
+        return bread(fb->next_reader,buff,nbyte);
+}
+-----
+The code currently in buff_read would become part of the default
+filter.
+
+
+	Flushing data
+
+flush will get passed on down the stack automatically, with recursive
+calls to bflush.  The user-supplied flush function will be called then,
+and also before close is called.  The user-supplied flush should not
+call flush on the next buffer.
+
+[djg: Poorly written "expanding" filters can cause some nastiness
+here.  In order to flush a layer you have to write out your current
+buffer, and that may cause the layer below to overflow a buffer and
+flush it.  If the filter is expanding then it may have to add more to
+the buffer before flushing it to the layer below.  It's possible that
+the layer below will end up having to flush twice.  It's a case where
+writev-like capabilities are useful.]
+
+	Closing Stacks and Filters
+
+When a filter is removed from the stack, flush will be called then close
+will be called.  When the entire stack is being closed, this operation
+will be done automatically on each filter within the stack; generally,
+filters should not operate on other filters further down the stack,
+except to pass data along when flush is called.
+
+	Flags and Options
+
+Changes to flags and options using the current functions only affect
+one buffer.  To affect all the buffers on down the chain, use
+bsetstackopts or bsetstackflags.
+
+bgetopt is currently only used to grab a count of the bytes sent;
+it will continue to provide that functionality.  bgetflags is
+used to provide information on whether or not the connection is
+still open; it'll continue to provide that functionality as well.
+
+The core BUFF operations will remain, though some operations which
+are done via flags and options will be done by attaching appropriate
+filters instead (eg. chunking).
+
+[djg: I'd like to consider filesystem metadata as well -- we only need
+a few bits of metadata to do HTTP: file size and last modified.  We
+need an etag generation function, it is specific to the filters in
+use.  You see, I'm envisioning a bottom layer which pulls data out of
+a database rather than reading from a file.]

Added: websites/staging/httpd/trunk/content/doap.rdf
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/doap.rdf
------------------------------------------------------------------------------
    svn:mime-type = application/xml

Added: websites/staging/httpd/trunk/content/docs-project/avail_translations.xml
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/docs-project/avail_translations.xml
------------------------------------------------------------------------------
    svn:mime-type = application/xml

Added: websites/staging/httpd/trunk/content/docs-project/contribute.xml
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/docs-project/contribute.xml
------------------------------------------------------------------------------
    svn:mime-type = application/xml

Added: websites/staging/httpd/trunk/content/docs-project/contributors.xml
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/docs-project/contributors.xml
------------------------------------------------------------------------------
    svn:mime-type = application/xml

Added: websites/staging/httpd/trunk/content/docs-project/docsformat.xml
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/docs-project/docsformat.xml
------------------------------------------------------------------------------
    svn:mime-type = application/xml

Added: websites/staging/httpd/trunk/content/docs-project/index.xml
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/docs-project/index.xml
------------------------------------------------------------------------------
    svn:mime-type = application/xml

Added: websites/staging/httpd/trunk/content/docs-project/mod_template.txt
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/docs-project/mod_template.txt
------------------------------------------------------------------------------
    svn:mime-type = application/xml

Added: websites/staging/httpd/trunk/content/docs-project/svn.xml
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/docs-project/svn.xml
------------------------------------------------------------------------------
    svn:mime-type = application/xml

Added: websites/staging/httpd/trunk/content/docs-project/translations.xml
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/docs-project/translations.xml
------------------------------------------------------------------------------
    svn:mime-type = application/xml

Added: websites/staging/httpd/trunk/content/docs/index.xml
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/docs/index.xml
------------------------------------------------------------------------------
    svn:mime-type = application/xml

Added: websites/staging/httpd/trunk/content/download.cgi
==============================================================================
--- websites/staging/httpd/trunk/content/download.cgi (added)
+++ websites/staging/httpd/trunk/content/download.cgi Sun May  6 14:18:02 2012
@@ -0,0 +1,6 @@
+#!/bin/sh
+# Wrapper script around mirrors.cgi script
+# (we must change to that directory in order for python to pick up the
+#  python includes correctly)
+cd /www/www.apache.org/dyn/mirrors
+/www/www.apache.org/dyn/mirrors/mirrors.cgi $*

Added: websites/staging/httpd/trunk/content/download.xml
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/download.xml
------------------------------------------------------------------------------
    svn:mime-type = application/xml

Added: websites/staging/httpd/trunk/content/favicon.ico
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/favicon.ico
------------------------------------------------------------------------------
    svn:mime-type = image/x-ico

Added: websites/staging/httpd/trunk/content/images/99POYlede.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/99POYlede.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/ACNA2010_120x240_basic.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/ACNA2010_120x240_basic.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/ACNA2010_125x125_basic.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/ACNA2010_125x125_basic.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/ACNA2010_234x60_basic.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/ACNA2010_234x60_basic.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/ACNA2010_468x60_basic.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/ACNA2010_468x60_basic.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/SWTopFame.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/SWTopFame.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/SWTopFame00.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/SWTopFame00.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/SWTopFame98.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/SWTopFame98.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/SWTopFame99.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/SWTopFame99.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/SWshowcase.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/SWshowcase.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/apache_email.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/apache_email.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/apache_feather.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/apache_feather.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/apache_feather_bullet.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/apache_feather_bullet.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/apache_feather_promo.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/apache_feather_promo.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/apache_home.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/apache_home.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/apache_index.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/apache_index.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/apache_logo.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/apache_logo.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/apache_pb.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/apache_pb.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/apache_pb3.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/apache_pb3.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/apache_pb_1.0.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/apache_pb_1.0.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/apache_sub.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/apache_sub.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/asf_logo_wide.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/asf_logo_wide.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/chuck.jpg
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/chuck.jpg
------------------------------------------------------------------------------
    svn:mime-type = image/jpeg

Added: websites/staging/httpd/trunk/content/images/coar.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/coar.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/erik.jpg
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/erik.jpg
------------------------------------------------------------------------------
    svn:mime-type = image/jpeg

Added: websites/staging/httpd/trunk/content/images/graybar.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/graybar.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/httpd_logo_wide.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/httpd_logo_wide.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/httpd_logo_wide.png
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/httpd_logo_wide.png
------------------------------------------------------------------------------
    svn:mime-type = image/png

Added: websites/staging/httpd/trunk/content/images/httpd_logo_wide.psd
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/httpd_logo_wide.psd
------------------------------------------------------------------------------
    svn:mime-type = image/vnd.adobe.photoshop

Added: websites/staging/httpd/trunk/content/images/kess.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/kess.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/noirin.jpg
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/noirin.jpg
------------------------------------------------------------------------------
    svn:mime-type = image/jpeg

Added: websites/staging/httpd/trunk/content/images/orange_ball.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/orange_ball.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/pctony.jpg
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/pctony.jpg
------------------------------------------------------------------------------
    svn:mime-type = image/jpeg

Added: websites/staging/httpd/trunk/content/images/powered_by.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/powered_by.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/rasmus.jpg
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/rasmus.jpg
------------------------------------------------------------------------------
    svn:mime-type = image/jpeg

Added: websites/staging/httpd/trunk/content/images/rbowen.jpg
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/rbowen.jpg
------------------------------------------------------------------------------
    svn:mime-type = image/jpeg

Added: websites/staging/httpd/trunk/content/images/small_feather.gif
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/small_feather.gif
------------------------------------------------------------------------------
    svn:mime-type = image/gif

Added: websites/staging/httpd/trunk/content/images/smiley.xbm
==============================================================================
--- websites/staging/httpd/trunk/content/images/smiley.xbm (added)
+++ websites/staging/httpd/trunk/content/images/smiley.xbm Sun May  6 14:18:02 2012
@@ -0,0 +1,6 @@
+#define smily_width 16
+#define smily_height 16
+static char smily_bits[] = {
+ 0x00,0x00,0xe0,0x07,0x10,0x08,0x08,0x10,0x04,0x20,0x62,0x46,0x62,0x46,0x02,
+ 0x40,0x02,0x40,0x12,0x48,0x22,0x44,0xc4,0x23,0x08,0x10,0x10,0x08,0xe0,0x07,
+ 0x00,0x00};

Added: websites/staging/httpd/trunk/content/images/stein.jpg
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/images/stein.jpg
------------------------------------------------------------------------------
    svn:mime-type = image/jpeg

Added: websites/staging/httpd/trunk/content/index.html
==============================================================================
--- websites/staging/httpd/trunk/content/index.html (added)
+++ websites/staging/httpd/trunk/content/index.html Sun May  6 14:18:02 2012
@@ -0,0 +1,114 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+               "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+    <head>
+        <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
+        <link href="/css/apsite.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
+        <meta name="author" content="Documentation Group" /><meta name="email" content="docs@httpd.apache.org" />
+        <title>Welcome! - The Apache HTTP Server Project</title>
+    </head>
+    <body>
+        
+        <div id="page-header">
+            <p class="menu">&nbsp;</p>
+            <p class="apache">&nbsp;</p>
+            <a href="/">
+            <img alt="" width="800" height="72" src="/images/httpd_logo_wide_new.png" border="0" />
+            </a>
+        </div>
+        
+
+        <!-- LEFT SIDE NAVIGATION -->
+        <div id="apmenu">
+            
+            <div class="codehilite"><pre>        <span class="c"># Essentials</span>
+</pre></div>
+
+
+<ul>
+<li><a href="ABOUT_APACHE.html">About</a></li>
+<li><a href="http://www.apache.org/licenses/">License</a></li>
+<li><a href="http://wiki.apache.org/httpd/FAQ">FAQ</a></li>
+<li><a href="/security_report.html">Secutiry Reports</a></li>
+</ul>
+<h1 id="download">Download!</h1>
+<ul>
+<li><a href="/download.cgi">From a Mirror</a></li>
+</ul>
+<h1 id="documentation">Documentation</h1>
+<ul>
+<li><a href="/docs/2.4/">Version 2.4</a></li>
+<li><a href="/docs/2.2/">Version 2.2</a></li>
+<li><a href="/docs/2.0/">Version 2.0</a></li>
+<li><a href="/docs/trunk/">Trunk (dev)</a></li>
+</ul>
+<h1 id="get-support">Get Support</h1>
+<ul>
+<li><a href="/support.html">Support</a></li>
+</ul>
+<h1 id="get-involved">Get Involved</h1>
+<ul>
+<li><a href="/lists.html">Mailing Lists</a></li>
+<li><a href="/bug_report.html">Bug Reports</a></li>
+<li><a href="/dev/">Developer Info</a></li>
+</ul>
+<h1 id="subprojects">Subprojects</h1>
+<ul>
+<li><a href="/docs-project/">Docs</a></li>
+<li><a href="/test/">Test</a></li>
+<li><a href="/test/flood/">Flood</a></li>
+<li><a href="/apreq/">libapreq</a></li>
+<li><a href="/modules">Modules</a></li>
+<li><a href="/mod_fcgid/">mod_fcgid</a></li>
+<li><a href="/mod_ftp/">mod_ftp</a></li>
+</ul>
+<h1 id="miscellaneous">Miscellaneous</h1>
+<ul>
+<li><a href="/contributors/">Contributors</a></li>
+<li><a href="http://www.apache.org/foundation/thanks.html">Sponsors</a></li>
+<li><a href="http://www.apache.org/foundation/sponsorship.html">Sponsorship</a></li>
+</ul>
+            
+        </div>
+
+
+        <!-- RIGHT SIDE INFORMATION -->
+        <div id="apcontents">
+            
+            <h1 id="the-number-one-http-server-on-the-internet">The Number One HTTP Server On The Internet</h1>
+<p>The Apache HTTP Server Project is an effort to develop and maintain an open-source HTTP server for modern operating systems including UNIX and Windows NT. The goal of this project is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards.</p>
+<p>Apache httpd has been the most popular web server on the Internet since April 1996, and celebrated its 17th birthday as a project this February.</p>
+<p>The Apache HTTP Server ("httpd") is a project of <a href="http://www.apache.org/">The Apache Software Foundation</a> .</p>
+<h1 id="apache-httpd-242-released">Apache httpd 2.4.2 Released</h1>
+<p>The Apache Software Foundation and the Apache HTTP Server Project are pleased to <a href="http://www.apache.org/dist/httpd/Announcement2.4.html">announce</a> the release of version 2.4.2 of the Apache HTTP Server ("Apache"). This version of Apache is our 2nd GA release of the new generation 2.4.x branch of Apache HTTPD and represents fifteen years of innovation by the project, and is recommended over all previous releases. This version of Apache is principally a security and bug fix release.</p>
+<p>This version of httpd is a major release of the 2.4 stable branch, and represents the best available version of Apache HTTP Server. <a href="docs/trunk/new_features_2_4.html">New features</a> include Loadable MPMs, major improvements to OSCP support, mod_lua, Dynamic Reverse Proxy configuration, Improved Authentication/Authorization, FastCGI Proxy, New Expression Parser, and a Small Object Caching API.</p>
+<p><a href="download.cgi#apache24">Download</a> | <a href="docs/trunk/new_features_2_4.html">New Features in httpd 2.4</a> | <a href="http://www.apache.org/dist/httpd/CHANGES_2.4">Complete ChangeLog for 2.4</a> | <a href="http://www.apache.org/dist/httpd/CHANGES_2.4.2">ChangeLog for just 2.4.2</a> </p>
+<h1 id="apache-httpd-2222-released">Apache httpd 2.2.22 Released</h1>
+<p>The Apache HTTP Server Project is proud to <a href="http://www.apache.org/dist/httpd/Announcement2.2.html">announce</a> the release of version 2.2.22 of the Apache HTTP Server ("httpd"). This version is principally a security and bugfix release. There is an offical <a href="http://httpd.apache.org/security/vulnerabilities_22.html">vulnerability list</a> of those issues fixed in this release.</p>
+<p>This version of httpd is a major release of the 2.2 stable branch. <a href="docs/2.2/new_features_2_2.html">New features</a> include Smart Filtering, Improved Caching, AJP Proxy, Proxy Load Balancing, Graceful Shutdown support, Large File Support, the Event MPM, and refactored Authentication/Authorization.</p>
+<p><a href="download.cgi">Download</a> | <a href="docs/2.2/new_features_2_2.html">New Features in httpd 2.2</a> | <a href="http://www.apache.org/dist/httpd/CHANGES_2.2.22">ChangeLog for 2.2.22</a> | <a href="http://www.apache.org/dist/httpd/CHANGES_2.2">Complete ChangeLog for 2.2</a> </p>
+<h1 id="apache-httpd-2064-released">Apache httpd 2.0.64 Released</h1>
+<p>The Apache HTTP Server Project <a href="http://www.apache.org/dist/httpd/Announcement2.0.html">announces</a> the legacy release of version 2.0.64 of the Apache HTTP Server ("httpd").</p>
+<p>This version of httpd is principally a security and bugfix release.</p>
+<p>For further details, see the <a href="http://www.apache.org/dist/httpd/Announcement2.0.html">announcement</a> .</p>
+<p><a href="download.cgi">Download</a> | <a href="docs/2.0/new_features_2_0.html">New Features in httpd 2.0</a> | <a href="http://www.apache.org/dist/httpd/CHANGES_2.0.64">ChangeLog for 2.0.64</a> | <a href="http://www.apache.org/dist/httpd/CHANGES_2.0">Complete ChangeLog for 2.0</a> </p>
+<h1 id="want-to-try-out-the-apache-http-server">Want to try out the Apache HTTP Server?</h1>
+<p>Great! We have updated our <a href="/download.cgi">download page</a> in an effort to better utilize our mirrors. We hope that by making it easier to use our mirrors that we will be able to provide a better download experience.</p>
+<p>Please ensure that you <a href="/download.cgi#verify">verify</a> your downloads using PGP or MD5 signatures</p>
+            
+
+            <!-- FOOTER -->
+            <div id="footer">
+                <p class="apache">
+                    
+                    <div class="codehilite"><pre>                <span class="n">Copyright</span> <span class="o">&amp;</span><span class="n">copy</span><span class="p">;</span> <span class="mi">2012</span> <span class="n">The</span> <span class="n">Apache</span> <span class="n">Software</span> <span class="n">Foundation</span>
+</pre></div>
+
+
+<p>Apache HTTP Server, Apache, and the Apache feather logo are trademarks of The Apache Software Foundation.</p>
+                    
+                </p>
+            </div>
+        </div>
+    </body>
+    </html>

Added: websites/staging/httpd/trunk/content/index.xml
==============================================================================
Binary file - no diff available.

Propchange: websites/staging/httpd/trunk/content/index.xml
------------------------------------------------------------------------------
    svn:mime-type = application/xml

Added: websites/staging/httpd/trunk/content/info/apache_books.html
==============================================================================
--- websites/staging/httpd/trunk/content/info/apache_books.html (added)
+++ websites/staging/httpd/trunk/content/info/apache_books.html Sun May  6 14:18:02 2012
@@ -0,0 +1,31 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+<TITLE>Books written about the Apache HTTP Server</TITLE>
+</HEAD>
+<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+<BODY
+ BGCOLOR="#FFFFFF"
+ TEXT="#000000"
+ LINK="#0000FF"
+ VLINK="#000080"
+ ALINK="#FF0000"
+>
+<DIV ALIGN="CENTER">
+ <IMG
+  SRC="../images/apache_sub.gif"
+  ALT="[APACHE HTTP SERVER BOOKS]"
+ >
+</DIV>
+
+<H1 ALIGN="CENTER">Books written about the Apache HTTP Server</H1>
+<P>Please go to <a href="http://www.apachebookstore.com/">www.apachebookstore.com</a>,
+   and select the <i>HTTP Server</i> section.
+</P>
+<HR>
+<P ALIGN="CENTER">
+<A HREF="/"><IMG SRC="../images/apache_home.gif" ALT="Home"></A>
+</P>
+
+</BODY>
+</HTML>

Added: websites/staging/httpd/trunk/content/info/apache_on_linux.html
==============================================================================
--- websites/staging/httpd/trunk/content/info/apache_on_linux.html (added)
+++ websites/staging/httpd/trunk/content/info/apache_on_linux.html Sun May  6 14:18:02 2012
@@ -0,0 +1,60 @@
+<HTML>
+<HEAD>
+<TITLE>Configuring linux to run Apache 0.8 +</TITLE>
+</HEAD>
+<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
+<BODY
+ BGCOLOR="#FFFFFF"
+ TEXT="#000000"
+ LINK="#0000FF"
+ VLINK="#000080"
+ ALINK="#FF0000"
+>
+<DIV ALIGN="CENTER">
+<IMG
+ SRC="../images/apache_sub.gif"
+ ALT="[APACHE DOCUMENTATION]"
+>
+</DIV>
+
+<H3>Warning: this document has been unmaintained for a very long time.</H3>
+<P>
+<H1 ALIGN="CENTER">Configuring linux to run Apache 0.8 + with virtual hosts</H1>
+
+<P>Some advice on configuring Linux so that it can run <A HREF="/">Apache</A>
+and <A HREF="../docs/vhosts/">virtual hosts</A></P>
+
+<OL>
+  <LI>You'll need linux kernel <STRONG>1.2.x</STRONG> ( &gt;=5 recommended) and compile with the following options:
+  <PRE>
+	  CONFIG_MODVERSIONS=y
+	  CONFIG_NETDEVICES=y
+	  # CONFIG_DUMMY is not set          ( say no when configuring )</PRE>
+<BR><BR></LI>
+
+  <LI>make dep ; make zImage ; make modules ; make modules_install<BR><BR></LI>
+
+  <LI>cp /usr/src/linux/arch/i386/boot/zImage /vmlinuz<BR><BR></LI>
+
+  <LI>rdev -R /vmlinuz 1  ; lilo<BR><BR></LI>
+  <LI>reboot system <BR><BR></LI>
+  <LI>insmod -o dummy0 /lib/modules/1.2.x/net/dummy.o<BR><BR></LI>
+  <LI>ifconfig dummy0 200.200.200.50 up<BR>
+   NOTE: Make sure the IP address you choice is a valid one,
+   and not being used.
+  <BR><BR></LI>
+  <LI>arp -s &lt;ethernet address&gt; 200.200.200.50 netmask 255.255.255.255 pub<BR>
+  NOTE: the ethernet address of your ethernet card can be found if you
+  type ifconfig eth0.  First line, there are 6 hex numbers sepearted by 
+  ':'.  Use that.
+  <BR><BR></LI>
+  <LI>route add 200.200.200.50 dummy0<BR><BR></LI>
+  <LI>Add &lt;virtual host 200.200.200.50&gt; ..... &lt; /virtualhost&gt; to your httpd.conf file.<BR><BR></LI>
+  <LI>Add 200.200.200.50 to your /etc/hosts or DNS database files.<BR><BR></LI>
+  <LI>Repeat from <STRONG>Step 1.</STRONG> with dummy1 if so desired.<BR><BR></LI>
+</OL>
+
+<P>Good luck.</P>
+
+</BODY>
+</HTML>



Mime
View raw message