diff options
Diffstat (limited to 'usr.sbin/config')
-rw-r--r-- | usr.sbin/config/SMM.doc/0.t | 88 | ||||
-rw-r--r-- | usr.sbin/config/SMM.doc/1.t | 61 | ||||
-rw-r--r-- | usr.sbin/config/SMM.doc/2.t | 188 | ||||
-rw-r--r-- | usr.sbin/config/SMM.doc/3.t | 299 | ||||
-rw-r--r-- | usr.sbin/config/SMM.doc/4.t | 442 | ||||
-rw-r--r-- | usr.sbin/config/SMM.doc/5.t | 271 | ||||
-rw-r--r-- | usr.sbin/config/SMM.doc/6.t | 233 | ||||
-rw-r--r-- | usr.sbin/config/SMM.doc/a.t | 162 | ||||
-rw-r--r-- | usr.sbin/config/SMM.doc/b.t | 137 | ||||
-rw-r--r-- | usr.sbin/config/SMM.doc/c.t | 109 | ||||
-rw-r--r-- | usr.sbin/config/SMM.doc/d.t | 272 | ||||
-rw-r--r-- | usr.sbin/config/SMM.doc/e.t | 114 | ||||
-rw-r--r-- | usr.sbin/config/SMM.doc/spell.ok | 305 |
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 |