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