diff options
Diffstat (limited to 'usr.sbin/config/SMM.doc')
| -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 | 239 | ||||
| -rw-r--r-- | usr.sbin/config/SMM.doc/Makefile | 10 | ||||
| -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 | 306 |
14 files changed, 2698 insertions, 0 deletions
diff --git a/usr.sbin/config/SMM.doc/0.t b/usr.sbin/config/SMM.doc/0.t new file mode 100644 index 0000000..ae5bf77 --- /dev/null +++ b/usr.sbin/config/SMM.doc/0.t @@ -0,0 +1,88 @@ +.\" 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 new file mode 100644 index 0000000..453041b --- /dev/null +++ b/usr.sbin/config/SMM.doc/1.t @@ -0,0 +1,61 @@ +.\" 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 new file mode 100644 index 0000000..34e6b63 --- /dev/null +++ b/usr.sbin/config/SMM.doc/2.t @@ -0,0 +1,188 @@ +.\" 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 new file mode 100644 index 0000000..cbb904f --- /dev/null +++ b/usr.sbin/config/SMM.doc/3.t @@ -0,0 +1,299 @@ +.\" 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 ``vmunix'', +then ``make vmunix'' +will generate a bootable image named ``vmunix''. 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 ``vmunix'' to be a system with the root file +system on an ``hp'' device and ``hkvmunix'' to be a system with the root +file system on an ``hk'' device, then ``make vmunix hkvmunix'' 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 ``/vmunix''. If you install +a new system and name it something other than ``/vmunix'', 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 new file mode 100644 index 0000000..d267799 --- /dev/null +++ b/usr.sbin/config/SMM.doc/4.t @@ -0,0 +1,442 @@ +.\" 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 ``vmunix''. 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 vmunix \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 vmunix \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 new file mode 100644 index 0000000..3a0f449 --- /dev/null +++ b/usr.sbin/config/SMM.doc/5.t @@ -0,0 +1,271 @@ +.\" 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 vmunix root on hp0 +config hpvmunix root on hp0 swap on hp0 and hp2 +config genvmunix 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 vmunix root on hp swap on hp and rk0 and rk1 +config upvmunix root on up +config hkvmunix 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 new file mode 100644 index 0000000..f02baed --- /dev/null +++ b/usr.sbin/config/SMM.doc/6.t @@ -0,0 +1,239 @@ +.\" 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 +.\" +.\".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. +.PP +With the configuration information in place, your configuration +file appropriately modified, and a system reconfigured and rebooted +you should incorporate the shell commands needed to install the special +files in the file system to the file ``/dev/MAKEDEV'' or +``/dev/MAKEDEV.local''. This is discussed in the document ``Installing +and Operating 4.4BSD''. diff --git a/usr.sbin/config/SMM.doc/Makefile b/usr.sbin/config/SMM.doc/Makefile new file mode 100644 index 0000000..3a2f188 --- /dev/null +++ b/usr.sbin/config/SMM.doc/Makefile @@ -0,0 +1,10 @@ +# @(#)Makefile 8.1 (Berkeley) 6/8/93 + +DIR= smm/02.config +SRCS= 0.t 1.t 2.t 3.t 4.t 5.t 6.t a.t b.t c.t d.t e.t +MACROS= -ms + +paper.ps: ${SRCS} + ${TBL} ${SRCS} | ${ROFF} > ${.TARGET} + +.include <bsd.doc.mk> diff --git a/usr.sbin/config/SMM.doc/a.t b/usr.sbin/config/SMM.doc/a.t new file mode 100644 index 0000000..dfcb954 --- /dev/null +++ b/usr.sbin/config/SMM.doc/a.t @@ -0,0 +1,162 @@ +.\" 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 new file mode 100644 index 0000000..7281610 --- /dev/null +++ b/usr.sbin/config/SMM.doc/b.t @@ -0,0 +1,137 @@ +.\" 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 +``/vmunix''). 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 new file mode 100644 index 0000000..0f28fda --- /dev/null +++ b/usr.sbin/config/SMM.doc/c.t @@ -0,0 +1,109 @@ +.\" 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 vmunix root on hp0 +config hpvmunix root on hp0 swap on hp0 and hp2 +config genvmunix 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 vmunix root on hp swap on hp and rk0 and rk1 +config upvmunix root on up +config hkvmunix 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 new file mode 100644 index 0000000..db9ab80 --- /dev/null +++ b/usr.sbin/config/SMM.doc/d.t @@ -0,0 +1,272 @@ +.\" 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 new file mode 100644 index 0000000..0a9505b --- /dev/null +++ b/usr.sbin/config/SMM.doc/e.t @@ -0,0 +1,114 @@ +.\" 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 new file mode 100644 index 0000000..4132452 --- /dev/null +++ b/usr.sbin/config/SMM.doc/spell.ok @@ -0,0 +1,306 @@ +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 +MAKEDEV +MAKEDEV.local +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 +genvmunix +gettimeofday +gigabytes +gprof +hardwired +hd +hk +hk0 +hkvmunix +howmany +hp0 +hp0b +hp1 +hp2 +hp3 +hpvmunix +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 +upvmunix +upwatch +upwstart +value,name2 +value2 +vax +vaxif +vaxmba +vaxuba +vmparam.h +vmunix +wildcard +wildcarded +wildcarding +xclu +xxx |
