4.t

早期freebsd实现

.\" Copyright (c) 1980, 1986, 1988 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) 7/29/93
.\"
.ds LH "Installing/Operating \*(4B
.ds CF \*(Dy
.ds RH "System setup
.Sh 1 "System setup"
.PP
This section describes procedures used to set up a \*(4B UNIX system.
These procedures are used when a system is first installed
or when the system configuration changes.  Procedures for normal
system operation are described in the next section.
.Sh 2 "Kernel configuration"
.PP
This section briefly describes the layout of the kernel code and
how files for devices are made.
For a full discussion of configuring
and building system images, consult the document ``Building
4.3BSD UNIX Systems with Config'' (SMM:2).
.Sh 3 "Kernel organization"
.PP
As distributed, the kernel source is in a
separate tar image.  The source may be physically
located anywhere within any filesystem so long as
a symbolic link to the location is created for the file
.Pn /sys
(many files in
.Pn /usr/include
are normally symbolic links relative to
.Pn /sys ).
In further discussions of the system source all path names
will be given relative to
.Pn /sys .
.LP
The kernel is made up of several large generic parts:
.TS
l l l.
sys		main kernel header files
kern		kernel functions broken down as follows
	init	system startup, syscall dispatching, entry points
	kern	scheduling, descriptor handling and generic I/O
	sys	process management, signals
	tty	terminal handling and job control
	vfs	filesystem management
	uipc	interprocess communication (sockets)
	subr	miscellaneous support routines
vm		virtual memory management
ufs		local filesystems broken down as follows
	ufs	common local filesystem routines
	ffs	fast filesystem
	lfs	log-based filesystem
	mfs	memory based filesystem
nfs		Sun-compatible network filesystem
miscfs		miscellaneous filesystems broken down as follows
	deadfs	where rejected vnodes go to die
	fdesc	access to per-process file descriptors
	fifofs	IEEE Std1003.1 FIFOs
	kernfs	filesystem access to kernel data structures
	lofs	loopback filesystem
	nullfs	another loopback filesystem
	portal	associate processes with filesystem locations
	specfs	device special files
	umapfs	provide alternate uid/gid mappings
dev		generic device drivers (SCSI, vnode, concatenated disk)
.TE
.LP
The networking code is organized by protocol
.TS
l l.
net	routing and generic interface drivers
netinet	Internet protocols (TCP, UDP, IP, etc)
netiso	ISO protocols (TP-4, CLNP, CLTP, etc)
netns	Xerox network systems protocols (IDP, SPP, etc)
netx25	CCITT X.25 protocols (X.25 Packet Level, HDLC/LAPB)
.TE
.LP
A separate subdirectory is provided for each machine architecture
.TS
l l.
hp300	HP 9000/300 series of Motorola 68000-based machines
hp	code common to both HP 68k and (non-existent) PA-RISC ports
i386	Intel 386/486-based PC machines
luna68k	Omron 68000-based workstations
news3400	Sony News MIPS-based workstations
pmax	Digital 3100/5000 MIPS-based workstations
sparc	Sun Microsystems SPARCstation 1, 1+, and 2
tahoe	(deprecated) CCI Power 6-series machines
vax	(deprecated) Digital VAX machines
.TE
.LP
Each machine directory is subdivided by function;
for example the hp300 directory contains
.TS
l l.
include	exported machine-dependent header files
hp300	machine-dependent support code and private header files
dev	device drivers
conf	configuration files
stand	machine-dependent standalone code
.TE
.LP
Other kernel related directories
.TS
l l.
compile	area to compile kernels
conf	machine-independent configuration files
stand	machine-independent standalone code
.TE
.Sh 3 "Devices and device drivers"
.PP
Devices supported by UNIX are implemented in the kernel
by drivers whose source is kept in
.Pn /sys/<architecture>/dev .
These drivers are loaded
into the system when included in a cpu specific configuration file
kept in the conf directory.  Devices are accessed through special
files in the filesystem, made by the
.Xr mknod (8)
program and normally kept in the
.Pn /dev
directory.
For all the devices supported by the distribution system, the
files in
.Pn /dev
are created by the
.Pn /dev/MAKEDEV
shell script.
.PP
Determine the set of devices that you have and create a new
.Pn /dev
directory by running the MAKEDEV script.
First create a new directory
.Pn /newdev ,
copy MAKEDEV into it, edit the file MAKEDEV.local
to provide an entry for local needs,
and run it to generate a
.Pn /newdev directory.
For instance,
.DS
\fB#\fP \fIcd /\fP
\fB#\fP \fImkdir newdev\fP
\fB#\fP \fIcp dev/MAKEDEV newdev/MAKEDEV\fP
\fB#\fP \fIcd newdev\fP
\fB#\fP \fIMAKEDEV \*(Dk0 pt0 std LOCAL\fP
.DE
Note the ``std'' argument causes standard devices such as
.Pn /dev/console ,
the machine console, to be created.
.PP
You can then do
.DS
\fB#\fP \fIcd /\fP
\fB#\fP \fImv dev olddev ; mv newdev dev\fP
\fB#\fP \fIsync\fP
.DE
to install the new device directory.
.Sh 3 "Building new system images"
.PP
The kernel configuration of each UNIX system is described by
a single configuration file, stored in the
.Pn /sys/<architecture>/conf
directory.
To learn about the format of this file and the procedure used
to build system images,
start by reading ``Building 4.3BSD UNIX Systems with Config'' (SMM:2),
look at the manual pages in section 4
of the UNIX manual for the devices you have,
and look at the sample configuration files in the
.Pn /sys/<architecture>/conf
directory.
.PP
The configured system image
.Pn vmunix
should be copied to the root, and then booted to try it out.
It is best to name it
.Pn /newvmunix
so as not to destroy the working system until you are sure it does work:
.DS
\fB#\fP \fIcp vmunix /newvmunix\fP
\fB#\fP \fIsync\fP
.DE
It is also a good idea to keep the previous system around under some other
name.  In particular, we recommend that you save the generic distribution
version of the system permanently as
.Pn /genvmunix
for use in emergencies.
To boot the new version of the system you should follow the
bootstrap procedures outlined in section 6.1.
After having booted and tested the new system, it should be installed as
.Pn /vmunix
before going into multiuser operation.
A systematic scheme for numbering and saving old versions
of the system may be useful.
.Sh 2 "Configuring terminals"
.PP
If UNIX is to support simultaneous
access from directly-connected terminals other than the console,
the file
.Pn /etc/ttys
(see
.Xr ttys (5))
must be edited.
.PP
To add a new terminal device, be sure the device is configured into the system
and that the special files for the device have been made by
.Pn /dev/MAKEDEV .
Then, enable the appropriate lines of
.Pn /etc/ttys
by setting the ``status''
field to \fBon\fP (or add new lines).
Note that lines in
.Pn /etc/ttys
are one-for-one with entries in the file of current users
(see
.Pn /var/run/utmp ),
and therefore it is best to make changes
while running in single-user mode
and to add all the entries for a new device at once.
.PP
Each line in the
.Pn /etc/ttys
file is broken into four tab separated
fields (comments are shown by a `#' character and extend to
the end of the line).  For each terminal line the four fields
are:
the device (without a leading
.Pn /dev ),
the program
.Pn /sbin/init
should startup to service the line
(or \fBnone\fP if the line is to be left alone),
the terminal type (found in
.Pn /usr/share/misc/termcap ),
and optional status information describing if the terminal is
enabled or not and if it is ``secure'' (i.e. the super user should
be allowed to login on the line).
If the console is marked as ``insecure'',
then the root password is required to bring the machine up single-user.
All fields are character strings
with entries requiring embedded white space enclosed in double
quotes.
Thus a newly added terminal
.Pn /dev/tty00
could be added as
.DS
tty00 	"/usr/libexec/getty std.9600"	vt100	on secure	# mike's office
.DE
The std.9600 parameter provided to
.Pn /usr/libexec/getty
is used in searching the file
.Pn /etc/gettytab ;
it specifies a terminal's characteristics (such as baud rate).
To make custom terminal types, consult
.Xr gettytab (5)
before modifying
.Pn /etc/gettytab .
.PP
Dialup terminals should be wired so that carrier is asserted only when the
phone line is dialed up.
For non-dialup terminals, from which modem control is not available,
you must wire back the signals so that
the carrier appears to always be present.  For further details,
find your terminal driver in section 4 of the manual.
.PP
For network terminals (i.e. pseudo terminals), no program should
be started up on the lines.  Thus, the normal entry in
.Pn /etc/ttys
would look like
.DS
ttyp0 	none	network
.DE
(Note, the fourth field is not needed here.)
.PP
When the system is running multi-user, all terminals that are listed in
.Pn /etc/ttys
as \fBon\fP have their line enabled.
If, during normal operations, you wish
to disable a terminal line, you can edit the file
.Pn /etc/ttys
to change the terminal's status to \fBoff\fP and
then send a hangup signal to the
.Xr init
process, by doing
.DS
\fB#\fP \fIkill \-1 1\fP
.DE
Terminals can similarly be enabled by changing the status field
from \fBoff\fP to \fBon\fP and sending a hangup signal to
.Xr init .
.PP
Note that if a special file is inaccessible when
.Xr init
tries to create a process for it,
.Xr init
will log a message to the
system error logging process (see
.Xr syslogd (8))
and try to reopen the terminal every minute, reprinting the warning
message every 10 minutes.  Messages of this sort are normally
printed on the console, though other actions may occur depending
on the configuration information found in
.Pn /etc/syslog.conf .
.PP
Finally note that you should change the names of any dialup
terminals to ttyd?
where ? is in [0-9a-zA-Z], as some programs use this property of the
names to determine if a terminal is a dialup.
Shell commands to do this should be put in the
.Pn /dev/MAKEDEV.local
script.
.PP
While it is possible to use truly arbitrary strings for terminal names,
the accounting and noticeably the
.Xr ps (1)
command make good use of the convention that tty names
(by default, and also after dialups are named as suggested above)
are distinct in the last 2 characters.
Change this and you may be sorry later, as the heuristic
.Xr ps (1)
uses based on these conventions will then break down and
.Xr ps
will run MUCH slower.
.Sh 2 "Adding users"
.PP
The procedure for adding a new user is described in
.Xr adduser (8).
You should add accounts for the initial user community, giving