Cut and paste my ELF explaination from my -current post a few days

ago.  SGMLify it (I hope), word smith minor nits and try to catch all
my typos.  Those more qualified than I at SGML and spelling should
check to make sure that I've not fu-bar'd anything.

FAQ/misc.sgml

@@ -1,4 +1,4 @@
-<!-- $Id: misc.sgml,v 1.6 1998-08-18 23:26:50 dwhite Exp $ -->
+<!-- $Id: misc.sgml,v 1.7 1998-10-08 00:23:37 imp Exp $ -->
 <!-- The FreeBSD Documentation Project -->
 
   <sect>
@@ -82,7 +82,7 @@
       library mechanism is based more closely on Sun's
       <tt>SunOS</tt>-style shared library mechanism and, as such, is very
       easy to use.  
-	  However, starting with 3.0, FreeBSD will offically support <tt/ELF/
+	  However, starting with 3.0, FreeBSD offically supports <tt/ELF/
 	  binaries as the default format.  Even though the <tt/a.out/
 	  executable format has served us well, the GNU people, who author the
 	  compiler tools we use, have dropped support for the <tt/a.out/
@@ -92,6 +92,78 @@
 	  ISO-C++, notably contstructors and destructors, has also led to
 	  native <tt/ELF/ support in future FreeBSD releases.
 
+    <sect1>
+      <heading>Yes, but why are there so many different
+      formats?</heading>
+
+      <p>Back in the dim, dark past, there was simple hardware.  This
+      simple hardware supported a simple, small system.  a.out was
+      completely adequate for the job of representing binaries on this
+      simple system (a pdp-11).  As people ported unix from this
+      simple system, they retained the a.out format because it was
+      sufficent for the early ports of unix to thinks like the
+      motorola 68k, VAXen, etc.
+
+      <p>Then some bright hardware engineer desided that if he could
+      force software to do some sleezey tricks, then he'd be able to
+      shave a few gates off the design and allow his cpu core to run
+      faster.  While it was made to work with this new kind of
+      hardware (known these dayss as RISC), <tt/a.out/ was ill-suited
+      for this hardware, so many formats were developed to get to a
+      better performance from this hardware than the limited, simple
+      <tt/a.out/ format could offer.  Things like <tt/COFF/,
+      <tt/ECOFF/, and a few obscure others were invented and their
+      limitations explored before things seemed to settle on <tt/ELF/.
+
+      <p>In addition, program sizes were getting huge and disks (and
+      physical memory) were still relatively small so the concept of a
+      shared library was born.  The VM system also became more
+      sophisticated.  While each one of these advancements was done
+      using the <tt/a.out/ format, its usefulness was stretched more
+      and more with each new feature.  In addition, people wanted to
+      dynamically load things at run time, or to junk parts of their
+      program after the init code had run to save in core memory
+      and/or swap space.  Languages became more sophistocated and
+      people wanted code called before main automatically.  Lots of
+      hacks were done to the <tt/a.out/ format to allow all of these
+      things to happen, and they basically worked for a time.  In
+      time, <tt/a.out/ wasn't up to handling all these problems
+      without an ever increasing overhead in code and complexity.
+      While <tt/ELF/ solved many of these problems, it would be
+      painful to switch from the system that basically worked.  So
+      <tt/ELF/ had to wait until it was more painful to remain with
+      <tt/a.out/ than it was to migrate to <tt/ELF/.
+
+      <p>However, as time passed, the build tools that FreeBSD derived
+      their build tools from (the assembler and loader especially)
+      evolved in two parallel trees.  The FreeBSD tree added shared
+      libraries and fixed some bugs.  The GNU folks that originally
+      write these programs rewrote them and added simpler support for
+      building cross compilers, plugging in different formats at will,
+      etc.  Since many people wanted to build cross compilers
+      targeting FreeBSD, they were out of luck since the older sources
+      that FreeBSD had for as and ld weren't up to the task.  The new
+      gnu tools chain (binutils) does support cross compiling,
+      <tt/ELF/, shared libraries, C++ extnensions, etc.  In addition,
+      many vendors are releasing <tt/ELF/ binaries, and it is a good
+      thing for FreeBSD to run them.  And if it is running <tt/ELF/
+      binaries, why bother having <tt/a.out/ any more?  It is a tired
+      old horse that has proven useful for a long time, but it is time
+      to turn him out to pasture for his long, faithful years of
+      service.
+
+      <p><tt/ELF/ is more expressive than a.out and will allow more
+      extensibility in the base system.  The <tt/ELF/ tools are better
+      maintained, and offer cross compilation support, which is
+      important to many people.  <tt/ELF/ may be a little slower than
+      a.out, but trying to measure it can be difficult.  There are
+      also numerous details that are different between the two in how
+      they map pages, handle init code, etc.  None of these are very
+      important, but they are differences.  In time support for
+      <tt/a.out/ will be moved out of the GENERIC kernel, and
+      eventually removed from the kernel once the need to run legacy
+      <tt/a.out/ programs is past.
+
     <sect1>
       <heading>Why won't chmod change the permissions on symlinks?</heading>