3.t

早期freebsd实现

.FE
We also include support for ISO Connection-Oriented Network Service,
X.25, TP-0.
The session and presentation layers are provided outside
the kernel using the ISO Development Environment by Marshall Rose,
that is available via anonymous FTP
(but is not included on the distribution tape).
Included in this development environment are file
transfer and management (FTAM), virtual terminals (VT),
a directory services implementation (X.500),
and miscellaneous other utilities.
.PP
Kernel support for the ISO OSI protocols is enabled with the ISO option
in the kernel configuration file.
The
.Xr iso (4)
manual page describes the protocols and addressing;
see also
.Xr clnp (4),
.Xr tp (4)
and
.Xr cltp (4).
The OSI equivalent to ARP is ESIS (End System to Intermediate System Routing
Protocol); running this protocol is mandatory, however one can manually add
translations for machines that do not participate by use of the
.Xr route (8)
command.
Additional information is provided in the manual page describing
.Xr esis (4).
.PP
The command
.Xr route (8)
has a new syntax and several new capabilities:
it can install routes with a specified destination and mask,
and can change route characteristics such as hop count, packet size
and window size.
.PP
Several important enhancements have been added to the TCP/IP
protocols including TCP header prediction and
serial line IP (SLIP) with header compression.
The routing implementation has been completely rewritten
to use a hierarchical routing tree with a mask per route
to support the arbitrary levels of routing found in the ISO protocols.
The routing table also stores and caches route characteristics
to speed the adaptation of the throughput and congestion avoidance
algorithms.
.PP
The format of the
.I sockaddr
structure (the structure used to describe a generic network address with an
address family and family-specific data)
has changed from previous releases,
as have the address family-specific versions of this structure.
The
.I sa_family
family field has been split into a length,
.Pn sa_len ,
and a family,
.Pn sa_family .
System calls that pass a
.I sockaddr
structure into the kernel (e.g.
.Fn sendto
and
.Fn connect )
have a separate parameter that specifies the 
.I sockaddr
length, and thus it is not necessary to fill in the
.I sa_len
field for those system calls.
System calls that pass a
.I sockaddr
structure back from the kernel (e.g. 
.Fn recvfrom
and
.Fn accept )
receive a completely filled-in
.I sockaddr
structure, thus the length field is valid.
Because this would not work for old binaries,
the new library uses a different system call number.
Thus, most networking programs compiled under \*(4B are incompatible
with older systems.
.PP
Although this change is mostly source and binary compatible
with old programs, there are three exceptions.
Programs with statically initialized
.I sockaddr
structures
(usually the Internet form, a
.I sockaddr_in )
are not compatible.
Generally, such programs should be changed to fill in the structure
at run time, as C allows no way to initialize a structure without
assuming the order and number of fields.
Also, programs with use structures to describe a network packet format
that contain embedded
.I sockaddr
structures also require change; a definition of an
.I osockaddr
structure is provided for this purpose.
Finally, programs that use the
.Sm SIOCGIFCONF
ioctl to get a complete list of interface addresses
need to check the
.I sa_len
field when iterating through the array of addresses returned,
as not all the structures returned have the same length
(this variance in length is nearly guaranteed by the presence of link-layer
address structures).
.Sh 4 "Additions and changes to filesystems"
.PP
The \*(4B distribution contains most of the interfaces
specified in the IEEE Std1003.1 system interface standard.
Filesystem additions include IEEE Std1003.1 FIFOs,
byte-range file locking, and saved user and group identifiers.
.PP
A new virtual filesystem interface has been added to the
kernel to support multiple filesystems.
In comparison with other interfaces,
the Berkeley interface has been structured for more efficient support
of filesystems that maintain state (such as the local filesystem).
The interface has been extended with support for stackable
filesystems done at UCLA.
These extensions allow for filesystems to be layered on top of each
other and allow new vnode operations to be added without requiring
changes to existing filesystem implementations.
For example,
the umap filesystem (see
.Xr mount_umap (8))
is used to mount a sub-tree of an existing filesystem
that uses a different set of uids and gids than the local system.
Such a filesystem could be mounted from a remote site via NFS or it
could be a filesystem on removable media brought from some foreign
location that uses a different password file.
.PP
Other new filesystems that may be stacked include the loopback filesystem
.Xr mount_lofs (8),
the kernel filesystem
.Xr mount_kernfs (8),
and the portal filesystem
.Xr mount_portal (8).
.PP
The buffer cache in the kernel is now organized as a file block cache
rather than a device block cache.
As a consequence, cached blocks from a file
and from the corresponding block device would no longer be kept consistent.
The block device thus has little remaining value.
Three changes have been made for these reasons:
.IP 1)
block devices may not be opened while they are mounted,
and may not be mounted while open, so that the two versions of cached
file blocks cannot be created,
.IP 2)
filesystem checks of the root now use the raw device
to access the root filesystem, and
.IP 3)
the root filesystem is initially mounted read-only
so that nothing can be written back to disk during or after change to
the raw filesystem by
.Xr fsck .
.LP
The root filesystem may be made writable while in single-user mode
with the command:
.DS
.ft CW
mount \-uw /
.DE
The mount command has an option to update the flags on a mounted filesystem,
including the ability to upgrade a filesystem from read-only to read-write
or downgrade it from read-write to read-only.
.PP
In addition to the local ``fast filesystem'',
we have added an implementation of the network filesystem (NFS)
that fully interoperates with the NFS shipped by Sun and its licensees.
Because our NFS implementation was implemented
by Rick Macklem of the University of Guelph
using only the publicly available NFS specification,
it does not require a license from Sun to use in source or binary form.
By default it runs over UDP to be compatible with Sun's implementation.
However, it can be configured on a per-mount basis to run over TCP.
Using TCP allows it to be used quickly and efficiently through
gateways and over long-haul networks.
Using an extended protocol, it supports Leases to allow a limited
callback mechanism that greatly reduces the network traffic necessary
to maintain cache consistency between the server and its clients.
Its use will be familiar to users of other implementations of NFS.
See the manual pages
.Xr mount (8),
.Xr mountd (8),
.Xr fstab (5),
.Xr exports (5),
.Xr netgroup (5),
.Xr nfsd (8),
.Xr nfsiod (8),
and
.Xr nfssvc (8).
and the document ``The 4.4BSD NFS Implementation'' (SMM:6)
for further information.
The format of
.Pn /etc/fstab
has changed from previous \*(Bs releases
to a blank-separated format to allow colons in pathnames.
.PP
A new local filesystem, the log-structured filesystem (LFS),
has been added to the system.
It provides near disk-speed output and fast crash recovery.
This work is based, in part, on the LFS filesystem created
for the Sprite operating system at Berkeley.
While the kernel implementation is almost complete,
only some of the utilities to support the
filesystem have been written,
so we do not recommend it for production use.
See
.Xr newlfs (8),
.Xr mount_lfs (8)
and
.Xr lfs_cleanerd (8)
for more information.
For a in-depth description of the implementation and performance
characteristics of log-structured filesystems in general,
and this one in particular, see Dr. Margo Seltzer's doctoral thesis,
available from the University of California Computer Science Department.
.PP
We have also added a memory-based filesystem that runs in
pageable memory, allowing large temporary filesystems without
requiring dedicated physical memory.
.PP
The local ``fast filesystem'' has been enhanced to do 
clustering that allows large pieces of files to be
allocated contiguously resulting in near doubling
of filesystem throughput.
The filesystem interface has been extended to allow
files and filesystems to grow to 2^63 bytes in size.
The quota system has been rewritten to support both
user and group quotas (simultaneously if desired).
Quota expiration is based on time rather than
the previous metric of number of logins over quota.
This change makes quotas more useful on fileservers
onto which users seldom login.
.PP
The system security has been greatly enhanced by the
addition of additional file flags that permit a file to be
marked as immutable or append only.
Once set, these flags can only be cleared by the super-user
when the system is running in insecure mode (normally, single-user).
In addition to the immutable and append-only flags,
the filesystem supports a new user-settable flag ``nodump''.
(File flags are set using the
.Xr chflags (1)
utility.)
When set on a file,
.Xr dump (8)
will omit the file from incremental backups
but retain them on full backups.
See the ``-h'' flag to 
.Xr dump (8)
for details on how to change this default.
The ``nodump'' flag is usually set on core dumps,
system crash dumps, and object files generated by the compiler.
Note that the flag is not preserved when files are copied
so that installing an object file will cause it to be preserved.
.PP
The filesystem format used in \*(4B has several additions.
Directory entries have an additional field,
.Pn d_type ,
that identifies the type of the entry
(normally found in the
.Pn st_mode
field of the
.Pn stat
structure).
This field is particularly useful for identifying
directories without the need to use
.Xr stat (2).
.PP
Short (less than sixty byte) symbolic links are now stored
in the inode itself rather than in a separate data block.
This saves disk space and makes access of symbolic links faster.
Short symbolic links are not given a special type,
so a user-level application is unaware of their special treatment.
Unlike pre-\*(4B systems, symbolic links do
not have an owner, group, access mode, times, etc.
Instead, these attributes are taken from the directory that contains the link.
The only attributes returned from an
.Xr lstat (2)
that refer to the symbolic link itself are the file type (S_IFLNK),
size, blocks, and link count (always 1).
.PP
An implementation of an auto-mounter daemon,
.Xr amd ,
was contributed by Jan-Simon Pendry of the
Imperial College of Science, Technology & Medicine.
See the document ``AMD \- The 4.4BSD Automounter'' (SMM:13)
for further information.
.PP
The directory
.Pn /dev/fd
contains special files
.Pn 0
through
.Pn 63
that, when opened, duplicate the corresponding file descriptor.
The names
.Pn /dev/stdin ,
.Pn /dev/stdout
and
.Pn /dev/stderr
refer to file descriptors 0, 1 and 2.
See
.Xr fd (4)
and
.Xr mount_fdesc (8)
for more information.
.Sh 4 "POSIX terminal driver changes"
.PP
The \*(4B system uses the IEEE P1003.1 (POSIX.1) terminal interface
rather than the previous \*(Bs terminal interface.
The terminal driver is similar to the System V terminal driver
with the addition of the necessary extensions to get the
functionality previously available in the \*(Ps terminal driver.
Both the old
.Xr ioctl
calls and old options to
.Xr stty (1)
are emulated.
This emulation is expected to be unavailable in many vendors releases,
so conversion to the new interface is encouraged.
.PP
\*(4B also adds the IEEE Std1003.1 job control interface,
that is similar to the \*(Ps job control interface,
but adds a security model that was missing in the
\*(Ps job control implementation.
A new system call,
.Fn setsid ,
creates a job-control session consisting of a single process
group with one member, the caller, that becomes a session leader.
Only a session leader may acquire a controlling terminal.
This is done explicitly via a
.Sm TIOCSCTTY
.Fn ioctl
call, not implicitly by an
.Fn open
call.
The call fails if the terminal is in use.
Programs that allocate controlling terminals (or pseudo-terminals)
require change to work in this environment.
The versions of
.Xr xterm
provided in the X11R5 release includes the necessary changes.
New library routines are available for allocating and initializing
pseudo-terminals and other terminals as controlling terminal; see
.Pn /usr/src/lib/libutil/pty.c
and
.Pn /usr/src/lib/libutil/login_tty.c .
.PP
The POSIX job control model formalizes the previous conventions
used in setting up a process group.
Unfortunately, this requires that changes be made in a defined order
and with some synchronization that were not necessary in the past.
Older job control shells (csh, ksh) will generally not operate correctly
with the new system.
.PP
Most of the other kernel interfaces have been changed to correspond
with the POSIX.1 interface, although that work is not complete.
See the relevant manual pages and the IEEE POSIX standard.
.Sh 4 "Native operating system compatibility"