4.t

早期freebsd实现

.PP
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,
.IP
.nf
\fBconfig\fP vmunix \fBroot\fP \fBon\fP hp0 \fBswap\fP \fBon\fP hp0b \fBsize\fP 1200
.fi
.LP
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.
.PP
To create a generic configuration, only the clause ``swap generic''
should be specified; any extra clauses will cause an error.
.NH 2
Device specifications
.PP
Each device attached to a machine must be specified
to
.I 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.
.PP
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 \fInexi\fP 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 
.I "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 
.IR 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.
.PP
A device specification takes one of the following forms:
.IP
.nf
\fBmaster\fP \fIdevice-name\fP \fIdevice-info\fP
\fBcontroller\fP \fIdevice-name\fP \fIdevice-info\fP [ \fIinterrupt-spec\fP ]
\fBdevice\fP \fIdevice-name\fP \fIdevice-info\fP \fIinterrupt-spec\fP
\fBdisk\fP \fIdevice-name\fP \fIdevice-info\fP
\fBtape\fP \fIdevice-name\fP \fIdevice-info\fP
.fi
.LP
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.''
.PP
The
.I device-name
is one of the standard device names, as
indicated in section 4 of the UNIX Programmers Manual,
concatenated with the
.I logical
unit number to be assigned the device (the 
.I logical
unit number may be different than the
.I physical
unit number indicated on the front of something
like a disk; the
.I 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.
.PP
The
.I 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 \fInexus\fP.
Thus, one of the following
specifications would be used:
.IP
.ta 1.5i 2.5i 4.0i
.nf
\fBcontroller\fP	mba0	\fBat\fP \fBnexus\fP \fIx\fP
\fBcontroller\fP	uba0	\fBat\fP \fBnexus\fP \fIx\fP
.fi
.LP
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.
.PP
The remaining interconnections on the VAX are:
.IP \(bu 3
a controller
may be connected to another controller (e.g. a disk controller attached
to a UNIBUS adapter),
.IP \(bu 3
a master is always attached to a controller (a MASSBUS adapter),
.IP \(bu 3
a tape is always attached to a master (for MASSBUS
tape drives),
.IP \(bu 3
a disk is always attached to a controller, and
.IP \(bu 3
devices
are always attached to controllers (e.g. UNIBUS controllers attached
to UNIBUS adapters).
.LP
The following lines give an example of each of these interconnections:
.IP
.ta 1.5i 2.5i 4.0i
.nf
\fBcontroller\fP	hk0	\fBat\fP uba0 ...
\fBmaster\fP	ht0	\fBat\fP mba0 ...
\fBdisk\fP	hp0	\fBat\fP mba0 ...
\fBtape\fP	tu0	\fBat\fP ht0 ...
\fBdisk\fP	rk1	\fBat\fP hk0 ...
\fBdevice\fP	dz0	\fBat\fP uba0 ...
.fi
.LP
Any piece of hardware which may be connected to a specific
controller may also be wildcarded across multiple controllers.
.PP
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 \fIslave\fP or \fIdrive\fP
number is sufficient to locate the control status register for the
device.
\fIDrive\fP 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:
.IP
.ta 1.5i 2.5i 4.0i
.nf
\fBcontroller\fP	hk0	\fBat\fP uba0 \fBcsr\fP 0177440	\fBvector\fP rkintr
\fBmaster\fP	ht0	\fBat\fP mba0 \fBdrive\fP 0
\fBdisk\fP	hp0	\fBat\fP mba0 \fBdrive\fP ?
\fBtape\fP	tu0	\fBat\fP ht0 \fBslave\fP 0
\fBdisk\fP	rk1	\fBat\fP hk0 \fBdrive\fP 1
\fBdevice\fP	dz0	\fBat\fP uba0 \fBcsr\fP 0160100	\fBvector\fP dzrint dzxint
.fi
.PP
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
.IR device ,
a 
.I flags
field.  It has the syntax
.IP
\fBflags\fP \fInumber\fP
.LP
and is usually placed after the
.I csr
specification.  The
.I 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.
.PP
The exact syntax for each specific device is given in the Synopsis
section of its manual page in section 4 of the manual.
.NH 2
Pseudo-devices
.PP
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
.IP
.DT
.nf
\fBpseudo-device\fP	\fIdevice-name\fP [ \fIhowmany\fP ]
.fi
.PP
Examples of pseudo devices are
\fBpty\fP, the pseudo terminal driver (where the optional
.I howmany
value indicates the number of pseudo terminals to configure, 32 default),
and \fBloop\fP, the software loopback network pseudo-interface.
Other pseudo devices for the network include
\fBimp\fP (required when a CSS or ACC imp is configured)
and \fBether\fP (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.