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
CONFIGURATION FILE SYNTAX
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.
A configuration file is broken up into three logical pieces:
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.
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 vax and sun.
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 vax machine are VAX8600, VAX780, VAX750, VAX730 and VAX630 (MicroVAX II). The 8650 is listed as an 8600, the 785 as a 780, and a 725 as a 730.
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 ``='', 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.
Options that are used within the system makefile and evaluated by make are listed as 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.
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 dst, 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 gettimeofday\|(2) and ctime\|(3) for more information.
This system is to be known as 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.
The maximum expected number of simultaneously active user on this system is number . This number is used to size several system data structures. System image parameters
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:
config sysname config-clausesThe sysname field is the name given to the loaded system image; almost everyone names their standard system image ``kernel''. 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 execve (2) calls may also be specified, though in practice this is almost always selected by config using one of its rules for selecting default locations for system devices.
A configuration clause is one of the following
root [ on ] root-device swap [ on ] swap-device [ and swap-device ] ... dumps [ on ] dump-device args [ on ] arg-device(the ``on'' is optional.) Multiple configuration clauses are separated by white space; 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 execve should be done on a particular device.
The device names supplied in the clauses may be fully specified as a device, unit, and file system partition; or underspecified in which case 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.
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.
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
major x minor ywhere the device name would normally be found. For example,
config kernel root on major 99 minor 1Normally, 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,
config kernel root on hp0 swap on hp0b size 1200would 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.
To create a generic configuration, only the clause ``swap generic'' should be specified; any extra clauses will cause an error. Device specifications
Each device attached to a machine must be specified to 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.
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 nexi 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 "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 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.
A device specification takes one of the following forms:
master device-name device-info controller device-name device-info [ interrupt-spec ] device device-name device-info interrupt-spec disk device-name device-info tape device-name device-infoA ``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.''
The device-name is one of the standard device names, as indicated in section 4 of the UNIX Programmers Manual, concatenated with the logical unit number to be assigned the device (the logical unit number may be different than the physical unit number indicated on the front of something like a disk; the 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.
The 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 nexus. Thus, one of the following specifications would be used:
controller mba0 at nexus x controller uba0 at nexus xTo 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.
The remaining interconnections on the VAX are:
\(bu 3a controller may be connected to another controller (e.g. a disk controller attached to a UNIBUS adapter),\(bu 3a master is always attached to a controller (a MASSBUS adapter),\(bu 3a tape is always attached to a master (for MASSBUS tape drives),\(bu 3a disk is always attached to a controller, and\(bu 3devices are always attached to controllers (e.g. UNIBUS controllers attached to UNIBUS adapters).The following lines give an example of each of these interconnections:
controller hk0 at uba0 ... master ht0 at mba0 ... disk hp0 at mba0 ... tape tu0 at ht0 ... disk rk1 at hk0 ... device dz0 at uba0 ...Any piece of hardware which may be connected to a specific controller may also be wildcarded across multiple controllers.
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 slave or drive number is sufficient to locate the control status register for the device. Drive 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:
controller hk0 at uba0 csr 0177440 vector rkintr master ht0 at mba0 drive 0 disk hp0 at mba0 drive ? tape tu0 at ht0 slave 0 disk rk1 at hk0 drive 1 device dz0 at uba0 csr 0160100 vector dzrint dzxintCertain 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 device , a flags field. It has the syntax
flags numberand is usually placed after the csr specification. The 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.
The exact syntax for each specific device is given in the Synopsis section of its manual page in section 4 of the manual. Pseudo-devices
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
pseudo-device device-name [ howmany ]Examples of pseudo devices are pty, the pseudo terminal driver (where the optional howmany value indicates the number of pseudo terminals to configure, 32 default), and loop, the software loopback network pseudo-interface. Other pseudo devices for the network include imp (required when a CSS or ACC imp is configured) and ether (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.