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.
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:
The 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
where the device name would normally be found. For example,
config kernel root on major 99 minor 1
Normally, 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 1200
would 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.
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.* 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-info
A ``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 x
To 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:
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 dzxint
Certain 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
and 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.
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.