Move most of the remaining USD/PSD/SMM papers into share/doc

13 files changed, 0 insertions, 2681 deletions

diff --git a/usr.sbin/config/SMM.doc/0.t b/usr.sbin/config/SMM.doc/0.t
deleted file mode 100644
index ae5bf77..0000000
--- a/usr.sbin/config/SMM.doc/0.t
+++ /dev/null
@@ -1,88 +0,0 @@
-.\" Copyright (c) 1983, 1993
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\" 3. All advertising materials mentioning features or use of this software
-.\"    must display the following acknowledgement:
-.\"	This product includes software developed by the University of
-.\"	California, Berkeley and its contributors.
-.\" 4. Neither the name of the University nor the names of its contributors
-.\"    may be used to endorse or promote products derived from this software
-.\"    without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\"	@(#)0.t	8.1 (Berkeley) 7/5/93
-.\"
-.bd S B 3
-.de UX
-.ie \\n(GA>0 \\$2UNIX\\$1
-.el \{\
-.if n \\$2UNIX\\$1*
-.if t \\$2UNIX\\$1\\f1\(dg\\fP
-.FS
-.if n *UNIX
-.if t \(dgUNIX
-.ie \\$3=1 is a Footnote of Bell Laboratories.
-.el is a Trademark of Bell Laboratories.
-.FE
-.nr GA 1\}
-..
-.de BR
-\fB\\$1\fP\\$2
-..
-.TL
-Building 4.4BSD Kernels with Config
-.AU
-Samuel J. Leffler and Michael J. Karels
-.AI
-Computer Systems Research Group
-Department of Electrical Engineering and Computer Science
-University of California, Berkeley
-Berkeley, California  94720
-.de IR
-\fI\\$1\fP\\$2
-..
-.de DT
-.TA 8 16 24 32 40 48 56 64 72 80
-..
-.AB
-.PP
-This document describes the use of
-\fIconfig\fP\|(8) to configure and create bootable
-4.4BSD system images.
-It discusses the structure of system
-configuration files and how to configure
-systems with non-standard hardware configurations.
-Sections describing the preferred way to
-add new code to the system and how the system's autoconfiguration
-process operates are included.  An appendix
-contains a summary of the rules used by the system
-in calculating the size of system data structures,
-and also indicates some of the standard system size
-limitations (and how to change them).
-Other configuration options are also listed.
-.sp
-.LP
-Revised July 5, 1993
-.AE
-.LP
-.OH 'Building 4.4BSD Kernels with Config''SMM:2-%'
-.EH 'SMM:2-%''Building 4.4BSD Kernels with Config'
diff --git a/usr.sbin/config/SMM.doc/1.t b/usr.sbin/config/SMM.doc/1.t
deleted file mode 100644
index 453041b..0000000
--- a/usr.sbin/config/SMM.doc/1.t
+++ /dev/null
@@ -1,61 +0,0 @@
-.\" Copyright (c) 1983, 1993
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\" 3. All advertising materials mentioning features or use of this software
-.\"    must display the following acknowledgement:
-.\"	This product includes software developed by the University of
-.\"	California, Berkeley and its contributors.
-.\" 4. Neither the name of the University nor the names of its contributors
-.\"    may be used to endorse or promote products derived from this software
-.\"    without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\"	@(#)1.t	8.1 (Berkeley) 6/8/93
-.\"
-.\".ds RH Introduction
-.ne 2i
-.sp 3
-.NH
-INTRODUCTION
-.PP
-.I Config
-is a tool used in building 4.4BSD system images (the UNIX kernel).
-It takes a file describing a system's tunable parameters and
-hardware support, and generates a collection
-of files which are then used to build a copy of UNIX appropriate
-to that configuration.
-.I Config
-simplifies system maintenance by isolating system dependencies
-in a single, easy to understand, file.
-.PP
-This document describes the content and 
-format of system configuration
-files and the rules which must be followed when creating 
-these files.  Example configuration files are constructed
-and discussed.
-.PP
-Later sections suggest guidelines to be used in modifying
-system source and explain some of the inner workings of the
-autoconfiguration process.  Appendix D summarizes the rules
-used in calculating the most important system data structures
-and indicates some inherent system data structure size
-limitations (and how to go about modifying them).
diff --git a/usr.sbin/config/SMM.doc/2.t b/usr.sbin/config/SMM.doc/2.t
deleted file mode 100644
index 34e6b63..0000000
--- a/usr.sbin/config/SMM.doc/2.t
+++ /dev/null
@@ -1,188 +0,0 @@
-.\" Copyright (c) 1983, 1993
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\" 3. All advertising materials mentioning features or use of this software
-.\"    must display the following acknowledgement:
-.\"	This product includes software developed by the University of
-.\"	California, Berkeley and its contributors.
-.\" 4. Neither the name of the University nor the names of its contributors
-.\"    may be used to endorse or promote products derived from this software
-.\"    without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\"	@(#)2.t	8.1 (Berkeley) 6/8/93
-.\"
-.\".ds RH "Configuration File Contents
-.ne 2i
-.NH
-CONFIGURATION FILE CONTENTS
-.PP
-A system configuration must include at least the following
-pieces of information:
-.IP \(bu 3
-machine type
-.IP \(bu 3
-cpu type
-.IP \(bu 3
-system identification
-.IP \(bu 3
-timezone
-.IP \(bu 3
-maximum number of users
-.IP \(bu 3
-location of the root file system
-.IP \(bu 3
-available hardware
-.PP
-.I Config
-allows multiple system images to be generated from a single
-configuration description.  Each system image is configured
-for identical hardware, but may have different locations for the root
-file system and, possibly, other system devices.
-.NH 2
-Machine type
-.PP
-The 
-.I "machine type"
-indicates if the system is going to operate on a DEC VAX-11\(dg computer,
-.FS
-\(dg DEC, VAX, UNIBUS, MASSBUS and MicroVAX are trademarks of Digital
-Equipment Corporation.
-.FE
-or some other machine on which 4.4BSD operates.  The machine type
-is used to locate certain data files which are machine specific, and
-also to select rules used in constructing the resultant
-configuration files.
-.NH 2
-Cpu type
-.PP
-The
-.I "cpu type"
-indicates which, of possibly many, cpu's the system is to operate on.
-For example, if the system is being configured for a VAX-11, it could
-be running on a VAX 8600, VAX-11/780, VAX-11/750, VAX-11/730 or MicroVAX II.
-(Other VAX cpu types, including the 8650, 785 and 725, are configured using
-the cpu designation for compatible machines introduced earlier.)
-Specifying
-more than one cpu type implies that the system should be configured to run
-on any of the cpu's specified.  For some types of machines this is not
-possible and 
-.I config
-will print a diagnostic indicating such.
-.NH 2
-System identification
-.PP
-The
-.I "system identification"
-is a moniker attached to the system, and often the machine on which the
-system is to run.  For example, at Berkeley we have machines named Ernie
-(Co-VAX), Kim (No-VAX), and so on.  The system identifier selected is used to
-create a global C ``#define'' which may be used to isolate system dependent
-pieces of code in the kernel.  For example, Ernie's Varian driver used
-to be special cased because its interrupt vectors were wired together.  The
-code in the driver which understood how to handle this non-standard hardware
-configuration was conditionally compiled in only if the system
-was for Ernie.  
-.PP
-The system identifier ``GENERIC'' is given to a system which
-will run on any cpu of a particular machine type; it should not
-otherwise be used for a system identifier.
-.NH 2
-Timezone
-.PP
-The timezone in which the system is to run is used to define the
-information returned by the \fIgettimeofday\fP\|(2)
-system call.  This value is specified as the number of hours east
-or west of GMT.  Negative numbers indicate a value east of GMT.
-The timezone specification may also indicate the
-type of daylight savings time rules to be applied.
-.NH 2
-Maximum number of users
-.PP
-The system allocates many system data structures at boot time
-based on the maximum number of users the system will support.
-This number is normally between 8 and 40, depending
-on the hardware and expected job mix.  The rules
-used to calculate system data structures are discussed in
-Appendix D.
-.NH 2
-Root file system location
-.PP
-When the system boots it must know the location of
-the root of the file system
-tree.  This location and the part(s) of the disk(s) to be used
-for paging and swapping must be specified in order to create
-a complete configuration description.  
-.I Config
-uses many rules to calculate default locations for these items;
-these are described in Appendix B.
-.PP
-When a generic system is configured, the root file system is left
-undefined until the system is booted.  In this case, the root file
-system need not be specified, only that the system is a generic system.
-.NH 2
-Hardware devices
-.PP
-When the system boots it goes through an
-.I autoconfiguration
-phase.  During this period, the system searches for all
-those hardware devices
-which the system builder has indicated might be present.  This probing
-sequence requires certain pieces of information such as register
-addresses, bus interconnects, etc.  A system's hardware may be configured
-in a very flexible manner or be specified without any flexibility
-whatsoever.  Most people do not configure hardware devices into the
-system unless they are currently present on the machine, expect
-them to be present in the near future, or are simply guarding
-against a hardware
-failure somewhere else at the site (it is often wise to configure in
-extra disks in case an emergency requires moving one off a machine which
-has hardware problems).
-.PP
-The specification of hardware devices usually occupies the majority of
-the configuration file.  As such, a large portion of this document will
-be spent understanding it.  Section 6.3 contains a description of
-the autoconfiguration process, as it applies to those planning to
-write, or modify existing, device drivers.
-.NH 2
-Pseudo devices
-.PP
-Several system facilities are configured in a manner like that used
-for hardware devices although they are not associated with specific hardware.
-These system options are configured as
-.IR pseudo-devices .
-Some pseudo devices allow an optional parameter that sets the limit
-on the number of instances of the device that are active simultaneously.
-.NH 2
-System options
-.PP
-Other than the mandatory pieces of information described above, it
-is also possible to include various optional system facilities
-or to modify system behavior and/or limits.
-For example, 4.4BSD can be configured to support binary compatibility for
-programs built under 4.3BSD.  Also, optional support is provided
-for disk quotas and tracing the performance of the virtual memory
-subsystem.  Any optional facilities to be configured into
-the system are specified in the configuration file.  The resultant
-files generated by
-.I config
-will automatically include the necessary pieces of the system.
diff --git a/usr.sbin/config/SMM.doc/3.t b/usr.sbin/config/SMM.doc/3.t
deleted file mode 100644
index e0b6234..0000000
--- a/usr.sbin/config/SMM.doc/3.t
+++ /dev/null
@@ -1,299 +0,0 @@
-.\" Copyright (c) 1983, 1993
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\" 3. All advertising materials mentioning features or use of this software
-.\"    must display the following acknowledgement:
-.\"	This product includes software developed by the University of
-.\"	California, Berkeley and its contributors.
-.\" 4. Neither the name of the University nor the names of its contributors
-.\"    may be used to endorse or promote products derived from this software
-.\"    without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\"	@(#)3.t	8.1 (Berkeley) 6/8/93
-.\"
-.\".ds RH "System Building Process
-.ne 2i
-.NH
-SYSTEM BUILDING PROCESS
-.PP
-In this section we consider the steps necessary to build a bootable system
-image.  We assume the system source is located in the ``/sys'' directory
-and that, initially, the system is being configured from source code.
-.PP
-Under normal circumstances there are 5 steps in building a system.
-.IP 1) 3
-Create a configuration file for the system.
-.IP 2) 3
-Make a directory for the system to be constructed in.
-.IP 3) 3
-Run
-.I config
-on the configuration file to generate the files required
-to compile and load the system image.
-.IP 4)
-Construct the source code interdependency rules for the
-configured system with
-.I make depend
-using
-.IR make (1).
-.IP 5)
-Compile and load the system with 
-.IR make .
-.PP
-Steps 1 and 2 are usually done only once.  When a system configuration
-changes it usually suffices to just run
-.I config
-on the modified configuration file, rebuild the source code dependencies,
-and remake the system.  Sometimes,
-however, configuration dependencies may not be noticed in which case
-it is necessary to clean out the relocatable object files saved
-in the system's directory; this will be discussed later.
-.NH 2
-Creating a configuration file
-.PP
-Configuration files normally reside in the directory ``/sys/conf''.
-A configuration file is most easily constructed by copying an
-existing configuration file and modifying it.  The 4.4BSD distribution
-contains a number of configuration files for machines at Berkeley;
-one may be suitable or, in worst case, a copy
-of the generic configuration file may be edited.
-.PP
-The configuration file must have the same name as the directory in
-which the configured system is to be built.  
-Further,
-.I config
-assumes this directory is located in the parent directory of
-the directory in which it
-is run.  For example, the generic
-system has a configuration file ``/sys/conf/GENERIC'' and an accompanying
-directory named ``/sys/GENERIC''.
-Although it is not required that the system sources and configuration
-files reside in ``/sys,'' the configuration and compilation procedure
-depends on the relative locations of directories within that hierarchy,
-as most of the system code and the files created by
-.I config
-use pathnames of the form ``../''.
-If the system files are not located in ``/sys,''
-it is desirable to make a symbolic link there for use in installation
-of other parts of the system that share files with the kernel.
-.PP
-When building the configuration file, be sure to include the items
-described in section 2.  In particular, the machine type,
-cpu type, timezone, system identifier, maximum users, and root device
-must be specified.  The specification of the hardware present may take
-a bit of work; particularly if your hardware is configured at non-standard
-places (e.g. device registers located at funny places or devices not
-supported by the system).  Section 4 of this document
-gives a detailed description of the configuration file syntax,
-section 5 explains some sample configuration files, and
-section 6 discusses how to add new devices to
-the system.  If the devices to be configured are not already
-described in one of the existing configuration files you should check
-the manual pages in section 4 of the UNIX Programmers Manual.  For each
-supported device, the manual page synopsis entry gives a
-sample configuration line.
-.PP
-Once the configuration file is complete, run it through
-.I config
-and look for any errors.  Never try and use a system which
-.I config
-has complained about; the results are unpredictable.
-For the most part,
-.IR config 's
-error diagnostics are self explanatory.  It may be the case that
-the line numbers given with the error messages are off by one.
-.PP
-A successful run of
-.I config
-on your configuration file will generate a number of files in
-the configuration directory.  These files are:
-.IP \(bu 3
-A file to be used by \fImake\fP\|(1)
-in compiling and loading the system,
-.IR Makefile .
-.IP \(bu 3
-One file for each possible system image for this machine,
-.IR swapxxx.c ,
-where
-.I xxx
-is the name of the system image,
-which describes where swapping, the root file system, and other
-miscellaneous system devices are located.
-.IP \(bu 3
-A collection of header files, one per possible device the
-system supports, which define the hardware configured.
-.IP \(bu 3
-A file containing the I/O configuration tables used by the system
-during its 
-.I autoconfiguration
-phase,
-.IR ioconf.c .
-.IP \(bu 3
-An assembly language file of interrupt vectors which
-connect interrupts from the machine's external buses to the main
-system path for handling interrupts,
-and a file that contains counters and names for the interrupt vectors.
-.PP
-Unless you have reason to doubt 
-.IR config ,
-or are curious how the system's autoconfiguration scheme
-works, you should never have to look at any of these files.
-.NH 2
-Constructing source code dependencies
-.PP
-When 
-.I config
-is done generating the files needed to compile and link your system it
-will terminate with a message of the form ``Don't forget to run make depend''.
-This is a reminder that you should change over to the configuration
-directory for the system just configured and type ``make depend''
-to build the rules used by 
-.I make
-to recognize interdependencies in the system source code.
-This will insure that any changes to a piece of the system
-source code will result in the proper modules being recompiled
-the next time
-.I make
-is run.
-.PP
-This step is particularly important if your site makes changes
-to the system include files.  The rules generated specify which source code
-files are dependent on which include files.  Without these rules,
-.I make
-will not recognize when it must rebuild modules
-due to the modification of a system header file.
-The dependency rules are generated by a pass of the C preprocessor
-and reflect the global system options.
-This step must be repeated when the configuration file is changed
-and
-.I config
-is used to regenerate the system makefile.
-.NH 2
-Building the system
-.PP
-The makefile constructed by
-.I config
-should allow a new system to be rebuilt by simply typing ``make image-name''.
-For example, if you have named your bootable system image ``kernel'',
-then ``make kernel''
-will generate a bootable image named ``kernel''.  Alternate system image names
-are used when the root file system location and/or swapping configuration
-is done in more than one way.  The makefile which
-.I config
-creates has entry points for each system image defined in
-the configuration file.
-Thus, if you have configured ``kernel'' to be a system with the root file
-system on an ``hp'' device and ``hkkernel'' to be a system with the root
-file system on an ``hk'' device, then ``make kernel hkkernel'' will generate
-binary images for each.
-As the system will generally use the disk from which it is loaded
-as the root filesystem, separate system images are only required
-to support different swap configurations.
-.PP
-Note that the name of a bootable image is different from the system
-identifier.  All bootable images are configured for the same system;
-only the information about the root file system and paging devices differ.
-(This is described in more detail in section 4.)
-.PP
-The last step in the system building process is to rearrange certain commonly
-used symbols in the symbol table of the system image;  the makefile
-generated by 
-.I config
-does this automatically for you.
-This is advantageous for programs such as
-\fInetstat\fP\|(1) and \fIvmstat\fP\|(1),
-which run much faster when the symbols they need are located at
-the front of the symbol table.  
-Remember also that many programs expect
-the currently executing system to be named ``/kernel''.  If you install
-a new system and name it something other than ``/kernel'', many programs
-are likely to give strange results.
-.NH 2
-Sharing object modules
-.PP
-If you have many systems which are all built on a single machine
-there are at least two approaches to saving time in building system
-images.  The best way is to have a single system image which is run on
-all machines.  This is attractive since it minimizes disk space used
-and time required to rebuild systems after making changes.  However,
-it is often the case that one or more systems will require a separately
-configured system image.  This may be due to limited memory (building
-a system with many unused device drivers can be expensive), or to
-configuration requirements (one machine may be a development machine
-where disk quotas are not needed, while another is a production machine
-where they are), etc.  In these cases it is possible
-for common systems to share relocatable object modules which are not
-configuration dependent; most of the modules in the directory ``/sys/sys''
-are of this sort.
-.PP
-To share object modules, a generic system should be built.  Then, for
-each system configure the system as before, but before recompiling and
-linking the system, type ``make links'' in the system compilation directory.
-This will cause the system
-to be searched for source modules which are safe to share between systems
-and generate symbolic links in the current directory to the appropriate
-object modules in the directory ``../GENERIC''.  A shell script,
-``makelinks'' is generated with this request and may be checked for
-correctness.  The file ``/sys/conf/defines'' contains a list of symbols
-which we believe are safe to ignore when checking the source code
-for modules which may be shared.  Note that this list includes the definitions
-used to conditionally compile in the virtual memory tracing facilities, and
-the trace point support used only rarely (even at Berkeley). 
-It may be necessary
-to modify this file to reflect local needs.  Note further that
-interdependencies which are not directly visible
-in the source code are not caught.  This means that if you place
-per-system dependencies in an include file, they will not be recognized
-and the shared code may be selected in an unexpected fashion.
-.NH 2
-Building profiled systems
-.PP
-It is simple to configure a system which will automatically
-collect profiling information as it operates.  The profiling data
-may be collected with \fIkgmon\fP\|(8) and processed with
-\fIgprof\fP\|(1)
-to obtain information regarding the system's operation.  Profiled
-systems maintain histograms of the program counter as well as the
-number of invocations of each routine.  The \fIgprof\fP
-command will also generate a dynamic call graph of the executing
-system and propagate time spent in each routine along the arcs
-of the call graph (consult the \fIgprof\fP documentation for elaboration).
-The program counter sampling can be driven by the system clock, or
-if you have an alternate real time clock, this can be used.  The 
-latter is highly recommended, as use of the system clock will result
-in statistical anomalies, and time spent in the clock routine will
-not be accurately attributed.
-.PP
-To configure a profiled system, the
-.B \-p
-option should be supplied to \fIconfig\fP.
-A profiled system is about 5-10% larger in its text space due to
-the calls to count the subroutine invocations.  When the system
-executes, the profiling data is stored in a buffer which is 1.2
-times the size of the text space.  The overhead for running a
-profiled system varies; under normal load we see anywhere from 5-25%
-of the system time spent in the profiling code.
-.PP
-Note that systems configured for profiling should not be shared as
-described above unless all the other shared systems are also to be
-profiled.
diff --git a/usr.sbin/config/SMM.doc/4.t b/usr.sbin/config/SMM.doc/4.t
deleted file mode 100644
index 7498185..0000000
--- a/usr.sbin/config/SMM.doc/4.t
+++ /dev/null
@@ -1,442 +0,0 @@
-.\" Copyright (c) 1983, 1993
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\" 3. All advertising materials mentioning features or use of this software
-.\"    must display the following acknowledgement:
-.\"	This product includes software developed by the University of
-.\"	California, Berkeley and its contributors.
-.\" 4. Neither the name of the University nor the names of its contributors
-.\"    may be used to endorse or promote products derived from this software
-.\"    without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\"	@(#)4.t	8.1 (Berkeley) 6/8/93
-.\"
-.\".ds RH "Configuration File Syntax
-.ne 2i
-.NH
-CONFIGURATION FILE SYNTAX
-.PP
-In this section we consider the specific rules used in writing
-a configuration file.  A complete grammar for the input language
-can be found in Appendix A and may be of use if you should have
-problems with syntax errors.
-.PP
-A configuration file is broken up into three logical pieces:
-.IP \(bu 3
-configuration parameters global to all system images 
-specified in the configuration file,
-.IP \(bu 3
-parameters specific to each
-system image to be generated, and
-.IP \(bu 3
-device specifications.
-.NH 2
-Global configuration parameters
-.PP
-The global configuration parameters are the type of machine,
-cpu types, options, timezone, system identifier, and maximum users.
-Each is specified with a separate line in the configuration file.
-.IP "\fBmachine\fP \fItype\fP"
-.br
-The system is to run on the machine type specified.  No more than
-one machine type can appear in the configuration file.  Legal values
-are
-.B vax
-and
-\fBsun\fP.
-.IP "\fBcpu\fP ``\fItype\fP''"
-.br
-This system is to run on the cpu type specified.
-More than one cpu type specification
-can appear in a configuration file.
-Legal types for a
-.B vax
-machine are
-\fBVAX8600\fP, \fBVAX780\fP, \fBVAX750\fP,
-\fBVAX730\fP
-and
-\fBVAX630\fP (MicroVAX II).
-The 8650 is listed as an 8600, the 785 as a 780, and a 725 as a 730.
-.IP "\fBoptions\fP \fIoptionlist\fP"
-.br
-Compile the listed optional code into the system. 
-Options in this list are separated by commas.
-Possible options are listed at the top of the generic makefile.
-A line of the form ``options FUNNY,HAHA'' generates global ``#define''s
-\-DFUNNY \-DHAHA in the resultant makefile.
-An option may be given a value by following its name with ``\fB=\fP'',
-then the value enclosed in (double) quotes.
-The following are major options are currently in use:
-COMPAT (include code for compatibility with 4.1BSD binaries),
-INET (Internet communication protocols),
-NS (Xerox NS communication protocols),
-and
-QUOTA (enable disk quotas).
-Other kernel options controlling system sizes and limits
-are listed in Appendix D;
-options for the network are found in Appendix E.
-There are additional options which are associated with certain
-peripheral devices; those are listed in the Synopsis section
-of the manual page for the device.
-.IP "\fBmakeoptions\fP \fIoptionlist\fP"
-.br
-Options that are used within the system makefile
-and evaluated by
-.I make
-are listed as
-.IR makeoptions .
-Options are listed with their values with the form
-``makeoptions name=value,name2=value2.''
-The values must be enclosed in double quotes if they include numerals
-or begin with a dash.
-.IP "\fBtimezone\fP \fInumber\fP [ \fBdst\fP [ \fInumber\fP ] ]"
-.br
-Specifies the timezone used by the system.  This is measured in the
-number of hours your timezone is west of GMT.  
-EST is 5 hours west of GMT, PST is 8.  Negative numbers
-indicate hours east of GMT. If you specify
-\fBdst\fP, the system will operate under daylight savings time.
-An optional integer or floating point number may be included
-to specify a particular daylight saving time correction algorithm;
-the default value is 1, indicating the United States.
-Other values are: 2 (Australian style), 3 (Western European),
-4 (Middle European), and 5 (Eastern European).  See
-\fIgettimeofday\fP\|(2) and \fIctime\fP\|(3) for more information.
-.IP "\fBident\fP \fIname\fP"
-.br
-This system is to be known as
-.IR name .
-This is usually a cute name like ERNIE (short for Ernie Co-Vax) or
-VAXWELL (for Vaxwell Smart).
-This value is defined for use in conditional compilation,
-and is also used to locate an optional list of source files specific
-to this system.
-.IP "\fBmaxusers\fP \fInumber\fP"
-.br
-The maximum expected number of simultaneously active user on this system is
-.IR number .
-This number is used to size several system data structures.
-.NH 2
-System image parameters
-.PP
-Multiple bootable images may be specified in a single configuration
-file.  The systems will have the same global configuration parameters
-and devices, but the location of the root file system and other
-system specific devices may be different.  A system image is specified
-with a ``config'' line:
-.IP
-\fBconfig\fP\ \fIsysname\fP\ \fIconfig-clauses\fP
-.LP
-The
-.I sysname
-field is the name given to the loaded system image; almost everyone
-names their standard system image ``kernel''.  The configuration clauses
-are one or more specifications indicating where the root file system
-is located and the number and location of paging devices.
-The device used by the system to process argument lists during
-.IR execve (2)
-calls may also be specified, though in practice this is almost
-always selected by
-.I config
-using one of its rules for selecting default locations for
-system devices.
-.PP
-A configuration clause is one of the following
-.IP
-.nf
-\fBroot\fP [ \fBon\fP ] \fIroot-device\fP
-\fBswap\fP [ \fBon\fP ] \fIswap-device\fP [ \fBand\fP \fIswap-device\fP ] ...
-\fBdumps\fP [ \fBon\fP ] \fIdump-device\fP
-\fBargs\fP [ \fBon\fP ] \fIarg-device\fP
-.LP
-(the ``on'' is optional.)  Multiple configuration clauses
-are separated by white space; 
-.I config
-allows specifications to be continued across multiple lines
-by beginning the continuation line with a tab character.
-The ``root'' clause specifies where the root file system
-is located, the ``swap'' clause indicates swapping and paging
-area(s), the ``dumps'' clause can be used to force system dumps
-to be taken on a particular device, and the ``args'' clause
-can be used to specify that argument list processing for
-.I execve
-should be done on a particular device.
-.PP
-The device names supplied in the clauses may be fully specified
-as a device, unit, and file system partition; or underspecified
-in which case
-.I config
-will use builtin rules to select default unit numbers and file
-system partitions.  The defaulting rules are a bit complicated
-as they are dependent on the overall system configuration.
-For example, the swap area need not be specified at all if 
-the root device is specified; in this case the swap area is
-placed in the ``b'' partition of the same disk where the root
-file system is located.  Appendix B contains a complete list
-of the defaulting rules used in selecting system configuration
-devices.
-.PP
-The device names are translated to the
-appropriate major and minor device
-numbers on a per-machine basis.  A file,
-``/sys/conf/devices.machine'' (where ``machine''
-is the machine type specified in the configuration file),
-is used to map a device name to its major block device number.
-The minor device number is calculated using the standard 
-disk partitioning rules: on unit 0, partition ``a'' is minor device
-0, partition ``b'' is minor device 1, and so on; for units
-other than 0, add 8 times the unit number to get the minor
-device.
-.PP
-If the default mapping of device name to major/minor device
-number is incorrect for your configuration, it can be replaced
-by an explicit specification of the major/minor device.
-This is done by substituting
-.IP
-\fBmajor\fP \fIx\fP \fBminor\fP \fIy\fP
-.LP
-where the device name would normally be found.  For example,
-.IP
-.nf
-\fBconfig\fP kernel \fBroot\fP \fBon\fP \fBmajor\fP 99 \fBminor\fP 1
-.fi
-.PP
-Normally, the areas configured for swap space are sized by the system
-at boot time.  If a non-standard size is to be used for one
-or more swap areas (less than the full partition),
-this can also be specified.  To do this, the
-device name specified for a swap area should have a ``size''
-specification appended.  For example,
-.IP
-.nf
-\fBconfig\fP kernel \fBroot\fP \fBon\fP hp0 \fBswap\fP \fBon\fP hp0b \fBsize\fP 1200
-.fi
-.LP
-would force swapping to be done in partition ``b'' of ``hp0'' and
-the swap partition size would be set to 1200 sectors.  A swap area
-sized larger than the associated disk partition is trimmed to the
-partition size.
-.PP
-To create a generic configuration, only the clause ``swap generic''
-should be specified; any extra clauses will cause an error.
-.NH 2
-Device specifications
-.PP
-Each device attached to a machine must be specified
-to
-.I config
-so that the system generated will know to probe for it during
-the autoconfiguration process carried out at boot time.  Hardware
-specified in the configuration need not actually be present on
-the machine where the generated system is to be run.  Only the
-hardware actually found at boot time will be used by the system.
-.PP
-The specification of hardware devices in the configuration file
-parallels the interconnection hierarchy of the machine to be
-configured.  On the VAX, this means that a configuration file must
-indicate what MASSBUS and UNIBUS adapters are present, and to
-which \fInexi\fP they might be connected.* 
-.FS
-* While VAX-11/750's and VAX-11/730 do not actually have 
-nexi, the system treats them as having 
-.I "simulated nexi"
-to simplify device configuration.
-.FE
-Similarly, devices
-and controllers must be indicated as possibly being connected
-to one or more adapters.  A device description may provide a
-complete definition of the possible configuration parameters
-or it may leave certain parameters undefined and make the system
-probe for all the possible values.  The latter allows a single
-device configuration list to match many possible physical
-configurations.  For example, a disk may be indicated as present
-at UNIBUS adapter 0, or at any UNIBUS adapter which the system
-locates at boot time.  The latter scheme, termed 
-.IR wildcarding ,
-allows more flexibility in the physical configuration of a system;
-if a disk must be moved around for some reason, the system will
-still locate it at the alternate location.
-.PP
-A device specification takes one of the following forms:
-.IP
-.nf
-\fBmaster\fP \fIdevice-name\fP \fIdevice-info\fP
-\fBcontroller\fP \fIdevice-name\fP \fIdevice-info\fP [ \fIinterrupt-spec\fP ]
-\fBdevice\fP \fIdevice-name\fP \fIdevice-info\fP \fIinterrupt-spec\fP
-\fBdisk\fP \fIdevice-name\fP \fIdevice-info\fP
-\fBtape\fP \fIdevice-name\fP \fIdevice-info\fP
-.fi
-.LP
-A ``master'' is a MASSBUS tape controller; a ``controller'' is a
-disk controller, a UNIBUS tape controller, a MASSBUS adapter, or
-a UNIBUS adapter.  A ``device'' is an autonomous device which
-connects directly to a UNIBUS adapter (as opposed to something
-like a disk which connects through a disk controller).  ``Disk''
-and ``tape'' identify disk drives and tape drives connected to
-a ``controller'' or ``master.''
-.PP
-The
-.I device-name
-is one of the standard device names, as
-indicated in section 4 of the UNIX Programmers Manual,
-concatenated with the
-.I logical
-unit number to be assigned the device (the 
-.I logical
-unit number may be different than the
-.I physical
-unit number indicated on the front of something
-like a disk; the
-.I logical
-unit number is used to refer to the UNIX device, not
-the physical unit number).  For example, ``hp0'' is logical
-unit 0 of a MASSBUS storage device, even though it might
-be physical unit 3 on MASSBUS adapter 1.
-.PP
-The
-.I device-info
-clause specifies how the hardware is
-connected in the interconnection hierarchy.  On the VAX,
-UNIBUS and MASSBUS adapters are connected to the internal
-system bus through
-a \fInexus\fP.
-Thus, one of the following
-specifications would be used:
-.IP
-.ta 1.5i 2.5i 4.0i
-.nf
-\fBcontroller\fP	mba0	\fBat\fP \fBnexus\fP \fIx\fP
-\fBcontroller\fP	uba0	\fBat\fP \fBnexus\fP \fIx\fP
-.fi
-.LP
-To tie a controller to a specific nexus, ``x'' would be supplied
-as the number of that nexus; otherwise ``x'' may be specified as
-``?'', in which
-case the system will probe all nexi present looking
-for the specified controller.
-.PP
-The remaining interconnections on the VAX are:
-.IP \(bu 3
-a controller
-may be connected to another controller (e.g. a disk controller attached
-to a UNIBUS adapter),
-.IP \(bu 3
-a master is always attached to a controller (a MASSBUS adapter),
-.IP \(bu 3
-a tape is always attached to a master (for MASSBUS
-tape drives),
-.IP \(bu 3
-a disk is always attached to a controller, and
-.IP \(bu 3
-devices
-are always attached to controllers (e.g. UNIBUS controllers attached
-to UNIBUS adapters).
-.LP
-The following lines give an example of each of these interconnections:
-.IP
-.ta 1.5i 2.5i 4.0i
-.nf
-\fBcontroller\fP	hk0	\fBat\fP uba0 ...
-\fBmaster\fP	ht0	\fBat\fP mba0 ...
-\fBdisk\fP	hp0	\fBat\fP mba0 ...
-\fBtape\fP	tu0	\fBat\fP ht0 ...
-\fBdisk\fP	rk1	\fBat\fP hk0 ...
-\fBdevice\fP	dz0	\fBat\fP uba0 ...
-.fi
-.LP
-Any piece of hardware which may be connected to a specific
-controller may also be wildcarded across multiple controllers.
-.PP
-The final piece of information needed by the system to configure
-devices is some indication of where or how a device will interrupt.
-For tapes and disks, simply specifying the \fIslave\fP or \fIdrive\fP
-number is sufficient to locate the control status register for the
-device.
-\fIDrive\fP numbers may be wildcarded
-on MASSBUS devices, but not on disks on a UNIBUS controller.
-For controllers, the control status register must be
-given explicitly, as well the number of interrupt vectors used and
-the names of the routines to which they should be bound. 
-Thus the example lines given above might be completed as:
-.IP
-.ta 1.5i 2.5i 4.0i
-.nf
-\fBcontroller\fP	hk0	\fBat\fP uba0 \fBcsr\fP 0177440	\fBvector\fP rkintr
-\fBmaster\fP	ht0	\fBat\fP mba0 \fBdrive\fP 0
-\fBdisk\fP	hp0	\fBat\fP mba0 \fBdrive\fP ?
-\fBtape\fP	tu0	\fBat\fP ht0 \fBslave\fP 0
-\fBdisk\fP	rk1	\fBat\fP hk0 \fBdrive\fP 1
-\fBdevice\fP	dz0	\fBat\fP uba0 \fBcsr\fP 0160100	\fBvector\fP dzrint dzxint
-.fi
-.PP
-Certain device drivers require extra information passed to them
-at boot time to tailor their operation to the actual hardware present.
-The line printer driver, for example, needs to know how many columns
-are present on each non-standard line printer (i.e. a line printer
-with other than 80 columns).  The drivers for the terminal multiplexors
-need to know which lines are attached to modem lines so that no one will
-be allowed to use them unless a connection is present.  For this reason,
-one last parameter may be specified to a
-.IR device ,
-a 
-.I flags
-field.  It has the syntax
-.IP
-\fBflags\fP \fInumber\fP
-.LP
-and is usually placed after the
-.I csr
-specification.  The
-.I number
-is passed directly to the associated driver.  The manual pages
-in section 4 should be consulted to determine how each driver
-uses this value (if at all).
-Communications interface drivers commonly use the flags
-to indicate whether modem control signals are in use.
-.PP
-The exact syntax for each specific device is given in the Synopsis
-section of its manual page in section 4 of the manual.
-.NH 2
-Pseudo-devices
-.PP
-A number of drivers and software subsystems
-are treated like device drivers without any associated hardware.
-To include any of these pieces, a ``pseudo-device'' specification
-must be used.  A specification for a pseudo device takes the form
-.IP
-.DT
-.nf
-\fBpseudo-device\fP	\fIdevice-name\fP [ \fIhowmany\fP ]
-.fi
-.PP
-Examples of pseudo devices are
-\fBpty\fP, the pseudo terminal driver (where the optional
-.I howmany
-value indicates the number of pseudo terminals to configure, 32 default),
-and \fBloop\fP, the software loopback network pseudo-interface.
-Other pseudo devices for the network include
-\fBimp\fP (required when a CSS or ACC imp is configured)
-and \fBether\fP (used by the Address Resolution Protocol
-on 10 Mb/sec Ethernets).
-More information on configuring each of these can also be found
-in section 4 of the manual.
diff --git a/usr.sbin/config/SMM.doc/5.t b/usr.sbin/config/SMM.doc/5.t
deleted file mode 100644
index 81f2a52..0000000
--- a/usr.sbin/config/SMM.doc/5.t
+++ /dev/null
@@ -1,271 +0,0 @@
-.\" Copyright (c) 1983, 1993
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\" 3. All advertising materials mentioning features or use of this software
-.\"    must display the following acknowledgement:
-.\"	This product includes software developed by the University of
-.\"	California, Berkeley and its contributors.
-.\" 4. Neither the name of the University nor the names of its contributors
-.\"    may be used to endorse or promote products derived from this software
-.\"    without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\"	@(#)5.t	8.1 (Berkeley) 6/8/93
-.\"
-.\".ds RH "Sample Configuration Files
-.ne 2i
-.NH
-SAMPLE CONFIGURATION FILES
-.PP
-In this section we will consider how to configure a
-sample VAX-11/780 system on which the hardware can be
-reconfigured to guard against various hardware mishaps.
-We then study the rules needed to configure a VAX-11/750
-to run in a networking environment.
-.NH 2
-VAX-11/780 System
-.PP
-Our VAX-11/780 is configured with hardware
-recommended in the document ``Hints on Configuring a VAX for 4.2BSD''
-(this is one of the high-end configurations).
-Table 1 lists the pertinent hardware to be configured.
-.DS B
-.TS
-box;
-l | l | l | l | l
-l | l | l | l | l.
-Item	Vendor	Connection	Name	Reference
-_
-cpu	DEC		VAX780
-MASSBUS controller	Emulex	nexus ?	mba0	hp(4)
-disk	Fujitsu	mba0	hp0
-disk	Fujitsu	mba0	hp1
-MASSBUS controller	Emulex	nexus ?	mba1
-disk	Fujitsu	mba1	hp2
-disk	Fujitsu	mba1	hp3
-UNIBUS adapter	DEC	nexus ?
-tape controller	Emulex	uba0	tm0	tm(4)
-tape drive	Kennedy	tm0	te0
-tape drive	Kennedy	tm0	te1
-terminal multiplexor	Emulex	uba0	dh0	dh(4)
-terminal multiplexor	Emulex	uba0	dh1
-terminal multiplexor	Emulex	uba0	dh2
-.TE
-.DE
-.ce
-Table 1.  VAX-11/780 Hardware support.
-.LP
-We will call this machine ANSEL and construct a configuration
-file one step at a time.
-.PP
-The first step is to fill in the global configuration parameters.
-The machine is a VAX, so the
-.I "machine type"
-is ``vax''.  We will assume this system will
-run only on this one processor, so the 
-.I "cpu type"
-is ``VAX780''.  The options are empty since this is going to
-be a ``vanilla'' VAX.  The system identifier, as mentioned before,
-is ``ANSEL,'' and the maximum number of users we plan to support is
-about 40.  Thus the beginning of the configuration file looks like
-this:
-.DS
-.ta 1.5i 2.5i 4.0i
-#
-# ANSEL VAX (a picture perfect machine)
-#
-machine	vax
-cpu	VAX780
-timezone	8 dst
-ident	ANSEL
-maxusers	40
-.DE
-.PP
-To this we must then add the specifications for three
-system images.  The first will be our standard system with the
-root on ``hp0'' and swapping on the same drive as the root.
-The second will have the root file system in the same location,
-but swap space interleaved among drives on each controller.
-Finally, the third will be a generic system,
-to allow us to boot off any of the four disk drives.
-.DS
-.ta 1.5i 2.5i
-config	kernel	root on hp0
-config	hpkernel	root on hp0 swap on hp0 and hp2
-config	genkernel	swap generic
-.DE
-.PP
-Finally, the hardware must be specified.  Let us first just try
-transcribing the information from Table 1.
-.DS
-.ta 1.5i 2.5i 4.0i
-controller	mba0	at nexus ?
-disk	hp0	at mba0 disk 0
-disk	hp1	at mba0 disk 1
-controller	mba1	at nexus ?
-disk	hp2	at mba1 disk 2
-disk	hp3	at mba1 disk 3
-controller	uba0	at nexus ?
-controller	tm0	at uba0 csr 0172520	vector tmintr
-tape	te0	at tm0 drive 0
-tape	te1	at tm0 drive 1
-device	dh0	at uba0 csr 0160020	vector dhrint dhxint
-device	dm0	at uba0 csr 0170500	vector dmintr
-device	dh1	at uba0 csr 0160040	vector dhrint dhxint
-device	dh2	at uba0 csr 0160060	vector dhrint dhxint
-.DE
-.LP
-(Oh, I forgot to mention one panel of the terminal multiplexor
-has modem control, thus the ``dm0'' device.)
-.PP
-This will suffice, but leaves us with little flexibility.  Suppose
-our first disk controller were to break.  We would like to recable the
-drives normally on the second controller so that all our disks could
-still be used without reconfiguring the system.  To do this we wildcard
-the MASSBUS adapter connections and also the slave numbers.  Further,
-we wildcard the UNIBUS adapter connections in case we decide some time
-in the future to purchase another adapter to offload the single UNIBUS
-we currently have.  The revised device specifications would then be:
-.DS
-.ta 1.5i 2.5i 4.0i
-controller	mba0	at nexus ?
-disk	hp0	at mba? disk ?
-disk	hp1	at mba? disk ?
-controller	mba1	at nexus ?
-disk	hp2	at mba? disk ?
-disk	hp3	at mba? disk ?
-controller	uba0	at nexus ?
-controller	tm0	at uba? csr 0172520	vector tmintr
-tape	te0	at tm0 drive 0
-tape	te1	at tm0 drive 1
-device	dh0	at uba? csr 0160020	vector dhrint dhxint
-device	dm0	at uba? csr 0170500	vector dmintr
-device	dh1	at uba? csr 0160040	vector dhrint dhxint
-device	dh2	at uba? csr 0160060	vector dhrint dhxint
-.DE
-.LP
-The completed configuration file for ANSEL is shown in Appendix C.
-.NH 2
-VAX-11/750 with network support
-.PP
-Our VAX-11/750 system will be located on two 10Mb/s Ethernet
-local area networks and also the DARPA Internet.  The system
-will have a MASSBUS drive for the root file system and two
-UNIBUS drives.  Paging is interleaved among all three drives.
-We have sold our standard DEC terminal multiplexors since this
-machine will be accessed solely through the network.  This
-machine is not intended to have a large user community, it
-does not have a great deal of memory.  First the global parameters:
-.DS
-.ta 1.5i 2.5i 4.0i
-#
-# UCBVAX (Gateway to the world)
-#
-machine	vax
-cpu	"VAX780"
-cpu	"VAX750"
-ident	UCBVAX
-timezone	8 dst
-maxusers	32
-options	INET
-options	NS
-.DE
-.PP
-The multiple cpu types allow us to replace UCBVAX with a
-more powerful cpu without reconfiguring the system.  The
-value of 32 given for the maximum number of users is done to
-force the system data structures to be over-allocated.  That
-is desirable on this machine because, while it is not expected
-to support many users, it is expected to perform a great deal
-of work.
-The ``INET'' indicates that we plan to use the
-DARPA standard Internet protocols on this machine,
-and ``NS'' also includes support for Xerox NS protocols.
-Note that unlike 4.2BSD configuration files,
-the network protocol options do not require corresponding pseudo devices.
-.PP
-The system images and disks are configured next.
-.DS
-.ta 1.5i 2.5i 4.0i
-config	kernel	root on hp swap on hp and rk0 and rk1
-config 	upkernel	root on up
-config 	hkkernel	root on hk swap on rk0 and rk1
-
-controller	mba0	at nexus ?
-controller	uba0	at nexus ?
-disk	hp0	at mba? drive 0
-disk	hp1	at mba? drive 1
-controller	sc0	at uba? csr 0176700	vector upintr
-disk	up0	at sc0 drive 0
-disk	up1	at sc0 drive 1
-controller	hk0	at uba? csr 0177440 	vector rkintr
-disk	rk0	at hk0 drive 0
-disk	rk1	at hk0 drive 1
-.DE
-.PP
-UCBVAX requires heavy interleaving of its paging area to keep up
-with all the mail traffic it handles.  The limiting factor on this
-system's performance is usually the number of disk arms, as opposed
-to memory or cpu cycles.  The extra UNIBUS controller, ``sc0'',
-is in case the MASSBUS controller breaks and a spare controller
-must be installed (most of our old UNIBUS controllers have been
-replaced with the newer MASSBUS controllers, so we have a number
-of these around as spares).
-.PP
-Finally, we add in the network devices.
-Pseudo terminals are needed to allow users to
-log in across the network (remember the only hardwired terminal
-is the console).
-The software loopback device is used for on-machine communications.
-The connection to the Internet is through
-an IMP, this requires yet another
-.I pseudo-device
-(in addition to the actual hardware device used by the
-IMP software).  And, finally, there are the two Ethernet devices.
-These use a special protocol, the Address Resolution Protocol (ARP),
-to map between Internet and Ethernet addresses.  Thus, yet another
-.I pseudo-device
-is needed.  The additional device specifications are show below.
-.DS
-.ta 1.5i 2.5i 4.0i
-pseudo-device	pty
-pseudo-device	loop
-pseudo-device	imp
-device	acc0	at uba? csr 0167600	vector accrint accxint
-pseudo-device	ether
-device	ec0	at uba? csr 0164330	vector ecrint eccollide ecxint
-device	il0	at uba? csr 0164000	vector ilrint ilcint
-.DE
-.LP
-The completed configuration file for UCBVAX is shown in Appendix C.
-.NH 2
-Miscellaneous comments
-.PP
-It should be noted in these examples that neither system was
-configured to use disk quotas or the 4.1BSD compatibility mode.
-To use these optional facilities, and others, we would probably
-clean out our current configuration, reconfigure the system, then
-recompile and relink the system image(s).  This could, of course,
-be avoided by figuring out which relocatable object files are 
-affected by the reconfiguration, then reconfiguring and recompiling
-only those files affected by the configuration change.  This technique
-should be used carefully.
diff --git a/usr.sbin/config/SMM.doc/6.t b/usr.sbin/config/SMM.doc/6.t
deleted file mode 100644
index 49f6e91..0000000
--- a/usr.sbin/config/SMM.doc/6.t
+++ /dev/null
@@ -1,233 +0,0 @@
-.\" Copyright (c) 1983, 1993
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\" 3. All advertising materials mentioning features or use of this software
-.\"    must display the following acknowledgement:
-.\"	This product includes software developed by the University of
-.\"	California, Berkeley and its contributors.
-.\" 4. Neither the name of the University nor the names of its contributors
-.\"    may be used to endorse or promote products derived from this software
-.\"    without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\"	@(#)6.t	8.1 (Berkeley) 6/8/93
-.\" $FreeBSD$
-.\"
-.\".ds RH "Adding New Devices
-.ne 2i
-.NH
-ADDING NEW SYSTEM SOFTWARE
-.PP
-This section is not for the novice, it describes
-some of the inner workings of the configuration process as
-well as the pertinent parts of the system autoconfiguration process.
-It is intended to give
-those people who intend to install new device drivers and/or
-other system facilities sufficient information to do so in the
-manner which will allow others to easily share the changes.
-.PP
-This section is broken into four parts:
-.IP \(bu 3
-general guidelines to be followed in modifying system code,
-.IP \(bu 3
-how to add non-standard system facilities to 4.4BSD,
-.IP \(bu 3
-how to add a device driver to 4.4BSD, and
-.NH 2
-Modifying system code
-.PP
-If you wish to make site-specific modifications to the system
-it is best to bracket them with
-.DS
-#ifdef SITENAME
-\&...
-#endif
-.DE
-to allow your source to be easily distributed to others, and
-also to simplify \fIdiff\fP\|(1) listings.  If you choose not
-to use a source code control system (e.g. SCCS, RCS), and
-perhaps even if you do, it is
-recommended that you save the old code with something
-of the form:
-.DS
-#ifndef SITENAME
-\&...
-#endif
-.DE
-We try to isolate our site-dependent code in individual files
-which may be configured with pseudo-device specifications.
-.PP
-Indicate machine-specific code with ``#ifdef vax'' (or other machine,
-as appropriate).
-4.4BSD underwent extensive work to make it extremely portable to
-machines with similar architectures\- you may someday find
-yourself trying to use a single copy of the source code on
-multiple machines.
-.NH 2
-Adding non-standard system facilities
-.PP
-This section considers the work needed to augment 
-.IR config 's
-data base files for non-standard system facilities.
-.I Config
-uses a set of files that list the source modules that may be required
-when building a system.
-The data bases are taken from the directory in which
-.I config
-is run, normally /sys/conf.
-Three such files may be used:
-.IR files ,
-.IR files .machine,
-and
-.IR files .ident.
-The first is common to all systems,
-the second contains files unique to a single machine type,
-and the third is an optional list of modules for use on a specific machine.
-This last file may override specifications in the first two.
-The format of the 
-.I files
-file has grown somewhat complex over time.  Entries are normally of
-the form
-.IP
-.nf
-.DT
-\fIdir/source.c\fP	\fItype\fP	 \fIoption-list\fP \fImodifiers\fP
-.LP
-for example,
-.IP
-.nf
-.DT
-\fIvaxuba/foo.c\fP	\fBoptional\fP	foo	\fBdevice-driver\fP
-.LP
-The
-.I type
-is one of
-.B standard
-or
-.BR optional .
-Files marked as standard are included in all system configurations.
-Optional file specifications include a list of one or more system
-options that together require the inclusion of this module.
-The options in the list may be either names of devices that may
-be in the configuration file,
-or the names of system options that may be defined.
-An optional file may be listed multiple times with different options;
-if all of the options for any of the entries are satisfied,
-the module is included.
-.PP
-If a file is specified as a
-.IR device-driver ,
-any special compilation options for device drivers will be invoked.
-On the VAX this results in the use of the
-.B \-i
-option for the C optimizer.  This is required when pointer references
-are made to memory locations in the VAX I/O address space.
-.PP
-Two other optional keywords modify the usage of the file.
-.I Config
-understands that certain files are used especially for
-kernel profiling.  These files are indicated in the
-.I files
-files with a 
-.I profiling-routine
-keyword.  For example, the current profiling subroutines
-are sequestered off in a separate file with the following
-entry:
-.IP
-.nf
-.DT
-\fIsys/subr_mcount.c\fP	\fBoptional\fP	\fBprofiling-routine\fP
-.fi
-.LP
-The 
-.I profiling-routine
-keyword forces
-.I config
-not to compile the source file with the 
-.B \-pg
-option.
-.PP
-The second keyword which can be of use is the
-.I config-dependent
-keyword.  This causes
-.I config
-to compile the indicated module with the global configuration
-parameters.  This allows certain modules, such as
-.I machdep.c
-to size system data structures based on the maximum number
-of users configured for the system.
-.NH 2
-Adding device drivers to 4.4BSD
-.PP
-The I/O system and
-.I config
-have been designed to easily allow new device support to be added.
-The system source directories are organized as follows:
-.DS
-.TS
-lw(1.0i) l.
-/sys/h	machine independent include files
-/sys/sys	machine-independent system source files
-/sys/conf	site configuration files and basic templates
-/sys/net	network-protocol-independent, but network-related code
-/sys/netinet	DARPA Internet code
-/sys/netimp	IMP support code
-/sys/netns	Xerox NS code
-/sys/vax	VAX-specific mainline code
-/sys/vaxif	VAX network interface code
-/sys/vaxmba	VAX MASSBUS device drivers and related code
-/sys/vaxuba	VAX UNIBUS device drivers and related code
-.TE
-.DE
-.PP
-Existing block and character device drivers for the VAX 
-reside in ``/sys/vax'', ``/sys/vaxmba'', and ``/sys/vaxuba''.  Network
-interface drivers reside in ``/sys/vaxif''.  Any new device
-drivers should be placed in the appropriate source code directory
-and named so as not to conflict with existing devices.
-Normally, definitions for things like device registers are placed in
-a separate file in the same directory.  For example, the ``dh''
-device driver is named ``dh.c'' and its associated include file is
-named ``dhreg.h''.
-.PP
-Once the source for the device driver has been placed in a directory,
-the file ``/sys/conf/files.machine'', and possibly
-``/sys/conf/devices.machine'' should be modified.  The 
-.I files
-files in the conf directory contain a line for each C source or binary-only
-file in the system.  Those files which are machine independent are
-located in ``/sys/conf/files,'' while machine specific files
-are in ``/sys/conf/files.machine.''  The ``devices.machine'' file
-is used to map device names to major block device numbers.  If the device
-driver being added provides support for a new disk
-you will want to modify this file (the format is obvious).
-.PP
-In addition to including the driver in the
-.I files
-file, it must also be added to the device configuration tables.  These
-are located in ``/sys/vax/conf.c'', or similar for machines other than
-the VAX.  If you don't understand what to add to this file, you should
-study an entry for an existing driver. 
-Remember that the position in the
-device table specifies the major device number.
-The block major number is needed in the ``devices.machine'' file
-if the device is a disk.
diff --git a/usr.sbin/config/SMM.doc/a.t b/usr.sbin/config/SMM.doc/a.t
deleted file mode 100644
index dfcb954..0000000
--- a/usr.sbin/config/SMM.doc/a.t
+++ /dev/null
@@ -1,162 +0,0 @@
-.\" Copyright (c) 1983, 1993
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\" 3. All advertising materials mentioning features or use of this software
-.\"    must display the following acknowledgement:
-.\"	This product includes software developed by the University of
-.\"	California, Berkeley and its contributors.
-.\" 4. Neither the name of the University nor the names of its contributors
-.\"    may be used to endorse or promote products derived from this software
-.\"    without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\"	@(#)a.t	8.1 (Berkeley) 6/8/93
-.\"
-.\".ds RH "Configuration File Grammar
-.bp
-.LG
-.B
-.ce
-APPENDIX A. CONFIGURATION FILE GRAMMAR
-.sp
-.R
-.NL
-.PP
-The following grammar is a compressed form of the actual
-\fIyacc\fP\|(1) grammar used by
-.I config
-to parse configuration files.
-Terminal symbols are shown all in upper case, literals
-are emboldened; optional clauses are enclosed in brackets, ``[''
-and ``]'';  zero or more instantiations are denoted with ``*''.
-.sp
-.nf
-.DT
-Configuration ::=  [ Spec \fB;\fP ]*
-
-Spec ::= Config_spec
-	| Device_spec
-	| \fBtrace\fP
-	| /* lambda */
-
-/* configuration specifications */
-
-Config_spec ::=  \fBmachine\fP ID
-	| \fBcpu\fP ID
-	| \fBoptions\fP Opt_list
-	| \fBident\fP ID
-	| System_spec
-	| \fBtimezone\fP [ \fB\-\fP ] NUMBER [ \fBdst\fP [ NUMBER ] ]
-	| \fBtimezone\fP [ \fB\-\fP ] FPNUMBER [ \fBdst\fP [ NUMBER ] ]
-	| \fBmaxusers\fP NUMBER
-
-/* system configuration specifications */
-
-System_spec ::= \fBconfig\fP ID System_parameter [ System_parameter ]*
-
-System_parameter ::=  swap_spec | root_spec | dump_spec | arg_spec
-
-swap_spec ::=  \fBswap\fP [ \fBon\fP ] swap_dev [ \fBand\fP swap_dev ]*
-
-swap_dev ::=  dev_spec [ \fBsize\fP NUMBER ]
-
-root_spec ::=  \fBroot\fP [ \fBon\fP ] dev_spec
-
-dump_spec ::=  \fBdumps\fP [ \fBon\fP ] dev_spec
-
-arg_spec ::=  \fBargs\fP [ \fBon\fP ] dev_spec
-
-dev_spec ::=  dev_name | major_minor
-
-major_minor ::=  \fBmajor\fP NUMBER \fBminor\fP NUMBER
-
-dev_name ::=  ID [ NUMBER [ ID ] ]
-
-/* option specifications */
-
-Opt_list ::=  Option [ \fB,\fP Option ]*
-
-Option ::=  ID [ \fB=\fP Opt_value ]
-
-Opt_value ::=  ID | NUMBER
-
-Mkopt_list ::=  Mkoption [ \fB,\fP Mkoption ]*
-
-Mkoption ::=  ID \fB=\fP Opt_value
-
-/* device specifications */
-
-Device_spec ::= \fBdevice\fP Dev_name Dev_info Int_spec
-	| \fBmaster\fP Dev_name Dev_info
-	| \fBdisk\fP Dev_name Dev_info
-	| \fBtape\fP Dev_name Dev_info
-	| \fBcontroller\fP Dev_name Dev_info [ Int_spec ]
-	| \fBpseudo-device\fP Dev [ NUMBER ]
-
-Dev_name ::=  Dev NUMBER
-
-Dev ::=  \fBuba\fP | \fBmba\fP | ID
-
-Dev_info ::=  Con_info [ Info ]*
-
-Con_info ::=  \fBat\fP Dev NUMBER
-	| \fBat\fP \fBnexus\fP NUMBER
-
-Info ::=  \fBcsr\fP NUMBER
-	| \fBdrive\fP NUMBER
-	| \fBslave\fP NUMBER
-	| \fBflags\fP NUMBER
-
-Int_spec ::=  \fBvector\fP ID [ ID ]*
-	| \fBpriority\fP NUMBER
-.fi
-.sp
-.SH
-Lexical Conventions
-.LP
-The terminal symbols are loosely defined as:
-.IP ID
-.br
-One or more alphabetics, either upper or lower case, and underscore,
-``_''.
-.IP NUMBER
-.br
-Approximately the C language specification for an integer number.
-That is, a leading ``0x'' indicates a hexadecimal value,
-a leading ``0'' indicates an octal value, otherwise the number is
-expected to be a decimal value.  Hexadecimal numbers may use either
-upper or lower case alphabetics.
-.IP FPNUMBER
-.br
-A floating point number without exponent.  That is a number of the
-form ``nnn.ddd'', where the fractional component is optional.
-.LP
-In special instances a question mark, ``?'', can be substituted for
-a ``NUMBER'' token.  This is used to effect wildcarding in device
-interconnection specifications.
-.LP
-Comments in configuration files are indicated by a ``#'' character
-at the beginning of the line; the remainder of the line is discarded.
-.LP
-A specification
-is interpreted as a continuation of the previous line
-if the first character of the line is tab.
diff --git a/usr.sbin/config/SMM.doc/b.t b/usr.sbin/config/SMM.doc/b.t
deleted file mode 100644
index 901a009..0000000
--- a/usr.sbin/config/SMM.doc/b.t
+++ /dev/null
@@ -1,137 +0,0 @@
-.\" Copyright (c) 1983, 1993
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\" 3. All advertising materials mentioning features or use of this software
-.\"    must display the following acknowledgement:
-.\"	This product includes software developed by the University of
-.\"	California, Berkeley and its contributors.
-.\" 4. Neither the name of the University nor the names of its contributors
-.\"    may be used to endorse or promote products derived from this software
-.\"    without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\"	@(#)b.t	8.1 (Berkeley) 6/8/93
-.\"
-.\".ds RH "Device Defaulting Rules
-.bp
-.LG
-.B
-.ce
-APPENDIX B. RULES FOR DEFAULTING SYSTEM DEVICES
-.sp
-.R
-.NL
-.PP
-When \fIconfig\fP processes a ``config'' rule which does
-not fully specify the location of the root file system,
-paging area(s), device for system dumps, and device for
-argument list processing it applies a set of rules to
-define those values left unspecified.  The following list
-of rules are used in defaulting system devices.
-.IP 1) 3
-If a root device is not specified, the swap
-specification must indicate a ``generic'' system is to be built.
-.IP 2) 3
-If the root device does not specify a unit number, it
-defaults to unit 0.
-.IP 3) 3
-If the root device does not include a partition specification,
-it defaults to the ``a'' partition.
-.IP 4) 3
-If no swap area is specified, it defaults to the ``b''
-partition of the root device.
-.IP 5) 3
-If no device is specified for processing argument lists, the
-first swap partition is selected.
-.IP 6) 3
-If no device is chosen for system dumps, the first swap
-partition is selected (see below to find out where dumps are
-placed within the partition).
-.PP
-The following table summarizes the default partitions selected
-when a device specification is incomplete, e.g. ``hp0''.
-.DS
-.TS
-l l.
-Type	Partition
-_
-root	``a''
-swap	``b''
-args	``b''
-dumps	``b''
-.TE
-.DE
-.SH
-Multiple swap/paging areas
-.PP
-When multiple swap partitions are specified, the system treats the
-first specified as a ``primary'' swap area which is always used.
-The remaining partitions are then interleaved into the paging
-system at the time a
-.IR swapon (2)
-system call is made.  This is normally done at boot time with
-a call to
-.IR swapon (8)
-from the /etc/rc file.
-.SH
-System dumps
-.PP
-System dumps are automatically taken after a system crash,
-provided the device driver for the ``dumps'' device supports
-this.  The dump contains the contents of memory, but not
-the swap areas.  Normally the dump device is a disk in
-which case the information is copied to a location at the
-back of the partition.  The dump is placed in the back of the
-partition because the primary swap and dump device are commonly
-the same device and this allows the system to be rebooted without
-immediately overwriting the saved information.  When a dump has
-occurred, the system variable \fIdumpsize\fP 
-is set to a non-zero value indicating the size (in bytes) of
-the dump.  The \fIsavecore\fP\|(8)
-program then copies the information from the dump partition to
-a file in a ``crash'' directory and also makes a copy of the
-system which was running at the time of the crash (usually
-``/kernel'').  The offset to the system dump is defined in the
-system variable \fIdumplo\fP (a sector offset from
-the front of the dump partition). The 
-.I savecore
-program operates by reading the contents of \fIdumplo\fP, \fIdumpdev\fP,
-and \fIdumpmagic\fP from /dev/kmem, then comparing the value
-of \fIdumpmagic\fP read from /dev/kmem to that located in
-corresponding location in the dump area of the dump partition.
-If a match is found, 
-.I savecore
-assumes a crash occurred and reads \fIdumpsize\fP from the dump area
-of the dump partition.  This value is then used in copying the
-system dump.  Refer to 
-\fIsavecore\fP\|(8)
-for more information about its operation.
-.PP
-The value \fIdumplo\fP is calculated to be 
-.DS
-\fIdumpdev-size\fP \- \fImemsize\fP
-.DE
-where \fIdumpdev-size\fP is the size of the disk partition
-where system dumps are to be placed, and
-\fImemsize\fP is the size of physical memory.
-If the disk partition is not large enough to hold a full
-dump, \fIdumplo\fP is set to 0 (the start of the partition).
diff --git a/usr.sbin/config/SMM.doc/c.t b/usr.sbin/config/SMM.doc/c.t
deleted file mode 100644
index 67b63ec..0000000
--- a/usr.sbin/config/SMM.doc/c.t
+++ /dev/null
@@ -1,109 +0,0 @@
-.\" Copyright (c) 1983, 1993
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\" 3. All advertising materials mentioning features or use of this software
-.\"    must display the following acknowledgement:
-.\"	This product includes software developed by the University of
-.\"	California, Berkeley and its contributors.
-.\" 4. Neither the name of the University nor the names of its contributors
-.\"    may be used to endorse or promote products derived from this software
-.\"    without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\"	@(#)c.t	8.1 (Berkeley) 6/8/93
-.\"
-.\".ds RH "Sample Config Files
-.bp
-.LG
-.B
-.ce
-APPENDIX C. SAMPLE CONFIGURATION FILES
-.sp
-.R
-.NL
-.PP
-The following configuration files are developed in section 5;
-they are included here for completeness.
-.sp 2
-.nf
-.ta 1.5i 2.5i 4.0i
-#
-# ANSEL VAX (a picture perfect machine)
-#
-machine	vax
-cpu	VAX780
-timezone	8 dst
-ident	ANSEL
-maxusers	40
-
-config	kernel	root on hp0
-config	hpkernel	root on hp0 swap on hp0 and hp2
-config	genkernel	swap generic
-
-controller	mba0	at nexus ?
-disk	hp0	at mba? disk ?
-disk	hp1	at mba? disk ?
-controller	mba1	at nexus ?
-disk	hp2	at mba? disk ?
-disk	hp3	at mba? disk ?
-controller	uba0	at nexus ?
-controller	tm0	at uba? csr 0172520	vector tmintr
-tape	te0	at tm0 drive 0
-tape	te1	at tm0 drive 1
-device	dh0	at uba? csr 0160020	vector dhrint dhxint
-device	dm0	at uba? csr 0170500	vector dmintr
-device	dh1	at uba? csr 0160040	vector dhrint dhxint
-device	dh2	at uba? csr 0160060	vector dhrint dhxint
-.bp
-#
-# UCBVAX - Gateway to the world
-#
-machine	vax
-cpu	"VAX780"
-cpu	"VAX750"
-ident	UCBVAX
-timezone	8 dst
-maxusers	32
-options	INET
-options	NS
-
-config	kernel	root on hp swap on hp and rk0 and rk1
-config	upkernel	root on up
-config	hkkernel	root on hk swap on rk0 and rk1
-
-controller	mba0	at nexus ?
-controller	uba0	at nexus ?
-disk	hp0	at mba? drive 0
-disk	hp1	at mba? drive 1
-controller	sc0	at uba? csr 0176700	vector upintr
-disk	up0	at sc0 drive 0
-disk	up1	at sc0 drive 1
-controller	hk0	at uba? csr 0177440	vector rkintr
-disk	rk0	at hk0 drive 0
-disk	rk1	at hk0 drive 1
-pseudo-device	pty
-pseudo-device	loop
-pseudo-device	imp
-device	acc0	at uba? csr 0167600	vector accrint accxint
-pseudo-device	ether
-device	ec0	at uba? csr 0164330	vector ecrint eccollide ecxint
-device	il0	at uba? csr 0164000	vector ilrint ilcint
diff --git a/usr.sbin/config/SMM.doc/d.t b/usr.sbin/config/SMM.doc/d.t
deleted file mode 100644
index db9ab80..0000000
--- a/usr.sbin/config/SMM.doc/d.t
+++ /dev/null
@@ -1,272 +0,0 @@
-.\" Copyright (c) 1983, 1993
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\" 3. All advertising materials mentioning features or use of this software
-.\"    must display the following acknowledgement:
-.\"	This product includes software developed by the University of
-.\"	California, Berkeley and its contributors.
-.\" 4. Neither the name of the University nor the names of its contributors
-.\"    may be used to endorse or promote products derived from this software
-.\"    without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\"	@(#)d.t	8.1 (Berkeley) 6/8/93
-.\"
-.\".ds RH "Data Structure Sizing Rules
-.bp
-.LG
-.B
-.ce
-APPENDIX D. VAX KERNEL DATA STRUCTURE SIZING RULES
-.sp
-.R
-.NL
-.PP
-Certain system data structures are sized at compile time
-according to the maximum number of simultaneous users expected,
-while others are calculated at boot time based on the
-physical resources present, e.g. memory.  This appendix lists
-both sets of rules and also includes some hints on changing
-built-in limitations on certain data structures.
-.SH
-Compile time rules
-.PP
-The file \fI/sys/conf\|/param.c\fP contains the definitions of
-almost all data structures sized at compile time.  This file
-is copied into the directory of each configured system to allow
-configuration-dependent rules and values to be maintained.
-(Each copy normally depends on the copy in /sys/conf,
-and global modifications cause the file to be recopied unless
-the makefile is modified.)
-The rules implied by its contents are summarized below (here
-MAXUSERS refers to the value defined in the configuration file
-in the ``maxusers'' rule).
-Most limits are computed at compile time and stored in global variables
-for use by other modules; they may generally be patched in the system
-binary image before rebooting to test new values.
-.IP \fBnproc\fP
-.br
-The maximum number of processes which may be running at any time.
-It is referred to in other calculations as NPROC and is defined to be
-.DS
-20 + 8 * MAXUSERS
-.DE
-.IP \fBntext\fP
-.br
-The maximum number of active shared text segments.
-The constant is intended to allow for network servers and common commands
-that remain in the table.
-It is defined as
-.DS
-36 + MAXUSERS.
-.DE
-.IP \fBninode\fP
-.br
-The maximum number of files in the file system which may be
-active at any time.  This includes files in use by users, as 
-well as directory files being read or written by the system
-and files associated with bound sockets in the UNIX IPC domain.
-It is defined as
-.DS
-(NPROC + 16 + MAXUSERS) + 32
-.DE
-.IP \fBnfile\fP
-.br
-The number of ``file table'' structures.  One file
-table structure is used for each open, unshared, file descriptor.
-Multiple file descriptors may reference a single file table
-entry when they are created through a \fIdup\fP call, or as the
-result of a \fIfork\fP.  This is defined to be
-.DS
-16 * (NPROC + 16 + MAXUSERS) / 10 + 32
-.DE
-.IP \fBncallout\fP
-.br
-The number of ``callout'' structures.  One callout
-structure is used per internal system event handled with
-a timeout.  Timeouts are used for terminal delays,
-watchdog routines in device drivers, protocol timeout processing, etc.
-This is defined as
-.DS
-16 + NPROC
-.DE
-.IP \fBnclist\fP
-.br
-The number of ``c-list'' structures.  C-list structures are
-used in terminal I/O, and currently each holds 60 characters.
-Their number is defined as
-.DS
-60 + 12 * MAXUSERS
-.DE
-.IP \fBnmbclusters\fP
-.br
-The maximum number of pages which may be allocated by the network.  
-This is defined as 256 (a quarter megabyte of memory) in /sys/h/mbuf.h.
-In practice, the network rarely uses this much memory.  It starts off
-by allocating 8 kilobytes of memory, then requesting more as 
-required.  This value represents an upper bound.
-.IP \fBnquota\fP
-.br
-The number of ``quota'' structures allocated.  Quota structures
-are present only when disc quotas are configured in the system.  One
-quota structure is kept per user.  This is defined to be
-.DS
-(MAXUSERS * 9) / 7 + 3
-.DE
-.IP \fBndquot\fP
-.br
-The number of ``dquot'' structures allocated.  Dquot structures
-are present only when disc quotas are configured in the system.
-One dquot structure is required per user, per active file system quota.
-That is, when a user manipulates a file on a file system on which
-quotas are enabled, the information regarding the user's quotas on
-that file system must be in-core.  This information is cached, so
-that not all information must be present in-core all the time.
-This is defined as
-.DS
-NINODE + (MAXUSERS * NMOUNT) / 4
-.DE
-where NMOUNT is the maximum number of mountable file systems.
-.LP
-In addition to the above values, the system page tables (used to
-map virtual memory in the kernel's address space) are sized at
-compile time by the SYSPTSIZE definition in the file /sys/vax/vmparam.h.
-This is defined to be
-.DS
-20 + MAXUSERS
-.DE
-pages of page tables. 
-Its definition affects
-the size of many data structures allocated at boot time because
-it constrains the amount of virtual memory which may be addressed
-by the running system.  This is often the limiting factor
-in the size of the buffer cache, in which case a message is printed
-when the system configures at boot time.
-.SH
-Run-time calculations
-.PP
-The most important data structures sized at run-time are those used in
-the buffer cache.  Allocation is done by allocating physical memory
-(and system virtual memory) immediately after the system
-has been started up; look in the file /sys/vax/machdep.c.
-The amount of physical memory which may be allocated to the buffer
-cache is constrained by the size of the system page tables, among
-other things.  While the system may calculate
-a large amount of memory to be allocated to the buffer cache,
-if the system page
-table is too small to map this physical
-memory into the virtual address space
-of the system, only as much as can be mapped will be used.
-.PP
-The buffer cache is comprised of a number of ``buffer headers''
-and a pool of pages attached to these headers.  Buffer headers
-are divided into two categories: those used for swapping and
-paging, and those used for normal file I/O.  The system tries
-to allocate 10% of the first two megabytes and 5% of the remaining
-available physical memory for the buffer
-cache (where \fIavailable\fP does not count that space occupied by
-the system's text and data segments).  If this results in fewer
-than 16 pages of memory allocated, then 16 pages are allocated.
-This value is kept in the initialized variable \fIbufpages\fP
-so that it may be patched in the binary image (to allow tuning
-without recompiling the system),
-or the default may be overridden with a configuration-file option.
-For example, the option \fBoptions BUFPAGES="3200"\fP
-causes 3200 pages (3.2M bytes) to be used by the buffer cache.
-A sufficient number of file I/O buffer headers are then allocated
-to allow each to hold 2 pages each.
-Each buffer maps 8K bytes.
-If the number of buffer pages is larger than can be mapped
-by the buffer headers, the number of pages is reduced.
-The number of buffer headers allocated
-is stored in the global variable \fInbuf\fP,
-which may be patched before the system is booted.
-The system option \fBoptions NBUF="1000"\fP forces the allocation
-of 1000 buffer headers.
-Half as many swap I/O buffer headers as file I/O buffers
-are allocated,
-but no more than 256.
-.SH
-System size limitations
-.PP
-As distributed, the sum of the virtual sizes of the core-resident
-processes is limited to 256M bytes.  The size of the text
-segment of a single process is currently limited to 6M bytes.
-It may be increased to no greater than the data segment size limit
-(see below) by redefining MAXTSIZ.
-This may be done with a configuration file option,
-e.g. \fBoptions MAXTSIZ="(10*1024*1024)"\fP
-to set the limit to 10 million bytes.
-Other per-process limits discussed here may be changed with similar options
-with names given in parentheses.
-Soft, user-changeable limits are set to 512K bytes for stack (DFLSSIZ)
-and 6M bytes for the data segment (DFLDSIZ) by default;
-these may be increased up to the hard limit
-with the \fIsetrlimit\fP\|(2) system call.
-The data and stack segment size hard limits are set by a system configuration
-option to one of 17M, 33M or 64M bytes.
-One of these sizes is chosen based on the definition of MAXDSIZ;
-with no option, the limit is 17M bytes; with an option
-\fBoptions MAXDSIZ="(32*1024*1024)"\fP (or any value between 17M and 33M),
-the limit is increased to 33M bytes, and values larger than 33M
-result in a limit of 64M bytes.
-You must be careful in doing this that you have adequate paging space.
-As normally configured , the system has 16M or 32M bytes per paging area,
-depending on disk size.
-The best way to get more space is to provide multiple, thereby
-interleaved, paging areas.
-Increasing the virtual memory limits results in interleaving of
-swap space in larger sections (from 500K bytes to 1M or 2M bytes).
-.PP
-By default, the virtual memory system allocates enough memory
-for system page tables mapping user page tables
-to allow 256 megabytes of simultaneous active virtual memory.
-That is, the sum of the virtual memory sizes of all (completely- or partially-)
-resident processes can not exceed this limit.
-If the limit is exceeded, some process(es) must be swapped out.
-To increase the amount of resident virtual space possible,
-you can alter the constant USRPTSIZE (in
-/sys/vax/vmparam.h).
-Each page of system page tables allows 8 megabytes of user virtual memory.
-.PP
-Because the file system block numbers are stored in
-page table \fIpg_blkno\fP
-entries, the maximum size of a file system is limited to
-2^24 1024 byte blocks.  Thus no file system can be larger than 8 gigabytes.
-.PP
-The number of mountable file systems is set at 20 by the definition
-of NMOUNT in /sys/h/param.h.
-This should be sufficient; if not, the value can be increased up to 255.
-If you have many disks, it makes sense to make some of
-them single file systems, and the paging areas don't count in this total.
-.PP
-The limit to the number of files that a process may have open simultaneously
-is set to 64.
-This limit is set by the NOFILE definition in /sys/h/param.h.
-It may be increased arbitrarily, with the caveat that the user structure
-expands by 5 bytes for each file, and thus UPAGES (/sys/vax/machparam.h)
-must be increased accordingly.
-.PP
-The amount of physical memory is currently limited to 64 Mb
-by the size of the index fields in the core-map (/sys/h/cmap.h).
-The limit may be increased by following instructions in that file
-to enlarge those fields.
diff --git a/usr.sbin/config/SMM.doc/e.t b/usr.sbin/config/SMM.doc/e.t
deleted file mode 100644
index 0a9505b..0000000
--- a/usr.sbin/config/SMM.doc/e.t
+++ /dev/null
@@ -1,114 +0,0 @@
-.\" Copyright (c) 1983, 1993
-.\"	The Regents of the University of California.  All rights reserved.
-.\"
-.\" Redistribution and use in source and binary forms, with or without
-.\" modification, are permitted provided that the following conditions
-.\" are met:
-.\" 1. Redistributions of source code must retain the above copyright
-.\"    notice, this list of conditions and the following disclaimer.
-.\" 2. Redistributions in binary form must reproduce the above copyright
-.\"    notice, this list of conditions and the following disclaimer in the
-.\"    documentation and/or other materials provided with the distribution.
-.\" 3. All advertising materials mentioning features or use of this software
-.\"    must display the following acknowledgement:
-.\"	This product includes software developed by the University of
-.\"	California, Berkeley and its contributors.
-.\" 4. Neither the name of the University nor the names of its contributors
-.\"    may be used to endorse or promote products derived from this software
-.\"    without specific prior written permission.
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-.\" SUCH DAMAGE.
-.\"
-.\"	@(#)e.t	8.1 (Berkeley) 6/8/93
-.\"
-.\".ds RH "Network configuration options
-.bp
-.LG
-.B
-.ce
-APPENDIX E. NETWORK CONFIGURATION OPTIONS
-.sp
-.R
-.NL
-.PP
-The network support in the kernel is self-configuring
-according to the protocol support options (INET and NS) and the network
-hardware discovered during autoconfiguration.
-There are several changes that may be made to customize network behavior
-due to local restrictions.
-Within the Internet protocol routines, the following options
-set in the system configuration file are supported:
-.IP \fBGATEWAY\fP
-.br
-The machine is to be used as a gateway.
-This option currently makes only minor changes.
-First, the size of the network routing hash table is increased.
-Secondly, machines that have only a single hardware network interface
-will not forward IP packets; without this option, they will also refrain
-from sending any error indication to the source of unforwardable packets.
-Gateways with only a single interface are assumed to have missing
-or broken interfaces, and will return ICMP unreachable errors to hosts
-sending them packets to be forwarded.
-.IP \fBTCP_COMPAT_42\fP
-.br
-This option forces the system to limit its initial TCP sequence numbers
-to positive numbers.
-Without this option, 4.4BSD systems may have problems with TCP connections
-to 4.2BSD systems that connect but never transfer data.
-The problem is a bug in the 4.2BSD TCP.
-.IP \fBIPFORWARDING\fP
-.br
-Normally, 4.4BSD machines with multiple network interfaces
-will forward IP packets received that should be resent to another host.
-If the line ``options IPFORWARDING="0"'' is in the system configuration
-file, IP packet forwarding will be disabled.
-.IP \fBIPSENDREDIRECTS\fP
-.br
-When forwarding IP packets, 4.4BSD IP will note when a packet is forwarded
-using the same interface on which it arrived.
-When this is noted, if the source machine is on the directly-attached
-network, an ICMP redirect is sent to the source host.
-If the packet was forwarded using a route to a host or to a subnet,
-a host redirect is sent, otherwise a network redirect is sent.
-The generation of redirects may be inhibited with the configuration
-option ``options IPSENDREDIRECTS="0".''
-.br
-.IP \fBSUBNETSARELOCAL\fP
-TCP calculates a maximum segment size to use for each connection,
-and sends no datagrams larger than that size.
-This size will be no larger than that supported on the outgoing
-interface.
-Furthermore, if the destination is not on the local network,
-the size will be no larger than 576 bytes.
-For this test, other subnets of a directly-connected subnetted
-network are considered to be local unless the line
-``options SUBNETSARELOCAL="0"'' is used in the system configuration file.
-.LP
-The following options are supported by the Xerox NS protocols:
-.IP \fBNSIP\fP
-.br
-This option allows NS IDP datagrams to be encapsulated in Internet IP
-packets for transmission to a collaborating NSIP host.
-This may be used to pass IDP packets through IP-only link layer networks.
-See
-.IR nsip (4P)
-for details.
-.IP \fBTHREEWAYSHAKE\fP
-.br
-The NS Sequenced Packet Protocol does not require a three-way handshake
-before considering a connection to be in the established state.
-(A three-way handshake consists of a connection request, an acknowledgement
-of the request along with a symmetrical opening indication,
-and then an acknowledgement of the reciprocal opening packet.)
-This option forces a three-way handshake before data may be transmitted
-on Sequenced Packet sockets.
diff --git a/usr.sbin/config/SMM.doc/spell.ok b/usr.sbin/config/SMM.doc/spell.ok
deleted file mode 100644
index dfc5df1..0000000
--- a/usr.sbin/config/SMM.doc/spell.ok
+++ /dev/null
@@ -1,305 +0,0 @@
-# $FreeBSD$
-ACC
-ANSEL
-ARP
-Autoconfiguration
-BUFPAGES
-CANTWAIT
-CH
-COMPAT
-CSS
-Co
-Config
-Config''SMM:2
-DCLR
-DFLDSIZ
-DFLSSIZ
-DFUNNY
-DHAHA
-DMA
-Dev
-Dquot
-ECC
-EMULEX
-Emulex
-Ethernet
-FPNUMBER
-FUNNY,HAHA
-HAVEBDP
-ICMP
-IDP
-IE
-INET
-IP
-IPC
-IPFORWARDING
-IPL
-IPSENDREDIRECTS
-Info
-Karels
-LH
-Leffler
-MASSBUS
-MAXDSIZ
-MAXTSIZ
-Makefile
-Mb
-MicroVAX
-Mkopt
-Mkoption
-NBUF
-NEED16
-NEEDBDP
-NINODE
-NMOUNT
-NOFILE
-NPROC
-NS
-NSC
-NSIP
-NUP
-PST
-RCS
-RDY
-RH
-RK07
-RK611
-SCCS
-SITENAME
-SMM:2
-SUBNETSARELOCAL
-SYSPTSIZE
-TCP
-THREEWAYSHAKE
-Timezone
-UCBVAX
-UDP
-UNIBUS
-UPAGES
-UPCS2
-USRPTSIZE
-VAX
-VAX630
-VAX730
-VAX750
-VAX780
-VAX8600
-VAXWELL
-VAXen
-Vax
-Vaxwell
-acc0
-accrint
-accxint
-addr
-arg
-args
-assym.s
-autoconfiguration
-autoconfigure
-autoconfigured
-backpointer
-badaddr
-blkno
-br
-br5
-buf
-bufpages
-buses
-caddr
-callout
-catchall
-cmap.h
-cmd
-conf
-conf.c
-config
-csr
-ct.c
-ctlr
-cvec
-datagrams
-define''s
-dev
-devices.machine
-dgo
-dh.c
-dh0
-dh1
-dh2
-dhreg.h
-dhrint
-dhxint
-dinfo
-dk
-dk.h
-dm0
-dmintr
-dname
-dquot
-dst
-dumpdev
-dumplo
-dumpmagic
-dumpsize
-dz.c
-dz0
-dzrint
-dzxint
-ec0
-eccollide
-ecrint
-ecxint
-endif
-es
-files.machine
-filesystem
-foo
-foo.c
-genkernel
-gettimeofday
-gigabytes
-gprof
-hardwired
-hd
-hk
-hk0
-hkkernel
-howmany
-hp0
-hp0b
-hp1
-hp2
-hp3
-hpkernel
-ht0
-hz
-ident
-ifdef
-ifndef
-il0
-ilcint
-ilrint
-info
-intr
-ioconf.c
-kgmon
-linterrs
-loopback
-machdep.c
-machparam.h
-makefile
-makelinks
-makeoptions
-maxusers
-mba
-mba0
-mba1
-mbuf.h
-mcount.c
-memsize
-minfo
-mname
-moniker
-mspw
-nbuf
-ncallout
-nclist
-ndquot
-ndrive
-netimp
-netinet
-netns
-netstat
-nexi
-nexus
-nfile
-ninode
-nmbclusters
-nnn.ddd
-nproc
-nquota
-nsip
-ntext
-optionlist
-param.c
-param.h
-pathnames
-pg
-physaddr
-pty
-rc
-reg
-rk.c
-rk0
-rk1
-rkintr
-savecore
-sc
-sc0
-sc1
-scdriver
-setrlimit
-sizeof
-softc
-source.c
-subr
-swapxxx.c
-sysname
-te0
-te1
-timezone
-tm0
-tmintr
-tu0
-uba
-uba.c
-uba0
-ubago
-uballoc
-ubamem
-ubanum
-ubareg.h
-ubarelse
-ubavar.h
-ubglue.s
-ubinfo
-ud
-ui
-um
-up.c
-up0
-up1
-up2
-upaddr
-upattach
-upba
-upcs1
-upcs2
-updevice
-updgo
-updinfo
-updtab
-upintr
-upip
-upmaptype
-upminfo
-upprobe
-upslave
-upstd
-upkernel
-upwatch
-upwstart
-value,name2
-value2
-vax
-vaxif
-vaxmba
-vaxuba
-vmparam.h
-kernel
-wildcard
-wildcarded
-wildcarding
-xclu
-xxx