![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to 2.t CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 02.config|
Return to 2.t CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / smm / 02.config |
1.1 root 1: .\" Copyright (c) 1983 Regents of the University of California.
2: .\" All rights reserved. The Berkeley software License Agreement
3: .\" specifies the terms and conditions for redistribution.
4: .\"
5: .\" @(#)2.t 6.2 (Berkeley) 6/3/86
6: .\"
7: .\".ds RH "Configuration File Contents
8: .ne 2i
9: .NH
10: CONFIGURATION FILE CONTENTS
11: .PP
12: A system configuration must include at least the following
13: pieces of information:
14: .IP \(bu 3
15: machine type
16: .IP \(bu 3
17: cpu type
18: .IP \(bu 3
19: system identification
20: .IP \(bu 3
21: timezone
22: .IP \(bu 3
23: maximum number of users
24: .IP \(bu 3
25: location of the root file system
26: .IP \(bu 3
27: available hardware
28: .PP
29: .I Config
30: allows multiple system images to be generated from a single
31: configuration description. Each system image is configured
32: for identical hardware, but may have different locations for the root
33: file system and, possibly, other system devices.
34: .NH 2
35: Machine type
36: .PP
37: The
38: .I "machine type"
39: indicates if the system is going to operate on a DEC VAX-11\(dg computer,
40: .FS
41: \(dg DEC, VAX, UNIBUS, MASSBUS and MicroVAX are trademarks of Digital
42: Equipment Corporation.
43: .FE
44: or some other machine on which 4.3BSD operates. The machine type
45: is used to locate certain data files which are machine specific, and
46: also to select rules used in constructing the resultant
47: configuration files.
48: .NH 2
49: Cpu type
50: .PP
51: The
52: .I "cpu type"
53: indicates which, of possibly many, cpu's the system is to operate on.
54: For example, if the system is being configured for a VAX-11, it could
55: be running on a VAX 8600, VAX-11/780, VAX-11/750, VAX-11/730 or MicroVAX II.
56: (Other VAX cpu types, including the 8650, 785 and 725, are configured using
57: the cpu designation for compatible machines introduced earlier.)
58: Specifying
59: more than one cpu type implies that the system should be configured to run
60: on any of the cpu's specified. For some types of machines this is not
61: possible and
62: .I config
63: will print a diagnostic indicating such.
64: .NH 2
65: System identification
66: .PP
67: The
68: .I "system identification"
69: is a moniker attached to the system, and often the machine on which the
70: system is to run. For example, at Berkeley we have machines named Ernie
71: (Co-VAX), Kim (No-VAX), and so on. The system identifier selected is used to
72: create a global C ``#define'' which may be used to isolate system dependent
73: pieces of code in the kernel. For example, Ernie's Varian driver used
74: to be special cased because its interrupt vectors were wired together. The
75: code in the driver which understood how to handle this non-standard hardware
76: configuration was conditionally compiled in only if the system
77: was for Ernie.
78: .PP
79: The system identifier ``GENERIC'' is given to a system which
80: will run on any cpu of a particular machine type; it should not
81: otherwise be used for a system identifier.
82: .NH 2
83: Timezone
84: .PP
85: The timezone in which the system is to run is used to define the
86: information returned by the \fIgettimeofday\fP\|(2)
87: system call. This value is specified as the number of hours east
88: or west of GMT. Negative numbers indicate a value east of GMT.
89: The timezone specification may also indicate the
90: type of daylight savings time rules to be applied.
91: .NH 2
92: Maximum number of users
93: .PP
94: The system allocates many system data structures at boot time
95: based on the maximum number of users the system will support.
96: This number is normally between 8 and 40, depending
97: on the hardware and expected job mix. The rules
98: used to calculate system data structures are discussed in
99: Appendix D.
100: .NH 2
101: Root file system location
102: .PP
103: When the system boots it must know the location of
104: the root of the file system
105: tree. This location and the part(s) of the disk(s) to be used
106: for paging and swapping must be specified in order to create
107: a complete configuration description.
108: .I Config
109: uses many rules to calculate default locations for these items;
110: these are described in Appendix B.
111: .PP
112: When a generic system is configured, the root file system is left
113: undefined until the system is booted. In this case, the root file
114: system need not be specified, only that the system is a generic system.
115: .NH 2
116: Hardware devices
117: .PP
118: When the system boots it goes through an
119: .I autoconfiguration
120: phase. During this period, the system searches for all
121: those hardware devices
122: which the system builder has indicated might be present. This probing
123: sequence requires certain pieces of information such as register
124: addresses, bus interconnects, etc. A system's hardware may be configured
125: in a very flexible manner or be specified without any flexibility
126: whatsoever. Most people do not configure hardware devices into the
127: system unless they are currently present on the machine, expect
128: them to be present in the near future, or are simply guarding
129: against a hardware
130: failure somewhere else at the site (it is often wise to configure in
131: extra disks in case an emergency requires moving one off a machine which
132: has hardware problems).
133: .PP
134: The specification of hardware devices usually occupies the majority of
135: the configuration file. As such, a large portion of this document will
136: be spent understanding it. Section 6.3 contains a description of
137: the autoconfiguration process, as it applies to those planning to
138: write, or modify existing, device drivers.
139: .NH 2
140: Pseudo devices
141: .PP
142: Several system facilities are configured in a manner like that used
143: for hardware devices although they are not associated with specific hardware.
144: These system options are configured as
145: .IR pseudo-devices .
146: Some pseudo devices allow an optional parameter that sets the limit
147: on the number of instances of the device that are active simultaneously.
148: .NH 2
149: System options
150: .PP
151: Other than the mandatory pieces of information described above, it
152: is also possible to include various optional system facilities
153: or to modify system behavior and/or limits.
154: For example, 4.3BSD can be configured to support binary compatibility for
155: programs built under 4.1BSD. Also, optional support is provided
156: for disk quotas and tracing the performance of the virtual memory
157: subsystem. Any optional facilities to be configured into
158: the system are specified in the configuration file. The resultant
159: files generated by
160: .I config
161: will automatically include the necessary pieces of the system.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.