.\" Copyright (c) 1983, 1993
.\" 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
.\" 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
.\" @(#)5.t 8.1 (Berkeley) 6/8/93
.\".ds RH "Sample Configuration Files
SAMPLE CONFIGURATION FILES
In this section we will consider how to configure a
sample VAX-11/780 system on which the hardware can be
reconfigured to guard against various hardware mishaps.
We then study the rules needed to configure a VAX-11/750
to run in a networking environment.
Our VAX-11/780 is configured with hardware
recommended in the document ``Hints on Configuring a VAX for 4.2BSD''
(this is one of the high-end configurations).
Table 1 lists the pertinent hardware to be configured.
Item Vendor Connection Name Reference
MASSBUS controller Emulex nexus ? mba0 hp(4)
MASSBUS controller Emulex nexus ? mba1
UNIBUS adapter DEC nexus ?
tape controller Emulex uba0 tm0 tm(4)
tape drive Kennedy tm0 te0
tape drive Kennedy tm0 te1
terminal multiplexor Emulex uba0 dh0 dh(4)
terminal multiplexor Emulex uba0 dh1
terminal multiplexor Emulex uba0 dh2
Table 1. VAX-11/780 Hardware support.
We will call this machine ANSEL and construct a configuration
The first step is to fill in the global configuration parameters.
The machine is a VAX, so the
is ``vax''. We will assume this system will
run only on this one processor, so the
is ``VAX780''. The options are empty since this is going to
be a ``vanilla'' VAX. The system identifier, as mentioned before,
is ``ANSEL,'' and the maximum number of users we plan to support is
about 40. Thus the beginning of the configuration file looks like
# ANSEL VAX (a picture perfect machine)
To this we must then add the specifications for three
system images. The first will be our standard system with the
root on ``hp0'' and swapping on the same drive as the root.
The second will have the root file system in the same location,
but swap space interleaved among drives on each controller.
Finally, the third will be a generic system,
to allow us to boot off any of the four disk drives.
config vmunix root on hp0
config hpvmunix root on hp0 swap on hp0 and hp2
config genvmunix swap generic
Finally, the hardware must be specified. Let us first just try
transcribing the information from Table 1.
controller mba0 at nexus ?
controller mba1 at nexus ?
controller uba0 at nexus ?
controller tm0 at uba0 csr 0172520 vector tmintr
device dh0 at uba0 csr 0160020 vector dhrint dhxint
device dm0 at uba0 csr 0170500 vector dmintr
device dh1 at uba0 csr 0160040 vector dhrint dhxint
device dh2 at uba0 csr 0160060 vector dhrint dhxint
(Oh, I forgot to mention one panel of the terminal multiplexor
has modem control, thus the ``dm0'' device.)
This will suffice, but leaves us with little flexibility. Suppose
our first disk controller were to break. We would like to recable the
drives normally on the second controller so that all our disks could
still be used without reconfiguring the system. To do this we wildcard
the MASSBUS adapter connections and also the slave numbers. Further,
we wildcard the UNIBUS adapter connections in case we decide some time
in the future to purchase another adapter to offload the single UNIBUS
we currently have. The revised device specifications would then be:
controller mba0 at nexus ?
controller mba1 at nexus ?
controller uba0 at nexus ?
controller tm0 at uba? csr 0172520 vector tmintr
device dh0 at uba? csr 0160020 vector dhrint dhxint
device dm0 at uba? csr 0170500 vector dmintr
device dh1 at uba? csr 0160040 vector dhrint dhxint
device dh2 at uba? csr 0160060 vector dhrint dhxint
The completed configuration file for ANSEL is shown in Appendix C.
VAX-11/750 with network support
Our VAX-11/750 system will be located on two 10Mb/s Ethernet
local area networks and also the DARPA Internet. The system
will have a MASSBUS drive for the root file system and two
UNIBUS drives. Paging is interleaved among all three drives.
We have sold our standard DEC terminal multiplexors since this
machine will be accessed solely through the network. This
machine is not intended to have a large user community, it
does not have a great deal of memory. First the global parameters:
# UCBVAX (Gateway to the world)
The multiple cpu types allow us to replace UCBVAX with a
more powerful cpu without reconfiguring the system. The
value of 32 given for the maximum number of users is done to
force the system data structures to be over-allocated. That
is desirable on this machine because, while it is not expected
to support many users, it is expected to perform a great deal
The ``INET'' indicates that we plan to use the
DARPA standard Internet protocols on this machine,
and ``NS'' also includes support for Xerox NS protocols.
Note that unlike 4.2BSD configuration files,
the network protocol options do not require corresponding pseudo devices.
The system images and disks are configured next.
config vmunix root on hp swap on hp and rk0 and rk1
config upvmunix root on up
config hkvmunix root on hk swap on rk0 and rk1
controller mba0 at nexus ?
controller uba0 at nexus ?
controller sc0 at uba? csr 0176700 vector upintr
controller hk0 at uba? csr 0177440 vector rkintr
UCBVAX requires heavy interleaving of its paging area to keep up
with all the mail traffic it handles. The limiting factor on this
system's performance is usually the number of disk arms, as opposed
to memory or cpu cycles. The extra UNIBUS controller, ``sc0'',
is in case the MASSBUS controller breaks and a spare controller
must be installed (most of our old UNIBUS controllers have been
replaced with the newer MASSBUS controllers, so we have a number
of these around as spares).
Finally, we add in the network devices.
Pseudo terminals are needed to allow users to
log in across the network (remember the only hardwired terminal
The software loopback device is used for on-machine communications.
The connection to the Internet is through
an IMP, this requires yet another
(in addition to the actual hardware device used by the
IMP software). And, finally, there are the two Ethernet devices.
These use a special protocol, the Address Resolution Protocol (ARP),
to map between Internet and Ethernet addresses. Thus, yet another
is needed. The additional device specifications are show below.
device acc0 at uba? csr 0167600 vector accrint accxint
device ec0 at uba? csr 0164330 vector ecrint eccollide ecxint
device il0 at uba? csr 0164000 vector ilrint ilcint
The completed configuration file for UCBVAX is shown in Appendix C.
It should be noted in these examples that neither system was
configured to use disk quotas or the 4.1BSD compatibility mode.
To use these optional facilities, and others, we would probably
clean out our current configuration, reconfigure the system, then
recompile and relink the system image(s). This could, of course,
be avoided by figuring out which relocatable object files are
affected by the reconfiguration, then reconfiguring and recompiling
only those files affected by the configuration change. This technique
should be used carefully.
projects / unix-history / blob