share/doc/smm/02.config/2.t

   1 .\" Copyright (c) 1983, 1993
   2 .\"     The Regents of the University of California.  All rights reserved.
   3 .\"
   4 .\" Redistribution and use in source and binary forms, with or without
   5 .\" modification, are permitted provided that the following conditions
   6 .\" are met:
   7 .\" 1. Redistributions of source code must retain the above copyright
   8 .\"    notice, this list of conditions and the following disclaimer.
   9 .\" 2. Redistributions in binary form must reproduce the above copyright
  10 .\"    notice, this list of conditions and the following disclaimer in the
  11 .\"    documentation and/or other materials provided with the distribution.
  12 .\" 3. Neither the name of the University nor the names of its contributors
  13 .\"    may be used to endorse or promote products derived from this software
  14 .\"    without specific prior written permission.
  15 .\"
  16 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
  17 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  18 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  19 .\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
  20 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  21 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  22 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  23 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  24 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  25 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  26 .\" SUCH DAMAGE.
  27 .\"
  28 .\"     @(#)2.t 8.1 (Berkeley) 6/8/93
  29 .\"
  30 .\".ds RH "Configuration File Contents
  31 .ne 2i
  32 .NH
  33 CONFIGURATION FILE CONTENTS
  34 .PP
  35 A system configuration must include at least the following
  36 pieces of information:
  37 .IP \(bu 3
  38 machine type
  39 .IP \(bu 3
  40 cpu type
  41 .IP \(bu 3
  42 system identification
  43 .IP \(bu 3
  44 timezone
  45 .IP \(bu 3
  46 maximum number of users
  47 .IP \(bu 3
  48 location of the root file system
  49 .IP \(bu 3
  50 available hardware
  51 .PP
  52 .I Config
  53 allows multiple system images to be generated from a single
  54 configuration description.  Each system image is configured
  55 for identical hardware, but may have different locations for the root
  56 file system and, possibly, other system devices.
  57 .NH 2
  58 Machine type
  59 .PP
  60 The
  61 .I "machine type"
  62 indicates if the system is going to operate on a DEC VAX-11\(dg computer,
  63 .FS
  64 \(dg DEC, VAX, UNIBUS, MASSBUS and MicroVAX are trademarks of Digital
  65 Equipment Corporation.
  66 .FE
  67 or some other machine on which 4.4BSD operates.  The machine type
  68 is used to locate certain data files which are machine specific, and
  69 also to select rules used in constructing the resultant
  70 configuration files.
  71 .NH 2
  72 Cpu type
  73 .PP
  74 The
  75 .I "cpu type"
  76 indicates which, of possibly many, cpu's the system is to operate on.
  77 For example, if the system is being configured for a VAX-11, it could
  78 be running on a VAX 8600, VAX-11/780, VAX-11/750, VAX-11/730 or MicroVAX II.
  79 (Other VAX cpu types, including the 8650, 785 and 725, are configured using
  80 the cpu designation for compatible machines introduced earlier.)
  81 Specifying
  82 more than one cpu type implies that the system should be configured to run
  83 on any of the cpu's specified.  For some types of machines this is not
  84 possible and
  85 .I config
  86 will print a diagnostic indicating such.
  87 .NH 2
  88 System identification
  89 .PP
  90 The
  91 .I "system identification"
  92 is a moniker attached to the system, and often the machine on which the
  93 system is to run.  For example, at Berkeley we have machines named Ernie
  94 (Co-VAX), Kim (No-VAX), and so on.  The system identifier selected is used to
  95 create a global C ``#define'' which may be used to isolate system dependent
  96 pieces of code in the kernel.  For example, Ernie's Varian driver used
  97 to be special cased because its interrupt vectors were wired together.  The
  98 code in the driver which understood how to handle this non-standard hardware
  99 configuration was conditionally compiled in only if the system
 100 was for Ernie.
 101 .PP
 102 The system identifier ``GENERIC'' is given to a system which
 103 will run on any cpu of a particular machine type; it should not
 104 otherwise be used for a system identifier.
 105 .NH 2
 106 Timezone
 107 .PP
 108 The timezone in which the system is to run is used to define the
 109 information returned by the \fIgettimeofday\fP\|(2)
 110 system call.  This value is specified as the number of hours east
 111 or west of GMT.  Negative numbers indicate a value east of GMT.
 112 The timezone specification may also indicate the
 113 type of daylight savings time rules to be applied.
 114 .NH 2
 115 Maximum number of users
 116 .PP
 117 The system allocates many system data structures at boot time
 118 based on the maximum number of users the system will support.
 119 This number is normally between 8 and 40, depending
 120 on the hardware and expected job mix.  The rules
 121 used to calculate system data structures are discussed in
 122 Appendix D.
 123 .NH 2
 124 Root file system location
 125 .PP
 126 When the system boots it must know the location of
 127 the root of the file system
 128 tree.  This location and the part(s) of the disk(s) to be used
 129 for paging and swapping must be specified in order to create
 130 a complete configuration description.
 131 .I Config
 132 uses many rules to calculate default locations for these items;
 133 these are described in Appendix B.
 134 .PP
 135 When a generic system is configured, the root file system is left
 136 undefined until the system is booted.  In this case, the root file
 137 system need not be specified, only that the system is a generic system.
 138 .NH 2
 139 Hardware devices
 140 .PP
 141 When the system boots it goes through an
 142 .I autoconfiguration
 143 phase.  During this period, the system searches for all
 144 those hardware devices
 145 which the system builder has indicated might be present.  This probing
 146 sequence requires certain pieces of information such as register
 147 addresses, bus interconnects, etc.  A system's hardware may be configured
 148 in a very flexible manner or be specified without any flexibility
 149 whatsoever.  Most people do not configure hardware devices into the
 150 system unless they are currently present on the machine, expect
 151 them to be present in the near future, or are simply guarding
 152 against a hardware
 153 failure somewhere else at the site (it is often wise to configure in
 154 extra disks in case an emergency requires moving one off a machine which
 155 has hardware problems).
 156 .PP
 157 The specification of hardware devices usually occupies the majority of
 158 the configuration file.  As such, a large portion of this document will
 159 be spent understanding it.  Section 6.3 contains a description of
 160 the autoconfiguration process, as it applies to those planning to
 161 write, or modify existing, device drivers.
 162 .NH 2
 163 Pseudo devices
 164 .PP
 165 Several system facilities are configured in a manner like that used
 166 for hardware devices although they are not associated with specific hardware.
 167 These system options are configured as
 168 .IR pseudo-devices .
 169 Some pseudo devices allow an optional parameter that sets the limit
 170 on the number of instances of the device that are active simultaneously.
 171 .NH 2
 172 System options
 173 .PP
 174 Other than the mandatory pieces of information described above, it
 175 is also possible to include various optional system facilities
 176 or to modify system behavior and/or limits.
 177 For example, 4.4BSD can be configured to support binary compatibility for
 178 programs built under 4.3BSD.  Also, optional support is provided
 179 for disk quotas and tracing the performance of the virtual memory
 180 subsystem.  Any optional facilities to be configured into
 181 the system are specified in the configuration file.  The resultant
 182 files generated by
 183 .I config
 184 will automatically include the necessary pieces of the system.