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