BSD 4.4 Lite Share Sources

25 files changed, 6165 insertions, 0 deletions

diff --git a/share/man/man4/Makefile b/share/man/man4/Makefile
new file mode 100644
index 0000000..c5ad948
--- /dev/null
+++ b/share/man/man4/Makefile
@@ -0,0 +1,10 @@
+#	@(#)Makefile	8.1 (Berkeley) 6/18/93
+
+MAN4=	clnp.0 cltp.0 drum.0 esis.0 fd.0 icmp.0 idp.0 inet.0 ip.0 \
+	iso.0 lo.0 netintro.0 ns.0 nsip.0 null.0 pty.0 route.0 \
+	spp.0 tcp.0 termios.0 tp.0 tty.0 udp.0 unix.0
+MLINKS+=fd.4 stderr.4 fd.4 stdin.4 fd.4 stdout.4
+MLINKS+=netintro.4 networking.4
+SUBDIR=	man4.hp300 man4.i386 man4.sparc man4.tahoe man4.vax
+
+.include <bsd.prog.mk>
diff --git a/share/man/man4/clnp.4 b/share/man/man4/clnp.4
new file mode 100644
index 0000000..ee42610
--- /dev/null
+++ b/share/man/man4/clnp.4
@@ -0,0 +1,167 @@
+.\" Copyright (c) 1990, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)clnp.4	8.2 (Berkeley) 4/2/94
+.\"
+.Dd April 2, 1994
+.Dt CLNP 4
+.Os
+.Sh NAME
+.Nm clnp
+.Nd Connectionless-Mode Network Protocol
+.Sh SYNOPSIS
+.Fd #include <sys/socket.h>
+.Fd #include <netiso/iso.h>
+.Fd #include <netiso/clnp.h>
+.Ft int
+.Fn socket AF_ISO SOCK_RAW 0
+.Sh DESCRIPTION
+.Tn CLNP
+is the connectionless-mode network protocol used by the 
+connectionless-mode network service. This protocol is specified in
+.Tn ISO
+8473.
+It may be accessed
+through a
+.Dq raw socket
+for debugging purposes only.
+.Tn CLNP
+sockets are connectionless,
+and are normally used with the
+.Xr sendto
+and
+.Xr recvfrom
+calls, though the
+.Xr connect 2
+call may also be used to fix the destination for future
+packets (in which case the 
+.Xr read 2
+or
+.Xr recv 2
+and 
+.Xr write 2
+or
+.Xr send 2
+system calls may be used).
+.Pp
+Outgoing packets automatically have a
+.Tn CLNP
+header prepended to
+them. Incoming packets received by the user contain the full
+.Tn CLNP
+header.
+The following
+.Xr setsockopt
+options apply to
+.Tn CLNP :
+.Bl -tag -width CLNPOPT_FLAGS
+.It Dv CLNPOPT_FLAGS
+Sets the flags which are passed to clnp when sending a datagram.
+Valid flags are:
+.Pp
+.Bl -tag -width "CLNP_NO_CKSUM" -offset indent -compact
+.It Dv CLNP_NO_SEG
+Do not allow segmentation
+.It Dv CLNP_NO_ER
+Suppress ER pdus
+.It Dv CLNP_NO_CKSUM
+Do not generate the
+.Tn CLNP
+checksum
+.El
+.Pp
+.It Dv CLNPOPT_OPTS
+Sets
+.Tn CLNP
+options. The options must be formatted exactly as specified by
+.Tn ISO
+8473, section 7.5
+.Dq Options Part.
+Once an option has been set, it will
+be sent on all packets until a different option is set.
+.El
+.Sh CONGESTION EXPERIENCE BIT
+Whenever a packet is transmitted, the globally unique quality of
+service option is added to the packet. The sequencing preferred bit and
+the low transit delay bit are set in this option.
+.Pp
+If a packet is forwarded containing the globally unique quality of
+service option, and the interface through which the packet will be 
+transmitted has a queue length greater than
+.Em congest_threshold ,
+then the congestion experienced bit is set in the quality of service option.
+.Pp
+The threshold value stored in
+.Em congest_threshold
+may be tuned.
+.Pp
+When a packet is received with the 
+globally unique quality of service option present, and the
+congestion experienced bit is set, then the transport congestion
+control function is called.
+.Sh DIAGNOSTICS
+A socket operation may fail with one of the following errors returned:
+.Bl -tag -width [EADDRNOTAVAIL]
+.It Bq Er EISCONN
+When trying to establish a connection on a socket which
+already has one, or when trying to send a datagram with the destination
+address specified and the socket is already connected;
+.It Bq Er ENOTCONN
+When trying to send a datagram, but
+no destination address is specified, and the socket hasn't been
+connected;
+.It Bq Er ENOBUFS
+When the system runs out of memory for
+an internal data structure;
+.It Bq Er EADDRNOTAVAIL
+When an attempt is made to create a 
+socket with a network address for which no network interface
+exists;
+.It Bq Er EHOSTUNREACH
+When trying to send a datagram, but no route to the destination
+address exists.
+.It Bq Er EINVAL
+When specifying unsupported options.
+.El
+.Sh SEE ALSO
+.Xr send 2 ,
+.Xr recv 2 ,
+.Xr intro 4 ,
+.Xr iso 4
+.Sh BUGS
+Packets are sent with the type code of 0x1d (technically an invalid
+packet type) for lack of a better way to identify raw
+.Tn CLNP
+packets.
+.Pp
+No more than
+.Dv MLEN
+bytes of options can be specified.
diff --git a/share/man/man4/cltp.4 b/share/man/man4/cltp.4
new file mode 100644
index 0000000..13bbd1c
--- /dev/null
+++ b/share/man/man4/cltp.4
@@ -0,0 +1,127 @@
+.\" Copyright (c) 1990, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)cltp.4	8.1 (Berkeley) 6/9/93
+.\"
+.Dd June 9, 1993
+.Dt CLTP 4
+.Os
+.Sh NAME
+.Nm cltp
+.Nd
+.Tn ISO
+Connectionless Transport Protocol
+.Sh SYNOPSIS
+.Fd #include <sys/socket.h>
+.Fd #include <netiso/iso.h>
+.Ft int
+.Fn socket AF_ISO SOCK_DGRAM 0
+.Sh DESCRIPTION
+.Tn CLTP
+is a simple, unreliable datagram protocol which is accessed
+via the
+.Dv SOCK_DGRAM
+abstraction for the
+.Tn ISO
+protocol family.
+.Tn CLTP
+sockets are connectionless, and are
+normally used with the
+.Xr sendto
+and
+.Xr recvfrom
+calls, though the
+.Xr connect 2
+call may also be used to fix the destination for future
+packets (in which case the 
+.Xr recv 2
+or
+.Xr read 2
+and 
+.Xr send 2
+or
+.Xr write 2
+system calls may be used).
+.Pp
+.Tn CLTP
+address formats are identical to those used by TP.
+In particular
+.Tn CLTP
+provides a service selector in addition
+to the normal
+.Tn ISO NSAP .
+Note that the
+.Tn CLTP
+selector
+space is separate from the TP selector space (i.e. a
+.Tn CLTP
+selector
+may not be
+.Dq connected
+to a TP selector).
+.Pp
+Options at the
+.Tn CLNP
+network level may be used with
+.Tn CLTP ;
+see
+.Xr clnp 4 .
+.Sh DIAGNOSTICS
+A socket operation may fail with one of the following errors returned:
+.Bl -tag -width [EADDRNOTAVAIL]
+.It Bq Er EISCONN
+when trying to establish a connection on a socket which
+already has one, or when trying to send a datagram with the destination
+address specified and the socket is already connected;
+.It Bq Er ENOTCONN
+when trying to send a datagram, but
+no destination address is specified, and the socket hasn't been
+connected;
+.It Bq Er ENOBUFS
+when the system runs out of memory for
+an internal data structure;
+.It Bq Er EADDRINUSE
+when an attempt
+is made to create a socket with a selector which has already been
+allocated;
+.It Bq Er EADDRNOTAVAIL
+when an attempt is made to create a 
+socket with a network address for which no network interface
+exists.
+.El
+.Sh SEE ALSO
+.Xr getsockopt 2 ,
+.Xr recv 2 ,
+.Xr send 2 ,
+.Xr socket 2 ,
+.Xr intro 4 ,
+.Xr iso 4 ,
+.Xr clnp 4
diff --git a/share/man/man4/drum.4 b/share/man/man4/drum.4
new file mode 100644
index 0000000..404d09d
--- /dev/null
+++ b/share/man/man4/drum.4
@@ -0,0 +1,59 @@
+.\" Copyright (c) 1980, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)drum.4	8.1 (Berkeley) 6/5/93
+.\"
+.Dd June 5, 1993
+.Dt DRUM 4
+.Os BSD 4
+.Sh NAME
+.Nm drum
+.Nd paging device
+.Sh DESCRIPTION
+This file refers to the paging device in use by the system.
+This may actually be a subdevice of one of the disk drivers, but in
+a system with paging interleaved across multiple disk drives
+it provides an indirect driver for the multiple drives.
+.Sh FILES
+.Bl -tag -width /dev/drum
+.It Pa /dev/drum
+.El
+.Sh HISTORY
+The
+.Nm
+special file appeared in
+.Bx 3.0 .
+.Sh BUGS
+Reads from the drum are not allowed across the interleaving boundaries.
+Since these only occur every .5Mbytes
+or so,
+and since the system never allocates blocks across the boundary,
+this is usually not a problem.
diff --git a/share/man/man4/esis.4 b/share/man/man4/esis.4
new file mode 100644
index 0000000..8fa57be
--- /dev/null
+++ b/share/man/man4/esis.4
@@ -0,0 +1,215 @@
+.\" Copyright (c) 1990, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)esis.4	8.2 (Berkeley) 11/30/93
+.\"
+.Dd November 30, 1993
+.Dt ESIS 4
+.Os
+.Sh NAME
+.Nm es-is
+.Nd End System to Intermediate System Routing Protocol
+.Sh SYNOPSIS
+.Sy pseudo-device
+.Nm ether
+.Sh DESCRIPTION
+The
+.Nm ES-IS
+routing protocol is used to dynamically map between
+.Tn ISO NSAP
+addresses and
+.Tn ISO SNPA
+addresses; to permit End and Intermediate Systems
+to learn of each other's existence; and to allow Intermediate Systems
+to inform End Systems of (potentially) better routes to use when 
+forwarding
+.Tn NPDU Ns s
+to a particular destination.
+.Pp
+The mapping between
+.Tn NSAP
+addresses and
+.Tn SNPA
+addresses is accomplished by
+transmitting hello
+.Tn PDU Ns s
+between the cooperating Systems. These
+.Tn PDU Ns s
+are transmitted whenever the
+.Em configuration
+timer expires.
+When a hello
+.Tn PDU
+is received, the
+.Tn SNPA
+address that it conveys is stored in the routing table for as long as the
+.Em holding time
+in the
+.Tn PDU
+suggests. The default
+.Em holding time
+(120 seconds) placed in the hello
+.Tn PDU ,
+the configuration timer value,
+and the system type (End System or Intermediate System) may be changed by
+issuing an
+.Dv SIOCSSTYPE
+.Xr ioctl 2 ,
+which is defined in
+.Pa /sys/netiso/iso_snpac.h.
+.Pp
+The protocol behaves differently depending on whether the System is
+configured as an End System or an Intermediate System.
+.Sh END SYSTEM OPERATION
+When an interface requests a mapping for an address not in the cache,
+the
+.Tn SNPA
+of any known Intermediate System is returned. If an Intermediate
+System is not known, then the
+.Em all end systems
+multicast address
+is returned. It is assumed that the intended recipient of the NPDU will
+immediately transmit a hello
+.Tn PDU
+back to the originator of the
+.Tn NPDU .
+.Pp
+If an
+.Tn NPDU
+is forwarded by the End System, a redirect
+.Tn PDU
+will not be
+generated.
+However, redirect
+.Tn PDU Ns s
+received will be processed. This processing
+consists of adding an entry in the routing table. If the
+redirect is towards an Intermediate System, then an entry is made in the
+routing table as well.
+The entry in the routing table will mark the
+.Tn NSAP
+address contained in the redirect
+.Tn PDU
+as the gateway for the destination
+system (if an NET is supplied), or will create a route with
+the NSAP address as the
+destination and the
+.Tn SNPA
+address (embodied as a link-level sockaddr) as the
+gateway.
+.Pp
+If the System is configured as an End System, it will report all the
+.Tn NSAP Ns s
+that have been configured using the ifconfig command, and no others.
+It is possible to have more than one
+.Tn NSAP
+assigned to a given interface,
+and it is also possible to have the same
+.Tn NSAP
+assigned to multiple
+interfaces.
+However, any
+.Tn NSAP
+containing an NSEL that is consistent with the
+nsellength option (default one) of any interface will be accepted as
+an
+.Tn NSAP
+for this System.
+.Sh INTERMEDIATE SYSTEM OPERATION
+When an interface requests a mapping for an address not in the routing table,
+an error is returned.
+.Pp
+When an
+.Tn NPDU
+is forwarded out on the same interface that the
+.Tn NPDU
+arrived upon,
+a redirect
+.Tn PDU
+is generated.
+.Sh MANUAL ROUTING TABLE MODIFICATION
+.Pp
+To facilitate communications with systems which do not use
+.Nm ES-IS,
+one may add a route whose destination is a sockaddr_iso containing
+the
+.Tn NSAP
+in question, and the gateway being a link-level sockaddr,
+either by writing a special purpose program, or using the
+.Xr route 8
+command e.g.:
+.Bd -literal
+route add -iface -osi 49.0.4.8.0.2b.b.83.bf \
+	-link qe0:8.0.2b.b.83.bf
+.Ed
+.Pp
+If the
+System is configured as an End System and has a single network interface
+which does not support multicast reception,
+it is necessary to manually configure the location of an
+.Tn IS ,
+using the route command in a similar way.
+There, the destination address should be
+.Dq default
+(spelled 
+out literally as 7
+.Tn ASCII
+characters), and the gateway should be
+once again be a link-level sockaddr specifying the
+.Tn SNPA
+of the
+.Tn IS .
+.Sh SEE ALSO
+.Xr un 4 ,
+.Xr iso 4 ,
+.Xr route 8 ,
+.Xr ifconfig 8
+.Rs
+.%T "End system to Intermediate system routing exchange protocol for use in conjunction with the Protocol for providing the connectionless-mode network service"
+.%R ISO
+.%N 9542
+.Re
+.Sh BUGS
+Redirect
+.Tn PDU Ns s
+do not contain options from the forwarded
+.Tn NPDU
+which generated
+the redirect. The multicast address used on the 802.3 network is taken from
+the
+.Tn NBS
+December 1987 agreements. This multicast address is not compatible
+with the 802.5 (Token Ring) multicast addresses format. Therefore, broadcast
+addresses are used on the 802.5 subnetwork.
+Researchers at the University of Wisconsin are constructing an implementation
+of the
+.Tn IS-IS
+routing protocol.
diff --git a/share/man/man4/fd.4 b/share/man/man4/fd.4
new file mode 100644
index 0000000..96ddcb0
--- /dev/null
+++ b/share/man/man4/fd.4
@@ -0,0 +1,91 @@
+.\" Copyright (c) 1990, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)fd.4	8.1 (Berkeley) 6/9/93
+.\"
+.Dd June 9, 1993
+.Dt FD 4
+.Os
+.Sh NAME
+.Nm fd ,
+.Nm stdin ,
+.Nm stdout ,
+.Nm stderr
+.Nd file descriptor files
+.Sh DESCRIPTION
+The files
+.Pa /dev/fd/0
+through
+.Pa /dev/fd/#
+refer to file descriptors which can be accessed through the file
+system.
+If the file descriptor is open and the mode the file is being opened
+with is a subset of the mode of the existing descriptor, the call:
+.Bd -literal -offset indent
+fd = open("/dev/fd/0", mode);
+.Ed
+.Pp
+and the call:
+.Bd -literal -offset indent
+fd = fcntl(0, F_DUPFD, 0);
+.Ed
+.Pp
+are equivalent.
+.Pp
+Opening the files
+.Pa /dev/stdin ,
+.Pa /dev/stdout
+and
+.Pa /dev/stderr
+is equivalent to the following calls:
+.Bd -literal -offset indent
+fd = fcntl(STDIN_FILENO,  F_DUPFD, 0);
+fd = fcntl(STDOUT_FILENO, F_DUPFD, 0);
+fd = fcntl(STDERR_FILENO, F_DUPFD, 0);
+.Ed
+.Pp
+Flags to the
+.Xr open 2
+call other than
+.Dv O_RDONLY , 
+.Dv O_WRONLY
+and
+.Dv O_RDWR
+are ignored.
+.Sh FILES
+.Bl -tag -width /dev/stderr -compact
+.It Pa /dev/fd/#
+.It Pa /dev/stdin
+.It Pa /dev/stdout
+.It Pa /dev/stderr
+.El
+.Sh SEE ALSO
+.Xr tty 4
diff --git a/share/man/man4/icmp.4 b/share/man/man4/icmp.4
new file mode 100644
index 0000000..d87772f
--- /dev/null
+++ b/share/man/man4/icmp.4
@@ -0,0 +1,117 @@
+.\" Copyright (c) 1986, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)icmp.4	8.1 (Berkeley) 6/5/93
+.\"
+.Dd June 5, 1993
+.Dt ICMP 4
+.Os BSD 4.3
+.Sh NAME
+.Nm icmp
+.Nd Internet Control Message Protocol
+.Sh SYNOPSIS
+.Fd #include <sys/socket.h>
+.Fd #include <netinet/in.h>
+.Ft int
+.Fn socket AF_INET SOCK_RAW proto
+.Sh DESCRIPTION
+.Tn ICMP
+is the error and control message protocol used
+by
+.Tn IP
+and the Internet protocol family.  It may be accessed
+through a
+.Dq raw socket
+for network monitoring
+and diagnostic functions.
+The
+.Fa proto
+parameter to the socket call to create an
+.Tn ICMP
+socket
+is obtained from
+.Xr getprotobyname 3 .
+.Tn ICMP
+sockets are connectionless,
+and are normally used with the
+.Xr sendto
+and
+.Xr recvfrom
+calls, though the
+.Xr connect 2
+call may also be used to fix the destination for future
+packets (in which case the 
+.Xr read 2
+or
+.Xr recv 2
+and 
+.Xr write 2
+or
+.Xr send 2
+system calls may be used).
+.Pp
+Outgoing packets automatically have an
+.Tn IP
+header prepended to
+them (based on the destination address).
+Incoming packets are received with the
+.Tn IP
+header and options intact.
+.Sh DIAGNOSTICS
+A socket operation may fail with one of the following errors returned:
+.Bl -tag -width [EADDRNOTAVAIL]
+.It Bq Er EISCONN
+when trying to establish a connection on a socket which
+already has one, or when trying to send a datagram with the destination
+address specified and the socket is already connected;
+.It Bq Er ENOTCONN
+when trying to send a datagram, but
+no destination address is specified, and the socket hasn't been
+connected;
+.It Bq Er ENOBUFS
+when the system runs out of memory for
+an internal data structure;
+.It Bq Er EADDRNOTAVAIL
+when an attempt is made to create a 
+socket with a network address for which no network interface
+exists.
+.El
+.Sh SEE ALSO
+.Xr send 2 ,
+.Xr recv 2 ,
+.Xr intro 4 ,
+.Xr inet 4 ,
+.Xr ip 4
+.Sh HISTORY
+The
+.Nm
+protocol appeared in
+.Bx 4.3 .
diff --git a/share/man/man4/idp.4 b/share/man/man4/idp.4
new file mode 100644
index 0000000..38a6f6a
--- /dev/null
+++ b/share/man/man4/idp.4
@@ -0,0 +1,185 @@
+.\" Copyright (c) 1985, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)idp.4	8.1 (Berkeley) 6/5/93
+.\"
+.Dd June 5, 1993
+.Dt IDP 4
+.Os BSD 4.3
+.Sh NAME
+.Nm idp
+.Nd Xerox Internet Datagram Protocol
+.Sh SYNOPSIS
+.Fd #include <sys/socket.h>
+.Fd #include <netns/ns.h>
+.Fd #include <netns/idp.h>
+.Ft int
+.Fn socket AF_NS SOCK_DGRAM 0
+.Sh DESCRIPTION
+.Tn IDP
+is a simple, unreliable datagram protocol which is used
+to support the
+.Dv SOCK_DGRAM
+abstraction for the Internet
+protocol family.
+.Tn IDP
+sockets are connectionless, and are
+normally used with the
+.Xr sendto
+and
+.Xr recvfrom
+calls, though the
+.Xr connect 2
+call may also be used to fix the destination for future
+packets (in which case the 
+.Xr recv 2
+or
+.Xr read 2
+and 
+.Xr send 2
+or
+.Xr write 2
+system calls may be used).
+.Pp
+Xerox protocols are built vertically on top of
+.Tn IDP .
+Thus,
+.Tn IDP
+address formats are identical to those used by
+.Tn SPP .
+Note that the
+.Tn IDP
+port
+space is the same as the
+.Tn SPP
+port space (i.e. a
+.Tn IDP
+port
+may be
+.Dq connected
+to a
+.Tn SPP
+port, with certain
+options enabled below).
+In addition broadcast packets may be sent
+(assuming the underlying network supports
+this) by using a reserved
+.Dq broadcast address ;
+this address
+is network interface dependent.
+.Sh DIAGNOSTICS
+A socket operation may fail with one of the following errors returned:
+.Bl -tag -width [EADDRNOTAVAIL]
+.It Bq Er EISCONN
+when trying to establish a connection on a socket which
+already has one, or when trying to send a datagram with the destination
+address specified and the socket is already connected;
+.It Bq Er ENOTCONN
+when trying to send a datagram, but
+no destination address is specified, and the socket hasn't been
+connected;
+.It Bq Er ENOBUFS
+when the system runs out of memory for
+an internal data structure;
+.It Bq Er EADDRINUSE
+when an attempt
+is made to create a socket with a port which has already been
+allocated;
+.It Bq Er EADDRNOTAVAIL
+when an attempt is made to create a 
+socket with a network address for which no network interface
+exists.
+.El
+.Sh SOCKET OPTIONS
+.Bl -tag -width [SO_HEADERS_ON_OUTPUT]
+.It Bq Dv SO_ALL_PACKETS
+When set, this option defeats automatic processing of Error packets,
+and Sequence Protocol packets.
+.It Bq Dv SO_DEFAULT_HEADERS
+The user provides the kernel an
+.Tn IDP
+header, from which
+it gleans the Packet Type.
+When requested, the kernel will provide an
+.Tn IDP
+header, showing
+the default packet type, and local and foreign addresses, if
+connected.
+.It Bq Dv SO_HEADERS_ON_INPUT
+When set, the first 30 bytes of any data returned from a read
+or recv from will be the initial 30 bytes of the
+.Tn IDP
+packet,
+as described by
+.Bd -literal -offset indent
+struct idp {
+	u_short		idp_sum;
+	u_short		idp_len;
+	u_char		idp_tc;
+	u_char		idp_pt;
+	struct ns_addr	idp_dna;
+	struct ns_addr	idp_sna;
+};
+.Ed
+.Pp
+This allows the user to determine the packet type, and whether
+the packet was a multi-cast packet or directed specifically at
+the local host.
+When requested, gives the current state of the option,
+.Pf ( Dv NSP_RAWIN
+or 0).
+.It Bq Dv SO_HEADERS_ON_OUTPUT
+When set, the first 30 bytes of any data sent
+will be the initial 30 bytes of the
+.Tn IDP
+packet.
+This allows the user to determine the packet type, and whether
+the packet should be multi-cast packet or directed specifically at
+the local host.
+You can also misrepresent the sender of the packet.
+When requested, gives the current state of the option.
+.Pf ( Dv NSP_RAWOUT
+or 0).
+.It Bq Dv SO_SEQNO
+When requested, this returns a sequence number which is not likely
+to be repeated until the machine crashes or a very long time has passed.
+It is useful in constructing Packet Exchange Protocol packets.
+.El
+.Sh SEE ALSO
+.Xr send 2 ,
+.Xr recv 2 ,
+.Xr intro 4 ,
+.Xr ns 4
+.Sh HISTORY
+The
+.Nm
+protocol appeared in
+.Bx 4.3 .
diff --git a/share/man/man4/inet.4 b/share/man/man4/inet.4
new file mode 100644
index 0000000..690bfca
--- /dev/null
+++ b/share/man/man4/inet.4
@@ -0,0 +1,182 @@
+.\" Copyright (c) 1983, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)inet.4	8.1 (Berkeley) 6/5/93
+.\"
+.Dd June 5, 1993
+.Dt INET 4
+.Os BSD 4.2
+.Sh NAME
+.Nm inet
+.Nd Internet protocol family
+.Sh SYNOPSIS
+.Fd #include <sys/types.h>
+.Fd #include <netinet/in.h>
+.Sh DESCRIPTION
+The Internet protocol family is a collection of protocols
+layered atop the
+.Em Internet  Protocol
+.Pq Tn IP
+transport layer, and utilizing the Internet address format.
+The Internet family provides protocol support for the
+.Dv SOCK_STREAM , SOCK_DGRAM ,
+and
+.Dv SOCK_RAW
+socket types; the
+.Dv SOCK_RAW
+interface provides access to the
+.Tn IP
+protocol.
+.Sh ADDRESSING
+Internet addresses are four byte quantities, stored in
+network standard format (on the
+.Tn VAX
+these are word and byte
+reversed).  The include file
+.Aq Pa netinet/in.h
+defines this address
+as a discriminated union.
+.Pp
+Sockets bound to the Internet protocol family utilize
+the following addressing structure,
+.Bd -literal -offset indent
+struct sockaddr_in {
+	short	sin_family;
+	u_short	sin_port;
+	struct	in_addr sin_addr;
+	char	sin_zero[8];
+};
+.Ed
+.Pp
+Sockets may be created with the local address
+.Dv INADDR_ANY
+to effect
+.Dq wildcard
+matching on incoming messages. 
+The address in a
+.Xr connect 2
+or
+.Xr sendto 2
+call may be given as
+.Dv INADDR_ANY
+to mean
+.Dq this host .
+The distinguished address
+.Dv INADDR_BROADCAST
+is allowed as a shorthand for the broadcast address on the primary
+network if the first network configured supports broadcast.
+.Sh PROTOCOLS
+The Internet protocol family is comprised of
+the
+.Tn IP
+transport protocol, Internet Control
+Message Protocol
+.Pq Tn ICMP ,
+Transmission Control
+Protocol
+.Pq Tn TCP ,
+and User Datagram Protocol
+.Pq Tn UDP .
+.Tn TCP
+is used to support the
+.Dv SOCK_STREAM
+abstraction while
+.Tn UDP
+is used to support the
+.Dv SOCK_DGRAM
+abstraction.  A raw interface to
+.Tn IP
+is available
+by creating an Internet socket of type
+.Dv SOCK_RAW .
+The
+.Tn ICMP
+message protocol is accessible from a raw socket.
+.Pp
+The 32-bit Internet address contains both network and host parts.
+It is frequency-encoded; the most-significant bit is clear
+in Class A addresses, in which the high-order 8 bits are the network
+number.
+Class B addresses use the high-order 16 bits as the network field,
+and Class C addresses have a 24-bit network part.
+Sites with a cluster of local networks and a connection to the
+Internet may chose to use a single network number for the cluster;
+this is done by using subnet addressing.
+The local (host) portion of the address is further subdivided
+into subnet and host parts.
+Within a subnet, each subnet appears to be an individual network;
+externally, the entire cluster appears to be a single, uniform
+network requiring only a single routing entry.
+Subnet addressing is enabled and examined by the following
+.Xr ioctl 2
+commands on a datagram socket in the Internet domain;
+they have the same form as the
+.Dv SIOCIFADDR
+command (see
+.Xr intro 4 ) .
+.Pp
+.Bl -tag -width SIOCSIFNETMASK
+.It Dv SIOCSIFNETMASK
+Set interface network mask.
+The network mask defines the network part of the address;
+if it contains more of the address than the address type would indicate,
+then subnets are in use.
+.It Dv SIOCGIFNETMASK
+Get interface network mask.
+.El
+.Sh SEE ALSO
+.Xr ioctl 2 ,
+.Xr socket 2 ,
+.Xr intro 4 ,
+.Xr tcp 4 ,
+.Xr udp 4 ,
+.Xr ip 4 ,
+.Xr icmp 4
+.Rs
+.%T "An Introductory 4.3 BSD Interprocess Communication Tutorial"
+.%B PS1
+.%N 7
+.Re
+.Rs
+.%T "An Advanced 4.3 BSD Interprocess Communication Tutorial"
+.%B PS1
+.%N 8
+.Re
+.Sh CAVEAT
+The Internet protocol support is subject to change as
+the Internet protocols develop.  Users should not depend
+on details of the current implementation, but rather
+the services exported.
+.Sh HISTORY
+The
+.Nm
+protocol interface appeared in
+.Bx 4.2 .
diff --git a/share/man/man4/ip.4 b/share/man/man4/ip.4
new file mode 100644
index 0000000..0f95c4b
--- /dev/null
+++ b/share/man/man4/ip.4
@@ -0,0 +1,378 @@
+.\" Copyright (c) 1983, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)ip.4	8.2 (Berkeley) 11/30/93
+.\"
+.Dd November 30, 1993
+.Dt IP 4
+.Os BSD 4.2
+.Sh NAME
+.Nm ip
+.Nd Internet Protocol
+.Sh SYNOPSIS
+.Fd #include <sys/socket.h>
+.Fd #include <netinet/in.h>
+.Ft int
+.Fn socket AF_INET SOCK_RAW proto
+.Sh DESCRIPTION
+.Tn IP 
+is the transport layer protocol used
+by the Internet protocol family.
+Options may be set at the
+.Tn IP
+level
+when using higher-level protocols that are based on
+.Tn IP
+(such as
+.Tn TCP
+and
+.Tn UDP ) .
+It may also be accessed
+through a
+.Dq raw socket
+when developing new protocols, or
+special-purpose applications.
+.Pp
+There are several
+.Tn IP-level
+.Xr setsockopt 2 / Ns
+.Xr getsockopt 2
+options.
+.Dv IP_OPTIONS 
+may be used to provide
+.Tn IP
+options to be transmitted in the
+.Tn IP
+header of each outgoing packet
+or to examine the header options on incoming packets.
+.Tn IP
+options may be used with any socket type in the Internet family.
+The format of
+.Tn IP
+options to be sent is that specified by the
+.Tn IP 
+protocol specification (RFC-791), with one exception:
+the list of addresses for Source Route options must include the first-hop
+gateway at the beginning of the list of gateways.
+The first-hop gateway address will be extracted from the option list
+and the size adjusted accordingly before use.
+To disable previously specified options,
+use a zero-length buffer:
+.Bd -literal
+setsockopt(s, IPPROTO_IP, IP_OPTIONS, NULL, 0);
+.Ed
+.Pp
+.Dv IP_TOS 
+and 
+.Dv IP_TTL 
+may be used to set the type-of-service and time-to-live
+fields in the 
+.Tn IP 
+header for 
+.Dv SOCK_STREAM 
+and 
+.Dv SOCK_DGRAM 
+sockets. For example,
+.Bd -literal
+int tos = IPTOS_LOWDELAY;       /* see <netinet/in.h> */
+setsockopt(s, IPPROTO_IP, IP_TOS, &tos, sizeof(tos));
+
+int ttl = 60;                   /* max = 255 */
+setsockopt(s, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl));
+.Ed
+.Pp
+If the 
+.Dv IP_RECVDSTADDR 
+option is enabled on a 
+.Dv SOCK_DGRAM 
+socket,
+the
+.Xr recvmsg
+call will return the destination 
+.Tn IP 
+address for a 
+.Tn UDP 
+datagram. 
+The msg_control field in the msghdr structure points to a buffer 
+that contains a cmsghdr structure followed by the 
+.Tn IP 
+address. 
+The cmsghdr fields have the following values:
+.Bd -literal
+cmsg_len = sizeof(struct in_addr)
+cmsg_level = IPPROTO_IP
+cmsg_type = IP_RECVDSTADDR
+.Ed
+.Ss "Multicast Options"
+.Pp
+.Tn IP 
+multicasting is supported only on 
+.Dv AF_INET 
+sockets of type
+.Dv SOCK_DGRAM 
+and 
+.Dv SOCK_RAW,
+and only on networks where the interface
+driver supports multicasting.
+.Pp
+The 
+.Dv IP_MULTICAST_TTL 
+option changes the time-to-live (TTL)
+for outgoing multicast datagrams
+in order to control the scope of the multicasts:
+.Bd -literal
+u_char ttl;	/* range: 0 to 255, default = 1 */
+setsockopt(s, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, sizeof(ttl));
+.Ed
+.sp
+Datagrams with a TTL of 1 are not forwarded beyond the local network.
+Multicast datagrams with a TTL of 0 will not be transmitted on any network,
+but may be delivered locally if the sending host belongs to the destination
+group and if multicast loopback has not been disabled on the sending socket
+(see below).  Multicast datagrams with TTL greater than 1 may be forwarded
+to other networks if a multicast router is attached to the local network.
+.Pp
+For hosts with multiple interfaces, each multicast transmission is 
+sent from the primary network interface.
+The 
+.Dv IP_MULTICAST_IF 
+option overrides the default for 
+subsequent transmissions from a given socket:
+.Bd -literal
+struct in_addr addr;
+setsockopt(s, IPPROTO_IP, IP_MULTICAST_IF, &addr, sizeof(addr));
+.Ed
+.sp
+where "addr" is the local 
+.Tn IP 
+address of the desired interface or
+.Dv INADDR_ANY 
+to specify the default interface.
+An interface's local IP address and multicast capability can 
+be obtained via the 
+.Dv SIOCGIFCONF 
+and 
+.Dv SIOCGIFFLAGS 
+ioctls. 
+Normal applications should not need to use this option.
+.Pp
+If a multicast datagram is sent to a group to which the sending host itself
+belongs (on the outgoing interface), a copy of the datagram is, by default,
+looped back by the IP layer for local delivery. 
+The 
+.Dv IP_MULTICAST_LOOP 
+option gives the sender explicit control 
+over whether or not subsequent datagrams are looped back:
+.Bd -literal
+u_char loop;	/* 0 = disable, 1 = enable (default) */
+setsockopt(s, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, sizeof(loop));
+.Ed
+.sp
+This option
+improves performance for applications that may have no more than one
+instance on a single host (such as a router demon), by eliminating
+the overhead of receiving their own transmissions.  It should generally not
+be used by applications for which there may be more than one instance on a
+single host (such as a conferencing program) or for which the sender does
+not belong to the destination group (such as a time querying program).
+.Pp
+A multicast datagram sent with an initial TTL greater than 1 may be delivered
+to the sending host on a different interface from that on which it was sent,
+if the host belongs to the destination group on that other interface.  The
+loopback control option has no effect on such delivery.
+.Pp
+A host must become a member of a multicast group before it can receive 
+datagrams sent to the group.  To join a multicast group, use the 
+.Dv IP_ADD_MEMBERSHIP 
+option:
+.Bd -literal
+struct ip_mreq mreq;
+setsockopt(s, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mreq, sizeof(mreq));
+.Ed
+.sp
+where 
+.Fa mreq
+is the following structure:
+.Bd -literal
+struct ip_mreq {
+    struct in_addr imr_multiaddr; /* multicast group to join */
+    struct in_addr imr_interface; /* interface to join on */
+}
+.Ed
+.sp
+.Dv imr_interface 
+should
+be 
+.Dv INADDR_ANY 
+to choose the default multicast interface, 
+or the 
+.Tn IP 
+address of a particular multicast-capable interface if
+the host is multihomed.
+Membership is associated with a single interface; 
+programs running on multihomed hosts may need to 
+join the same group on more than one interface.  
+Up to 
+.Dv IP_MAX_MEMBERSHIPS 
+(currently 20) memberships may be added on a
+single socket.
+.Pp
+To drop a membership, use:
+.Bd -literal
+struct ip_mreq mreq;
+setsockopt(s, IPPROTO_IP, IP_DROP_MEMBERSHIP, &mreq, sizeof(mreq));
+.Ed
+.sp
+where 
+.Fa mreq
+contains the same values as used to add the membership. 
+Memberships are dropped when the socket is closed or the process exits.  
+.\"-----------------------
+.Ss "Raw IP Sockets"
+.Pp
+Raw
+.Tn IP
+sockets are connectionless,
+and are normally used with the
+.Xr sendto
+and
+.Xr recvfrom
+calls, though the
+.Xr connect 2
+call may also be used to fix the destination for future
+packets (in which case the 
+.Xr read 2
+or
+.Xr recv 2
+and 
+.Xr write 2
+or
+.Xr send 2
+system calls may be used).
+.Pp
+If
+.Fa proto
+is 0, the default protocol
+.Dv IPPROTO_RAW
+is used for outgoing
+packets, and only incoming packets destined for that protocol
+are received.
+If
+.Fa proto
+is non-zero, that protocol number will be used on outgoing packets
+and to filter incoming packets.
+.Pp
+Outgoing packets automatically have an
+.Tn IP
+header prepended to
+them (based on the destination address and the protocol
+number the socket is created with),
+unless the 
+.Dv IP_HDRINCL 
+option has been set.
+Incoming packets are received with
+.Tn IP
+header and options intact.
+.Pp
+.Dv IP_HDRINCL 
+indicates the complete IP header is included with the data
+and may be used only with the 
+.Dv SOCK_RAW 
+type.
+.Bd -literal
+#include <netinet/ip.h>
+
+int hincl = 1;                  /* 1 = on, 0 = off */
+setsockopt(s, IPPROTO_IP, IP_HDRINCL, &hincl, sizeof(hincl));
+.Ed
+.sp
+Unlike previous 
+.Tn BSD 
+releases, the program must set all
+the fields of the IP header, including the following:
+.Bd -literal
+ip->ip_v = IPVERSION;
+ip->ip_hl = hlen >> 2;
+ip->ip_id = 0;  /* 0 means kernel set appropriate value */
+ip->ip_off = offset;
+.Ed
+.sp .5
+If the header source address is set to 
+.Dv INADDR_ANY,
+the kernel will choose an appropriate address.
+.Sh DIAGNOSTICS
+A socket operation may fail with one of the following errors returned:
+.Bl -tag -width [EADDRNOTAVAIL]
+.It Bq Er EISCONN
+when trying to establish a connection on a socket which
+already has one, or when trying to send a datagram with the destination
+address specified and the socket is already connected;
+.It Bq Er ENOTCONN
+when trying to send a datagram, but
+no destination address is specified, and the socket hasn't been
+connected;
+.It Bq Er ENOBUFS
+when the system runs out of memory for
+an internal data structure;
+.It Bq Er EADDRNOTAVAIL
+when an attempt is made to create a 
+socket with a network address for which no network interface
+exists.
+.It Bq Er EACESS
+when an attempt is made to create
+a raw IP socket by a non-privileged process.
+.El
+.Pp
+The following errors specific to
+.Tn IP
+may occur when setting or getting
+.Tn IP
+options:
+.Bl -tag -width EADDRNOTAVAILxx
+.It Bq Er EINVAL
+An unknown socket option name was given.
+.It Bq Er EINVAL
+The IP option field was improperly formed;
+an option field was shorter than the minimum value
+or longer than the option buffer provided.
+.El
+.Sh SEE ALSO
+.Xr getsockopt 2 ,
+.Xr send 2 ,
+.Xr recv 2 ,
+.Xr intro 4 ,
+.Xr icmp 4 ,
+.Xr inet 4
+.Sh HISTORY
+The
+.Nm
+protocol appeared in
+.Bx 4.2 .
diff --git a/share/man/man4/iso.4 b/share/man/man4/iso.4
new file mode 100644
index 0000000..c15e34c
--- /dev/null
+++ b/share/man/man4/iso.4
@@ -0,0 +1,186 @@
+.\" Copyright (c) 1990, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)iso.4	8.2 (Berkeley) 11/30/93
+.\"
+.Dd November 30, 1993
+.Dt ISO 4
+.Os
+.Sh NAME
+.Nm iso
+.Nd
+.Tn ISO
+protocol family
+.Sh SYNOPSIS
+.Fd #include <sys/types.h>
+.Fd #include <netiso/iso.h>
+.Sh DESCRIPTION
+The
+.Tn ISO
+protocol family is a collection of protocols
+that uses the
+.Tn ISO
+address format.
+The
+.Tn ISO
+family provides protocol support for the
+.Dv SOCK_SEQPACKET
+abstraction through the
+.Tn TP
+protocol
+.Pf ( Tn ISO
+8073), 
+for the
+.Dv SOCK_DGRAM
+abstraction through the connectionless transport
+protocol
+.Pf ( Tn ISO
+8602),
+and for the
+.Dv SOCK_RAW
+abstraction
+by providing direct access (for debugging) to the
+.Tn CLNP 
+.Pf ( Tn ISO
+8473) network layer protocol.
+.Sh ADDRESSING
+.Tn ISO
+addresses are based upon
+.Tn ISO
+8348/AD2, 
+.%T "Addendum to the Network Service Definition Covering Network Layer Addressing."
+.Pp
+Sockets bound to the OSI protocol family use
+the following address structure:
+.Bd -literal
+struct iso_addr {
+     u_char    isoa_len;  /* length, not including this byte */
+     char      isoa_genaddr[20];  /* general opaque address */
+};
+
+struct sockaddr_iso {
+     u_char    siso_len;      /* size of this sockaddr */
+     u_char    siso_family;   /* addressing domain, AF_ISO */
+     u_char    siso_plen;     /* presentation selector length */
+     u_char    siso_slen;     /* session selector length */
+     u_char    siso_tlen;     /* transport selector length */
+     struct    iso_addr siso_addr; /* network address */
+     u_char    siso_pad[6];    /* space for gosip v2 SELs */
+};
+#define siso_nlen siso_addr.isoa_len
+#define siso_data siso_addr.isoa_genaddr
+.Ed
+.Pp
+The fields of this structure are:
+.Bl -tag -width Ds
+.It Ar siso_len:
+Length of the entire address structure, in bytes, which may grow to
+be longer than the 32 bytes shown above.
+.It Ar siso_family:
+Identifies the domain:
+.Dv AF_ISO .
+.It Ar siso_tlen:
+Length of the transport selector.
+.It Ar siso_slen:
+Length of the session selector.
+This is not currently supported by the kernel and is provided as
+a convenience for user level programs.
+.It Ar siso_plen:
+Length of the presentation selector.
+This is not currently supported by the kernel and is provided as
+a convenience for user level programs.
+.It Ar siso_addr:
+The network part of the address, described below.
+.El
+.Sh TRANSPORT ADDRESSING
+.Pp
+An
+.Tn ISO
+transport address is similar to an Internet address in that
+it contains a network-address portion and a portion that the
+transport layer uses to multiplex its services among clients.
+In the Internet domain, this portion of the address is called a
+.Em port .
+In the
+.Tn ISO
+domain, this is called a
+.Em transport selector
+(also known at one time as a
+.Em transport suffix ) .
+While ports are always 16 bits, 
+transport selectors may be
+of (almost) arbitrary size.
+.Pp
+Since the C language does not provide convenient variable
+length structures, we have separated the selector lengths
+from the data themselves.
+The network address and various selectors are stored contiguously,
+with the network address first, then the transport selector, and so
+on.  Thus, if you had a nework address of less then 20 bytes,
+the transport selector would encroach on space normally reserved
+for the network address.
+.Pp
+.Sh NETWORK ADDRESSING.
+.Tn ISO
+network addresses are limited to 20 bytes in length.
+.Tn ISO
+network addresses can take any format.
+.Sh PROTOCOLS
+The
+.Tn ARGO
+1.0 implementation of the 
+.Tn ISO
+protocol family comprises
+the Connectionless-Mode Network Protocol
+.Pq Tn CLNP , 
+and the Transport Protocol
+.Pq Tn TP ,
+classes 4 and 0,
+and
+.Tn X.25 .
+.Tn TP
+is used to support the
+.Dv SOCK_SEQPACKET
+abstraction.
+A raw interface to
+.Tn CLNP
+is available
+by creating an
+.Tn ISO
+socket of type
+.Dv SOCK_RAW .
+This is used for
+.Tn CLNP
+debugging only.
+.Sh SEE ALSO
+.Xr tp 4 ,
+.Xr clnp 4 ,
+.Xr cltp 4
diff --git a/share/man/man4/lo.4 b/share/man/man4/lo.4
new file mode 100644
index 0000000..7fe453b
--- /dev/null
+++ b/share/man/man4/lo.4
@@ -0,0 +1,81 @@
+.\" Copyright (c) 1983, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)lo.4	8.1 (Berkeley) 6/5/93
+.\"
+.Dd June 5, 1993
+.Dt LO 4
+.Os BSD 4.2
+.Sh NAME
+.Nm lo
+.Nd software loopback network interface
+.Sh SYNOPSIS
+.Sy pseudo-device
+.Nm loop
+.Sh DESCRIPTION
+The
+.Nm loop
+interface is a software loopback mechanism which may be
+used for performance analysis, software testing, and/or local
+communication.
+As with other network interfaces, the loopback interface must have
+network addresses assigned for each address family with which it is to be used.
+These addresses
+may be set or changed with the
+.Dv SIOCSIFADDR
+.Xr ioctl 2 .
+The loopback interface should be the last interface configured,
+as protocols may use the order of configuration as an indication of priority.
+The loopback should
+.Em never
+be configured first unless no hardware
+interfaces exist.
+.Sh DIAGNOSTICS
+.Bl -diag
+.It lo%d: can't handle af%d.
+The interface was handed
+a message with addresses formatted in an unsuitable address
+family; the packet was dropped.
+.El
+.Sh SEE ALSO
+.Xr intro 4 ,
+.Xr inet 4 ,
+.Xr ns 4
+.Sh HISTORY
+The
+.Nm
+device appeared in
+.Bx 4.2 .
+.Sh BUGS
+Previous versions of the system enabled the loopback interface
+automatically, using a nonstandard Internet address (127.1).
+Use of that address is now discouraged; a reserved host address
+for the local network should be used instead.
diff --git a/share/man/man4/netintro.4 b/share/man/man4/netintro.4
new file mode 100644
index 0000000..897f189
--- /dev/null
+++ b/share/man/man4/netintro.4
@@ -0,0 +1,328 @@
+.\" Copyright (c) 1983, 1990, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)netintro.4	8.2 (Berkeley) 11/30/93
+.\"
+.Dd November 30, 1993
+.Dt NETINTRO 4
+.Os BSD 4.2
+.Sh NAME
+.Nm networking
+.Nd introduction to networking facilities
+.Sh SYNOPSIS
+.Fd #include <sys/socket.h>
+.Fd #include <net/route.h>
+.Fd #include <net/if.h>
+.Sh DESCRIPTION
+This section is a general introduction to the networking facilities
+available in the system.
+Documentation in this part of section
+4 is broken up into three areas:
+.Em protocol families
+(domains),
+.Em protocols ,
+and
+.Em network interfaces .
+.Pp
+All network protocols are associated with a specific
+.Em protocol family .
+A protocol family provides basic services to the protocol
+implementation to allow it to function within a specific
+network environment.  These services may include 
+packet fragmentation and reassembly, routing, addressing, and 
+basic transport.  A protocol family may support multiple
+methods of addressing, though the current protocol implementations
+do not.  A protocol family is normally comprised of a number
+of protocols, one per
+.Xr socket 2
+type.  It is not required that a protocol family support
+all socket types.  A protocol family may contain multiple
+protocols supporting the same socket abstraction. 
+.Pp
+A protocol supports one of the socket abstractions detailed in
+.Xr socket 2 .
+A specific protocol may be accessed either by creating a
+socket of the appropriate type and protocol family, or
+by requesting the protocol explicitly when creating a socket.
+Protocols normally accept only one type of address format,
+usually determined by the addressing structure inherent in
+the design of the protocol family/network architecture.
+Certain semantics of the basic socket abstractions are
+protocol specific.  All protocols are expected to support
+the basic model for their particular socket type, but may,
+in addition, provide non-standard facilities or extensions
+to a mechanism.  For example, a protocol supporting the
+.Dv SOCK_STREAM
+abstraction may allow more than one byte of out-of-band
+data to be transmitted per out-of-band message.
+.Pp
+A network interface is similar to a device interface.
+Network interfaces comprise the lowest layer of the
+networking subsystem, interacting with the actual transport
+hardware.  An interface may support one or more protocol
+families and/or address formats.
+The SYNOPSIS section of each network interface
+entry gives a sample specification
+of the related drivers for use in providing
+a system description to the
+.Xr config 8
+program.
+The DIAGNOSTICS section lists messages which may appear on the console
+and/or in the system error log,
+.Pa /var/log/messages
+(see
+.Xr syslogd 8 ) ,
+due to errors in device operation.
+.Sh PROTOCOLS
+The system currently supports the
+Internet
+protocols, the Xerox Network Systems(tm) protocols,
+and some of the
+.Tn ISO OSI
+protocols.
+Raw socket interfaces are provided to the
+.Tn IP
+protocol
+layer of the
+Internet, and to the
+.Tn IDP
+protocol of Xerox
+.Tn NS .
+Consult the appropriate manual pages in this section for more
+information regarding the support for each protocol family.
+.Sh ADDRESSING
+Associated with each protocol family is an address
+format.  All network address adhere to a general structure,
+called a sockaddr, described below. However, each protocol
+imposes finer and more specific structure, generally renaming
+the variant, which is discussed in the protocol family manual
+page alluded to above.
+.Bd -literal -offset indent
+    struct sockaddr {
+	u_char	sa_len;
+    	u_char	sa_family;
+    	char	sa_data[14];
+};
+.Ed
+.Pp
+The field
+.Ar sa_len
+contains the total length of the of the structure,
+which may exceed 16 bytes.
+The following address values for
+.Ar sa_family
+are known to the system
+(and additional formats are defined for possible future implementation):
+.Bd -literal
+#define    AF_UNIX      1    /* local to host (pipes, portals) */
+#define    AF_INET      2    /* internetwork: UDP, TCP, etc. */
+#define    AF_NS        6    /* Xerox NS protocols */
+#define    AF_CCITT     10   /* CCITT protocols, X.25 etc */
+#define    AF_HYLINK    15   /* NSC Hyperchannel */
+#define    AF_ISO       18   /* ISO protocols */
+.Ed
+.Sh ROUTING
+.Tn UNIX
+provides some packet routing facilities.
+The kernel maintains a routing information database, which
+is used in selecting the appropriate network interface when
+transmitting packets.
+.Pp
+A user process (or possibly multiple co-operating processes)
+maintains this database by sending messages over a special kind
+of socket.
+This supplants fixed size
+.Xr ioctl 2
+used in earlier releases.
+.Pp
+This facility is described in
+.Xr route 4 .
+.Sh INTERFACES
+Each network interface in a system corresponds to a
+path through which messages may be sent and received.  A network
+interface usually has a hardware device associated with it, though
+certain interfaces such as the loopback interface,
+.Xr lo 4 ,
+do not.
+.Pp
+The following 
+.Xr ioctl
+calls may be used to manipulate network interfaces.
+The
+.Xr ioctl
+is made on a socket (typically of type
+.Dv SOCK_DGRAM )
+in the desired domain.
+Most of the requests supported in earlier releases 
+take an
+.Ar ifreq
+structure as its parameter.  This structure has the form
+.Bd -literal
+struct	ifreq {
+#define    IFNAMSIZ    16
+    char    ifr_name[IFNAMSIZE];        /* if name, e.g. "en0" */
+    union {
+        struct    sockaddr ifru_addr;
+        struct    sockaddr ifru_dstaddr;
+        struct    sockaddr ifru_broadaddr;
+        short     ifru_flags;
+        int       ifru_metric;
+        caddr_t   ifru_data;
+    } ifr_ifru;
+#define ifr_addr      ifr_ifru.ifru_addr    /* address */
+#define ifr_dstaddr   ifr_ifru.ifru_dstaddr /* other end of p-to-p link */
+#define ifr_broadaddr ifr_ifru.ifru_broadaddr /* broadcast address */
+#define ifr_flags     ifr_ifru.ifru_flags   /* flags */
+#define ifr_metric    ifr_ifru.ifru_metric  /* metric */
+#define ifr_data      ifr_ifru.ifru_data    /* for use by interface */
+};
+.Ed
+.Pp
+Calls which are now deprecated are:
+.Bl -tag -width SIOCGIFBRDADDR
+.It Dv SIOCSIFADDR
+Set interface address for protocol family.  Following the address
+assignment, the ``initialization'' routine for
+the interface is called.
+.It Dv SIOCSIFDSTADDR
+Set point to point address for protocol family and interface.
+.It Dv SIOCSIFBRDADDR
+Set broadcast address for protocol family and interface.
+.El
+.Pp
+.Xr Ioctl
+requests to obtain addresses and requests both to set and
+retrieve other data are still fully supported
+and use the
+.Ar ifreq
+structure:
+.Bl -tag -width SIOCGIFBRDADDR
+.It Dv SIOCGIFADDR
+Get interface address for protocol family.
+.It Dv SIOCGIFDSTADDR
+Get point to point address for protocol family and interface.
+.It Dv SIOCGIFBRDADDR
+Get broadcast address for protocol family and interface.
+.It Dv SIOCSIFFLAGS
+Set interface flags field.  If the interface is marked down,
+any processes currently routing packets through the interface
+are notified;
+some interfaces may be reset so that incoming packets are no longer received.
+When marked up again, the interface is reinitialized.
+.It Dv SIOCGIFFLAGS
+Get interface flags.
+.It Dv SIOCSIFMETRIC
+Set interface routing metric.
+The metric is used only by user-level routers.
+.It Dv SIOCGIFMETRIC
+Get interface metric.
+.El
+.Pp
+There are two requests that make use of a new structure:
+.Bl -tag -width SIOCGIFBRDADDR
+.It Dv SIOCAIFADDR
+An interface may have more than one address associated with it
+in some protocols.  This request provides a means to
+add additional addresses (or modify characteristics of the
+primary address if the default address for the address family
+is specified).  Rather than making separate calls to
+set destination or broadcast addresses, or network masks
+(now an integral feature of multiple protocols)
+a separate structure is used to specify all three facets simultaneously
+(see below).
+One would use a slightly tailored version of this struct specific
+to each family (replacing each sockaddr by one
+of the family-specific type).
+Where the sockaddr itself is larger than the
+default size, one needs to modify the
+.Xr ioctl
+identifier itself to include the total size, as described in
+.Xr ioctl .
+.It Dv SIOCDIFADDR
+This requests deletes the specified address from the list
+associated with an interface.  It also uses the
+.Ar if_aliasreq
+structure to allow for the possibility of protocols allowing
+multiple masks or destination addresses, and also adopts the
+convention that specification of the default address means
+to delete the first address for the interface belonging to
+the address family in which the original socket was opened.
+.It Dv SIOCGIFCONF
+Get interface configuration list.  This request takes an
+.Ar ifconf
+structure (see below) as a value-result parameter.  The 
+.Ar ifc_len
+field should be initially set to the size of the buffer
+pointed to by 
+.Ar ifc_buf .
+On return it will contain the length, in bytes, of the
+configuration list.
+.El
+.Bd -literal
+/*
+* Structure used in SIOCAIFCONF request.
+*/
+struct ifaliasreq {
+        char    ifra_name[IFNAMSIZ];   /* if name, e.g. "en0" */
+        struct  sockaddr        ifra_addr;
+        struct  sockaddr        ifra_broadaddr;
+        struct  sockaddr        ifra_mask;
+};
+.Ed
+.Pp
+.Bd -literal
+/*
+* Structure used in SIOCGIFCONF request.
+* Used to retrieve interface configuration
+* for machine (useful for programs which
+* must know all networks accessible).
+*/
+struct ifconf {
+    int   ifc_len;		/* size of associated buffer */
+    union {
+        caddr_t    ifcu_buf;
+        struct     ifreq *ifcu_req;
+    } ifc_ifcu;
+#define ifc_buf ifc_ifcu.ifcu_buf /* buffer address */
+#define ifc_req ifc_ifcu.ifcu_req /* array of structures returned */
+};
+.Ed
+.Sh SEE ALSO
+.Xr socket 2 ,
+.Xr ioctl 2 ,
+.Xr intro 4 ,
+.Xr config 8 ,
+.Xr routed 8
+.Sh HISTORY
+The
+.Nm netintro
+manual appeared in
+.Bx 4.3 tahoe .
diff --git a/share/man/man4/ns.4 b/share/man/man4/ns.4
new file mode 100644
index 0000000..18efeac
--- /dev/null
+++ b/share/man/man4/ns.4
@@ -0,0 +1,179 @@
+.\" Copyright (c) 1985, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)ns.4	8.2 (Berkeley) 11/30/93
+.\"
+.Dd November 30, 1993
+.Dt NS 4
+.Os BSD 4.3
+.Sh NAME
+.Nm ns
+.Nd Xerox Network Systems(tm) protocol family
+.Sh SYNOPSIS
+.Nm options NS
+.Nm options NSIP
+.Nm pseudo-device ns
+.Sh DESCRIPTION
+The
+.Tn NS
+protocol family is a collection of protocols
+layered atop the
+.Em Internet  Datagram  Protocol
+.Pq Tn IDP
+transport layer, and using the Xerox 
+.Tn NS
+address formats.
+The
+.Tn NS
+family provides protocol support for the
+.Dv SOCK_STREAM , SOCK_DGRAM , SOCK_SEQPACKET ,
+and
+.Dv SOCK_RAW
+socket types; the
+.Dv SOCK_RAW
+interface is a debugging tool, allowing you to trace all packets
+entering, (or with toggling kernel variable, additionally leaving) the local
+host.
+.Sh ADDRESSING
+.Tn NS
+addresses are 12 byte quantities, consisting of a 
+4 byte Network number, a 6 byte Host number and a 2 byte port number,
+all stored in network standard format.
+(on the
+.Tn VAX
+these are word and byte reversed; on the
+.Tn SUN 
+they are not
+reversed).  The include file
+.Aq Pa netns/ns.h
+defines the
+.Tn NS
+address as a structure containing unions (for quicker
+comparisons).
+.Pp
+Sockets in the Internet protocol family use the following
+addressing structure:
+.Bd -literal -offset indent
+struct sockaddr_ns {
+	short		sns_family;
+	struct ns_addr	sns_addr;
+	char		sns_zero[2];
+};
+.Ed
+.Pp
+where an
+.Ar ns_addr
+is composed as follows:
+.Bd -literal -offset indent
+union ns_host {
+	u_char		c_host[6];
+	u_short		s_host[3];
+};
+
+union ns_net {
+	u_char		c_net[4];
+	u_short		s_net[2];
+};
+
+struct ns_addr {
+	union ns_net	x_net;
+	union ns_host	x_host;
+	u_short	x_port;
+};
+.Ed
+.Pp
+Sockets may be created with an address of all zeroes to effect
+.Dq wildcard
+matching on incoming messages.
+The local port address specified in a
+.Xr bind 2
+call is restricted to be greater than
+.Dv NSPORT_RESERVED
+(=3000, in
+.Aq Pa netns/ns.h )
+unless the creating process is running
+as the super-user, providing a space of protected port numbers.
+.Sh PROTOCOLS
+The
+.Tn NS
+protocol family supported by the operating system
+is comprised of
+the Internet Datagram Protocol
+.Pq Tn IDP
+.Xr idp 4 ,
+Error Protocol (available through
+.Tn IDP ) ,
+and
+Sequenced Packet Protocol
+.Pq Tn SPP
+.Xr spp 4 .
+.Pp
+.Tn SPP
+is used to support the
+.Dv SOCK_STREAM
+and
+.Dv SOCK_SEQPACKET
+abstraction,
+while
+.Tn IDP
+is used to support the
+.Dv SOCK_DGRAM
+abstraction.
+The Error protocol is responded to by the kernel
+to handle and report errors in protocol processing;
+it is, however,
+only accessible to user programs through heroic actions.
+.Sh SEE ALSO
+.Xr intro 3 ,
+.Xr byteorder 3 ,
+.Xr gethostbyname 3 ,
+.Xr getnetent 3 ,
+.Xr getprotoent 3 ,
+.Xr getservent 3 ,
+.Xr ns 3 ,
+.Xr intro 4 ,
+.Xr spp 4 ,
+.Xr idp 4 ,
+.Xr nsip 4
+.Rs
+.%T "Internet Transport Protocols"
+.%R Xerox Corporation document XSIS
+.%N 028112
+.Re
+.Rs
+.%T "An Advanced 4.3 BSD Interprocess Communication Tutorial"
+.Re
+.Sh HISTORY
+The
+.Nm
+protocol family
+appeared in
+.Bx 4.3 .
diff --git a/share/man/man4/nsip.4 b/share/man/man4/nsip.4
new file mode 100644
index 0000000..6d71782
--- /dev/null
+++ b/share/man/man4/nsip.4
@@ -0,0 +1,128 @@
+.\" Copyright (c) 1985, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)nsip.4	8.2 (Berkeley) 11/30/93
+.\"
+.Dd November 30, 1993
+.Dt NSIP 4
+.Os BSD 4.3
+.Sh NAME
+.Nm nsip
+.Nd software network interface encapsulating NS packets in IP packets
+.Sh SYNOPSIS
+.Cd options NSIP
+.Fd #include <netns/ns_if.h>
+.Sh DESCRIPTION
+The
+.Nm nsip
+interface is a software mechanism which may be
+used to transmit Xerox
+.Tn NS Ns (tm)
+packets through otherwise uncooperative
+networks.
+It functions by prepending an
+.Tn IP
+header, and resubmitting the packet
+through the
+.Tn UNIX
+.Tn IP
+machinery.
+.Pp
+The super-user can advise the operating system of a willing partner
+by naming an
+.Tn IP
+address to be associated with an
+.Tn NS
+address.
+Presently, only specific hosts pairs are allowed, and for each host
+pair, an artificial point-to-point interface is constructed.
+At some future date,
+.Tn IP
+broadcast addresses or hosts may be paired
+with
+.Tn NS
+networks or hosts.
+.Pp
+Specifically, a socket option of
+.Dv SO_NSIP_ROUTE
+is set on a socket
+of family
+.Dv AF_NS ,
+type
+.Dv SOCK_DGRAM ,
+passing the following structure:
+.Bd -literal
+struct nsip_req {
+	struct sockaddr rq_ns;	/* must be ns format destination */
+	struct sockaddr rq_ip;	/* must be ip format gateway */
+	short rq_flags;
+};
+.Ed
+.Sh DIAGNOSTICS
+.Bl -diag
+.It nsip%d: can't handle af%d.
+The interface was handed
+a message with addresses formatted in an unsuitable address
+family; the packet was dropped.
+.El
+.Sh SEE ALSO
+.Xr intro 4 ,
+.Xr ns 4
+.Sh HISTORY
+The
+.Nm
+interface appeared in
+.Bx 4.3 .
+.Sh BUGS
+It is absurd to have a separate pseudo-device for each pt-to-pt
+link.
+There is no way to change the
+.Tn IP
+address for an
+.Tn NS
+host once the
+encapsulation interface is set up.
+The request should honor flags of
+.Dv RTF_GATEWAY
+to indicate
+remote networks, and the absence of
+.Dv RTF_UP
+should be a clue
+to remove that partner.
+This was intended to postpone the necessity of rewriting reverse
+.Tn ARP
+for the 
+.Xr en 4
+device, and to allow passing
+.Tn XNS
+packets through an
+Arpanet-Milnet gateway, to facilitate testing between some co-operating
+universities.
diff --git a/share/man/man4/null.4 b/share/man/man4/null.4
new file mode 100644
index 0000000..583e109
--- /dev/null
+++ b/share/man/man4/null.4
@@ -0,0 +1,56 @@
+.\" Copyright (c) 1991, 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
+.\" 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.
+.\"
+.\"	@(#)null.4	8.1 (Berkeley) 6/5/93
+.\"
+.Dd June 5, 1993
+.Dt NULL 4
+.Os
+.Sh NAME
+.Nm null
+.Nd the null device
+.Sh DESCRIPTION
+The
+.Nm
+device accepts and reads data as any ordinary (and willing)
+file \-
+but throws it away. The length of the
+.Nm null
+device is always zero.
+.Sh FILES
+.Bl -tag -width /dev/null
+.It Pa /dev/null
+.El
+.Sh HISTORY
+A
+.Nm
+device appeared in
+.At v7 .
diff --git a/share/man/man4/pty.4 b/share/man/man4/pty.4
new file mode 100644
index 0000000..dd982c3
--- /dev/null
+++ b/share/man/man4/pty.4
@@ -0,0 +1,212 @@
+.\" Copyright (c) 1983, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)pty.4	8.2 (Berkeley) 11/30/93
+.\"
+.Dd November 30, 1993
+.Dt PTY 4
+.Os BSD 4.2
+.Sh NAME
+.Nm pty
+.Nd pseudo terminal driver
+.Sh SYNOPSIS
+.Nm pseudo-device pty
+.Op Ar count
+.Sh DESCRIPTION
+The
+.Xr pty
+driver provides support for a device-pair termed a
+.Em pseudo terminal .
+A pseudo terminal is a pair of character devices, a
+.Em master
+device and a
+.Em slave
+device.  The slave device provides to a process
+an interface identical
+to that described in
+.Xr tty 4 .
+However, whereas all other devices which provide the 
+interface described in
+.Xr tty 4
+have a hardware device of some sort behind them, the slave
+device has, instead, another process manipulating
+it through the master half of the pseudo terminal.
+That is, anything written on the master device is
+given to the slave device as input and anything written
+on the slave device is presented as input on the master
+device.
+.Pp
+In configuring, if an optional
+.Ar count
+is given in
+the specification, that number of pseudo terminal pairs are configured;
+the default count is 32.
+.Pp
+The following 
+.Xr ioctl 2
+calls apply only to pseudo terminals:
+.Bl -tag -width TIOCREMOTE
+.It Dv TIOCSTOP
+Stops output to a terminal (e.g. like typing
+.Ql ^S ) .
+Takes
+no parameter.
+.It Dv TIOCSTART
+Restarts output (stopped by
+.Dv TIOCSTOP
+or by typing
+.Ql ^S ) .
+Takes no parameter.
+.It Dv TIOCPKT
+Enable/disable 
+.Em packet
+mode.  Packet mode is enabled by specifying (by reference)
+a nonzero parameter and disabled by specifying (by reference)
+a zero parameter.  When applied to the master side of a pseudo
+terminal, each subsequent 
+.Xr read
+from the terminal will return data written on the slave part of
+the pseudo terminal preceded by a zero byte (symbolically
+defined as
+.Dv TIOCPKT_DATA ) ,
+or a single byte reflecting control
+status information.  In the latter case, the byte is an inclusive-or
+of zero or more of the bits:
+.Bl -tag -width TIOCPKT_FLUSHWRITE
+.It Dv TIOCPKT_FLUSHREAD
+whenever the read queue for the terminal is flushed.
+.It Dv TIOCPKT_FLUSHWRITE
+whenever the write queue for the terminal is flushed.
+.It Dv TIOCPKT_STOP
+whenever output to the terminal is stopped a la
+.Ql ^S .
+.It Dv TIOCPKT_START
+whenever output to the terminal is restarted.
+.It Dv TIOCPKT_DOSTOP
+whenever 
+.Em t_stopc
+is
+.Ql ^S
+and 
+.Em t_startc
+is
+.Ql ^Q .
+.It Dv TIOCPKT_NOSTOP
+whenever the start and stop characters are not
+.Ql ^S/^Q .
+.Pp
+While this mode is in use, the presence of control status information
+to be read from the master side may be detected by a
+.Xr select 2
+for exceptional conditions.
+.Pp
+This mode is used by
+.Xr rlogin 1
+and
+.Xr rlogind 8
+to implement a remote-echoed, locally
+.Ql ^S/^Q
+flow-controlled
+remote login with proper back-flushing of output; it can be
+used by other similar programs.
+.El
+.It Dv TIOCUCNTL
+Enable/disable a mode that allows a small number of simple user
+.Xr ioctl
+commands to be passed through the pseudo-terminal,
+using a protocol similar to that of
+.Dv TIOCPKT .
+The
+.Dv TIOCUCNTL
+and
+.Dv TIOCPKT
+modes are mutually exclusive.
+This mode is enabled from the master side of a pseudo terminal
+by specifying (by reference)
+a nonzero parameter and disabled by specifying (by reference)
+a zero parameter.
+Each subsequent 
+.Xr read
+from the master side will return data written on the slave part of
+the pseudo terminal preceded by a zero byte,
+or a single byte reflecting a user control operation on the slave side.
+A user control command consists of a special
+.Xr ioctl
+operation with no data; the command is given as
+.Dv UIOCCMD Ns (n) ,
+where
+.Ar n
+is a number in the range 1-255.
+The operation value
+.Ar n
+will be received as a single byte on the next
+.Xr read
+from the master side.
+The
+.Xr ioctl
+.Dv UIOCCMD Ns (0)
+is a no-op that may be used to probe for
+the existence of this facility.
+As with
+.Dv TIOCPKT
+mode, command operations may be detected with a
+.Xr select
+for exceptional conditions.
+.It Dv TIOCREMOTE
+A mode for the master half of a pseudo terminal, independent
+of
+.Dv TIOCPKT .
+This mode causes input to the pseudo terminal
+to be flow controlled and not input edited (regardless of the
+terminal mode).  Each write to the control terminal produces
+a record boundary for the process reading the terminal.  In
+normal usage, a write of data is like the data typed as a line
+on the terminal; a write of 0 bytes is like typing an end-of-file
+character.
+.Dv TIOCREMOTE
+can be used when doing remote line
+editing in a window manager, or whenever flow controlled input
+is required.
+.El
+.Sh FILES
+.Bl -tag -width /dev/tty[p-r][0-9a-f]x -compact
+.It Pa /dev/pty[p-r][0-9a-f]
+master pseudo terminals
+.It Pa /dev/tty[p-r][0-9a-f]
+slave pseudo terminals
+.El
+.Sh DIAGNOSTICS
+None.
+.Sh HISTORY
+The
+.Nm
+driver appeared in
+.Bx 4.2 .
diff --git a/share/man/man4/route.4 b/share/man/man4/route.4
new file mode 100644
index 0000000..a5425ec
--- /dev/null
+++ b/share/man/man4/route.4
@@ -0,0 +1,270 @@
+.\" Copyright (c) 1990, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)route.4	8.6 (Berkeley) 4/19/94
+.\"
+.Dd April 19, 1994
+.Dt ROUTE 4
+.Os
+.Sh NAME
+.Nm route 
+.Nd kernel packet forwarding database
+.Sh SYNOPSIS
+.Fd #include <sys/socket.h>
+.Fd #include <net/if.h>
+.Fd #include <net/route.h>
+.Ft int
+.Fn socket PF_ROUTE SOCK_RAW "int family"
+.Sh DESCRIPTION
+.Tn UNIX
+provides some packet routing facilities.
+The kernel maintains a routing information database, which
+is used in selecting the appropriate network interface when
+transmitting packets.
+.Pp
+A user process (or possibly multiple co-operating processes)
+maintains this database by sending messages over a special kind
+of socket.
+This supplants fixed size
+.Xr ioctl 2 Ns 's
+used in earlier releases.
+Routing table changes may only be carried out by the super user.
+.Pp
+The operating system may spontaneously emit routing messages in response
+to external events, such as receipt of a re-direct, or failure to
+locate a suitable route for a request.
+The message types are described in greater detail below.
+.Pp
+Routing database entries come in two flavors: for a specific
+host, or for all hosts on a generic subnetwork (as specified
+by a bit mask and value under the mask.
+The effect of wildcard or default route may be achieved by using
+a mask of all zeros, and there may be hierarchical routes.
+.Pp
+When the system is booted and addresses are assigned
+to the network interfaces, each protocol family
+installs a routing table entry for each interface when it is ready for traffic.
+Normally the protocol specifies the route
+through each interface as a
+.Dq direct
+connection to the destination host
+or network.  If the route is direct, the transport layer of
+a protocol family usually requests the packet be sent to the
+same host specified in the packet.  Otherwise, the interface
+is requested to address the packet to the gateway listed in the routing entry
+(i.e. the packet is forwarded).
+.Pp
+When routing a packet,
+the kernel will attempt to find 
+the most specific route matching the destination.
+(If there are two different mask and value-under-the-mask pairs
+that match, the more specific is the one with more bits in the mask.
+A route to a host is regarded as being supplied with a mask of
+as many ones as there are bits in the destination).
+If no entry is found, the destination is declared to be unreachable,
+and a routing\-miss message is generated if there are any
+listers on the routing control socket described below.
+.Pp
+A wildcard routing entry is specified with a zero
+destination address value, and a mask of all zeroes.
+Wildcard routes will be used
+when the system fails to find other routes matching the
+destination.  The combination of wildcard
+routes and routing redirects can provide an economical
+mechanism for routing traffic.
+.Pp
+One opens the channel for passing routing control messages
+by using the socket call shown in the synopsis above:
+.Pp
+The
+.Fa family
+parameter may be
+.Dv AF_UNSPEC
+which will provide
+routing information for all address families, or can be restricted
+to a specific address family by specifying which one is desired.
+There can be more than one routing socket open per system.
+.Pp
+Messages are formed by a header followed by a small
+number of sockadders (now variable length particularly
+in the
+.Tn ISO
+case), interpreted by position, and delimited
+by the new length entry in the sockaddr.
+An example of a message with four addresses might be an
+.Tn ISO
+redirect:
+Destination, Netmask, Gateway, and Author of the redirect.
+The interpretation of which address are present is given by a
+bit mask within the header, and the sequence is least significant
+to most significant bit within the vector.
+.Pp
+Any messages sent to the kernel are returned, and copies are sent
+to all interested listeners.  The kernel will provide the process
+id. for the sender, and the sender may use an additional sequence
+field to distinguish between outstanding messages.  However,
+message replies may be lost when kernel buffers are exhausted.
+.Pp
+The kernel may reject certain messages, and will indicate this
+by filling in the
+.Ar rtm_errno
+field.
+The routing code returns
+.Dv EEXIST
+if
+requested to duplicate an existing entry,
+.Dv ESRCH
+if
+requested to delete a non-existent entry,
+or
+.Dv ENOBUFS
+if insufficient resources were available
+to install a new route.
+In the current implementation, all routing process run locally,
+and the values for
+.Ar rtm_errno
+are available through the normal
+.Em errno
+mechanism, even if the routing reply message is lost.
+.Pp
+A process may avoid the expense of reading replies to
+its own messages by issuing a
+.Xr setsockopt 2
+call indicating that the
+.Dv SO_USELOOPBACK
+option
+at the
+.Dv SOL_SOCKET
+level is to be turned off.
+A process may ignore all messages from the routing socket
+by doing a 
+.Xr shutdown 2
+system call for further input.
+.Pp
+If a route is in use when it is deleted,
+the routing entry will be marked down and removed from the routing table,
+but the resources associated with it will not
+be reclaimed until all references to it are released. 
+User processes can obtain information about the routing
+entry to a specific destination by using a
+.Dv RTM_GET
+message,
+or by reading the
+.Pa /dev/kmem
+device, or by issuing a
+.Xr getkerninfo 2
+system call.
+.Pp
+Messages include:
+.Bd -literal
+#define	RTM_ADD		0x1    /* Add Route */
+#define	RTM_DELETE	0x2    /* Delete Route */
+#define	RTM_CHANGE	0x3    /* Change Metrics, Flags, or Gateway */
+#define	RTM_GET		0x4    /* Report Information */
+#define	RTM_LOOSING	0x5    /* Kernel Suspects Partitioning */
+#define	RTM_REDIRECT	0x6    /* Told to use different route */
+#define	RTM_MISS	0x7    /* Lookup failed on this address */
+#define	RTM_RESOLVE	0xb    /* request to resolve dst to LL addr */
+.Ed
+.Pp
+A message header consists of:
+.Bd -literal
+struct rt_msghdr {
+    u_short rmt_msglen;  /* to skip over non-understood messages */
+    u_char  rtm_version; /* future binary compatibility */
+    u_char  rtm_type;    /* message type */
+    u_short rmt_index;   /* index for associated ifp */
+    pid_t   rmt_pid;     /* identify sender */
+    int     rtm_addrs;   /* bitmask identifying sockaddrs in msg */
+    int     rtm_seq;     /* for sender to identify action */
+    int     rtm_errno;   /* why failed */
+    int     rtm_flags;   /* flags, incl kern & message, e.g. DONE */
+    int     rtm_use;     /* from rtentry */
+    u_long  rtm_inits;   /* which values we are initializing */
+    struct  rt_metrics rtm_rmx;	/* metrics themselves */
+};
+.Ed
+.Pp
+where
+.Bd -literal
+struct rt_metrics {
+    u_long rmx_locks;     /* Kernel must leave these values alone */
+    u_long rmx_mtu;       /* MTU for this path */
+    u_long rmx_hopcount;  /* max hops expected */
+    u_long rmx_expire;    /* lifetime for route, e.g. redirect */
+    u_long rmx_recvpipe;  /* inbound delay-bandwith product */
+    u_long rmx_sendpipe;  /* outbound delay-bandwith product */
+    u_long rmx_ssthresh;  /* outbound gateway buffer limit */
+    u_long rmx_rtt;       /* estimated round trip time */
+    u_long rmx_rttvar;    /* estimated rtt variance */
+};
+.Ed
+.Pp
+Flags include the values:
+.Bd -literal
+#define	RTF_UP        0x1       /* route usable */
+#define	RTF_GATEWAY   0x2       /* destination is a gateway */
+#define	RTF_HOST      0x4       /* host entry (net otherwise) */
+#define	RTF_REJECT    0x8       /* host or net unreachable */
+#define	RTF_DYNAMIC   0x10      /* created dynamically (by redirect) */
+#define	RTF_MODIFIED  0x20      /* modified dynamically (by redirect) */
+#define	RTF_DONE      0x40      /* message confirmed */
+#define	RTF_MASK      0x80      /* subnet mask present */
+#define	RTF_CLONING   0x100     /* generate new routes on use */
+#define	RTF_XRESOLVE  0x200     /* external daemon resolves name */
+#define	RTF_LLINFO    0x400     /* generated by ARP or ESIS */
+#define	RTF_STATIC    0x800     /* manually added */
+#define	RTF_BLACKHOLE 0x1000    /* just discard pkts (during updates) */
+#define	RTF_PROTO2    0x4000    /* protocol specific routing flag #1 */
+#define	RTF_PROTO1    0x8000    /* protocol specific routing flag #2 */
+.Ed
+.Pp
+Specifiers for metric values in rmx_locks and rtm_inits are:
+.Bd -literal
+#define	RTV_SSTHRESH  0x1    /* init or lock _ssthresh */
+#define	RTV_RPIPE     0x2    /* init or lock _recvpipe */
+#define	RTV_SPIPE     0x4    /* init or lock _sendpipe */
+#define	RTV_HOPCOUNT  0x8    /* init or lock _hopcount */
+#define	RTV_RTT       0x10   /* init or lock _rtt */
+#define	RTV_RTTVAR    0x20   /* init or lock _rttvar */
+#define	RTV_MTU       0x40   /* init or lock _mtu */
+.Ed
+.Pp
+Specifiers for which addresses are present in the messages are:
+.Bd -literal
+#define RTA_DST       0x1    /* destination sockaddr present */
+#define RTA_GATEWAY   0x2    /* gateway sockaddr present */
+#define RTA_NETMASK   0x4    /* netmask sockaddr present */
+#define RTA_GENMASK   0x8    /* cloning mask sockaddr present */
+#define RTA_IFP       0x10   /* interface name sockaddr present */
+#define RTA_IFA       0x20   /* interface addr sockaddr present */
+#define RTA_AUTHOR    0x40   /* sockaddr for author of redirect */
+.Ed
diff --git a/share/man/man4/spp.4 b/share/man/man4/spp.4
new file mode 100644
index 0000000..d749e2e
--- /dev/null
+++ b/share/man/man4/spp.4
@@ -0,0 +1,191 @@
+.\" Copyright (c) 1985, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)spp.4	8.2 (Berkeley) 4/19/94
+.\"
+.Dd April 19, 1994
+.Dt SPP 4
+.Os BSD 4.3
+.Sh NAME
+.Nm spp
+.Nd Xerox Sequenced Packet Protocol
+.Sh SYNOPSIS
+.Fd #include <sys/socket.h>
+.Fd #include <netns/ns.h>
+.Fd #include <netns/sp.h>
+.Ft int
+.Fn socket AF_NS SOCK_STREAM 0
+.Ft int
+.Fn socket AF_NS SOCK_SEQPACKET 0
+.Sh DESCRIPTION
+The
+.Tn SPP
+protocol provides reliable, flow-controlled, two-way
+transmission of data.  It is a byte-stream protocol used to
+support the
+.Dv SOCK_STREAM
+abstraction.
+.Tn SPP
+uses the standard
+.Tn NS Ns (tm)
+address formats.
+.Pp
+Sockets utilizing the
+.Tn SPP
+protocol are either
+.Dq active
+or
+.Dq passive .
+Active sockets initiate connections to passive
+sockets.  By default
+.Tn SPP
+sockets are created active; to create a
+passive socket the
+.Xr listen 2
+system call must be used
+after binding the socket with the
+.Xr bind 2
+system call.  Only
+passive sockets may use the 
+.Xr accept 2
+call to accept incoming connections.  Only active sockets may
+use the
+.Xr connect 2
+call to initiate connections.
+.Pp
+Passive sockets may
+.Dq underspecify
+their location to match
+incoming connection requests from multiple networks.  This
+technique, termed
+.Dq wildcard addressing ,
+allows a single
+server to provide service to clients on multiple networks.
+To create a socket which listens on all networks, the
+.Tn NS
+address of all zeroes must be bound.
+The
+.Tn SPP
+port may still be specified
+at this time; if the port is not specified the system will assign one.
+Once a connection has been established the socket's address is
+fixed by the peer entity's location.   The address assigned the
+socket is the address associated with the network interface
+through which packets are being transmitted and received.  Normally
+this address corresponds to the peer entity's network.
+.Pp
+If the
+.Dv SOCK_SEQPACKET
+socket type is specified,
+each packet received has the actual 12 byte sequenced packet header
+left for the user to inspect:
+.Bd -literal -offset indent
+struct sphdr {
+	u_char		sp_cc;	/* connection control */
+#define	SP_EM	0x10		/* end of message */
+	u_char		sp_dt;	/* datastream type */
+	u_short		sp_sid;
+	u_short		sp_did;
+	u_short		sp_seq;
+	u_short		sp_ack;
+	u_short		sp_alo;
+};
+.Ed
+.Pp
+This facilitates the implementation of higher level Xerox protocols
+which make use of the data stream type field and the end of message bit.
+Conversely, the user is required to supply a 12 byte header,
+the only part of which inspected is the data stream type and end of message
+fields.
+.Pp
+For either socket type,
+packets received with the Attention bit sent are interpreted as
+out of band data.  Data sent with
+.Dq send(..., ..., ..., Dv MSG_OOB )
+cause the attention bit to be set.
+.Sh DIAGNOSTICS
+A socket operation may fail with one of the following errors returned:
+.Bl -tag -width [EADDRNOTAVAIL]
+.It Bq Er EISCONN
+when trying to establish a connection on a socket which
+already has one;
+.It Bq Er ENOBUFS
+when the system runs out of memory for
+an internal data structure;
+.It Bq Er ETIMEDOUT
+when a connection was dropped
+due to excessive retransmissions;
+.It Bq Er ECONNRESET
+when the remote peer
+forces the connection to be closed;
+.It Bq Er ECONNREFUSED
+when the remote
+peer actively refuses connection establishment (usually because
+no process is listening to the port);
+.It Bq Er EADDRINUSE
+when an attempt
+is made to create a socket with a port which has already been
+allocated;
+.It Bq Er EADDRNOTAVAIL
+when an attempt is made to create a 
+socket with a network address for which no network interface
+exists.
+.El
+.Sh SOCKET OPTIONS
+.Bl -tag -width SO_DEFAULT_HEADERS
+.It Dv SO_DEFAULT_HEADERS
+when set, this determines the data stream type and whether
+the end of message bit is to be set on every ensuing packet.
+.It Dv SO_MTU
+This specifies the maximum amount of user data in a single packet.
+The default is 576 bytes - sizeof(struct spidp).  This quantity
+affects windowing \- increasing it without increasing the amount
+of buffering in the socket will lower the number of unread packets
+accepted.  Anything larger than the default will not be forwarded
+by a bona fide
+.Tn XEROX
+product internetwork router.
+The data argument for the setsockopt call must be
+an unsigned short.
+.El
+.Sh SEE ALSO
+.Xr intro 4 ,
+.Xr ns 4
+.Sh HISTORY
+The
+.Nm
+protocol appeared in
+.Bx 4.3 .
+.Sh BUGS
+There should be some way to reflect record boundaries in
+a stream.
+For stream mode, there should be an option to get the data stream type of
+the record the user process is about to receive.
diff --git a/share/man/man4/tcp.4 b/share/man/man4/tcp.4
new file mode 100644
index 0000000..21f49d5
--- /dev/null
+++ b/share/man/man4/tcp.4
@@ -0,0 +1,178 @@
+.\" Copyright (c) 1983, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)tcp.4	8.1 (Berkeley) 6/5/93
+.\"
+.Dd June 5, 1993
+.Dt TCP 4
+.Os BSD 4.2
+.Sh NAME
+.Nm tcp
+.Nd Internet Transmission Control Protocol
+.Sh SYNOPSIS
+.Fd #include <sys/socket.h>
+.Fd #include <netinet/in.h>
+.Ft int
+.Fn socket AF_INET SOCK_STREAM 0
+.Sh DESCRIPTION
+The
+.Tn TCP
+protocol provides reliable, flow-controlled, two-way
+transmission of data.  It is a byte-stream protocol used to
+support the
+.Dv SOCK_STREAM
+abstraction.  TCP uses the standard
+Internet address format and, in addition, provides a per-host
+collection of
+.Dq port addresses .
+Thus, each address is composed
+of an Internet address specifying the host and network, with
+a specific
+.Tn TCP
+port on the host identifying the peer entity.
+.Pp
+Sockets utilizing the tcp protocol are either
+.Dq active
+or
+.Dq passive .
+Active sockets initiate connections to passive
+sockets.  By default
+.Tn TCP
+sockets are created active; to create a
+passive socket the
+.Xr listen 2
+system call must be used
+after binding the socket with the
+.Xr bind 2
+system call.  Only
+passive sockets may use the 
+.Xr accept 2
+call to accept incoming connections.  Only active sockets may
+use the
+.Xr connect 2
+call to initiate connections.
+.Pp
+Passive sockets may
+.Dq underspecify
+their location to match
+incoming connection requests from multiple networks.  This
+technique, termed
+.Dq wildcard addressing ,
+allows a single
+server to provide service to clients on multiple networks.
+To create a socket which listens on all networks, the Internet
+address
+.Dv INADDR_ANY
+must be bound.  The
+.Tn TCP
+port may still be specified
+at this time; if the port is not specified the system will assign one.
+Once a connection has been established the socket's address is
+fixed by the peer entity's location.   The address assigned the
+socket is the address associated with the network interface
+through which packets are being transmitted and received.  Normally
+this address corresponds to the peer entity's network.
+.Pp
+.Tn TCP
+supports one socket option which is set with
+.Xr setsockopt 2
+and tested with
+.Xr getsockopt 2 .
+Under most circumstances,
+.Tn TCP
+sends data when it is presented;
+when outstanding data has not yet been acknowledged, it gathers
+small amounts of output to be sent in a single packet once
+an acknowledgement is received.
+For a small number of clients, such as window systems
+that send a stream of mouse events which receive no replies,
+this packetization may cause significant delays.
+Therefore,
+.Tn TCP
+provides a boolean option,
+.Dv TCP_NODELAY
+(from
+.Aq Pa netinet/tcp.h ,
+to defeat this algorithm.
+The option level for the
+.Xr setsockopt
+call is the protocol number for
+.Tn TCP ,
+available from
+.Xr getprotobyname 3 .
+.Pp
+Options at the
+.Tn IP
+transport level may be used with
+.Tn TCP ;
+see
+.Xr ip 4 .
+Incoming connection requests that are source-routed are noted,
+and the reverse source route is used in responding.
+.Sh DIAGNOSTICS
+A socket operation may fail with one of the following errors returned:
+.Bl -tag -width [EADDRNOTAVAIL]
+.It Bq Er EISCONN
+when trying to establish a connection on a socket which
+already has one;
+.It Bq Er ENOBUFS
+when the system runs out of memory for
+an internal data structure;
+.It Bq Er ETIMEDOUT
+when a connection was dropped
+due to excessive retransmissions;
+.It Bq Er ECONNRESET
+when the remote peer
+forces the connection to be closed;
+.It Bq Er ECONNREFUSED
+when the remote
+peer actively refuses connection establishment (usually because
+no process is listening to the port);
+.It Bq Er EADDRINUSE
+when an attempt
+is made to create a socket with a port which has already been
+allocated;
+.It Bq Er EADDRNOTAVAIL
+when an attempt is made to create a 
+socket with a network address for which no network interface
+exists.
+.El
+.Sh SEE ALSO
+.Xr getsockopt 2 ,
+.Xr socket 2 ,
+.Xr intro 4 ,
+.Xr inet 4 ,
+.Xr ip 4
+.Sh HISTORY
+The
+.Nm
+protocol stack appeared in
+.Bx 4.2 .
diff --git a/share/man/man4/termios.4 b/share/man/man4/termios.4
new file mode 100644
index 0000000..72e9710
--- /dev/null
+++ b/share/man/man4/termios.4
@@ -0,0 +1,1411 @@
+.\" Copyright (c) 1991, 1992, 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
+.\" 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.
+.\"
+.\"	@(#)termios.4	8.4 (Berkeley) 4/19/94
+.\"
+.Dd April 19, 1994
+.Dt TERMIOS 4
+.Os BSD 4
+.Sh NAME
+.Nm termios
+.Nd general terminal line discipline
+.Sh SYNOPSIS
+.Fd #include <termios.h>
+.Sh DESCRIPTION
+This describes a general terminal line discipline that is
+supported on tty asynchronous communication ports.
+.Ss Opening a Terminal Device File
+When a terminal file is opened, it normally causes the process to wait
+until a connection is established.  For most hardware, the presence
+of a connection is indicated by the assertion of the hardware
+.Dv CARRIER line.
+If the termios structure associated with the terminal file has the
+.Dv CLOCAL
+flag set in the cflag, or if the
+.Dv O_NONBLOCK
+flag is set
+in the
+.Xr open 2
+call, then the open will succeed even without
+a connection being present.
+In practice, applications
+seldom open these files; they are opened by special programs, such
+as
+.Xr getty 2
+or
+.Xr rlogind 2 ,
+and become
+an application's standard input, output, and error files.
+.Ss Job Control in a Nutshell
+Every process is associated with a particular process group and session.
+The grouping is hierarchical: every member of a particular process group is a
+member of the same session.  This structuring is used in managing groups
+of related processes for purposes of
+.\" .Gw "job control" ;
+.Em "job control" ;
+that is, the
+ability from the keyboard (or from program control) to simultaneously
+stop or restart
+a complex command (a command composed of one or more related
+processes).  The grouping into process groups allows delivering
+of signals that stop or start the group as a whole, along with
+arbitrating which process group has access to the single controlling
+terminal.  The grouping at a higher layer into sessions is to restrict
+the job control related signals and system calls to within processes
+resulting from a particular instance of a "login".  Typically, a session
+is created when a user logs in, and the login terminal is setup
+to be the controlling terminal; all processes spawned from that
+login shell are in the same session, and inherit the controlling
+terminal.
+A job control shell
+operating interactively (that is, reading commands from a terminal)
+normally groups related processes together by placing them into the
+same process group.  A set of processes in the same process group
+is collectively referred to as a "job". When the foreground process
+group of the terminal is the same as the process group of a particular
+job, that job is said to be in the "foreground".  When the process
+group of the terminal is different than the process group of
+a job (but is still the controlling terminal), that job is said
+to be in the "background".  Normally the
+shell reads a command and starts the job that implements that
+command.  If the command is to be started in the foreground (typical), it
+sets the process group of the terminal to the process group
+of the started job, waits for the job to complete, and then
+sets the process group of the terminal back to its own process
+group (it puts itself into the foreground).  If the job is to
+be started in the background (as denoted by the shell operator "&"),
+it never changes the process group of the terminal and doesn't
+wait for the job to complete (that is, it immediately attempts to read the next
+command).  If the job is started in the foreground, the user may
+type a key (usually
+.Ql \&^Z )
+which generates the terminal stop signal
+.Pq Dv SIGTSTP
+and has the affect of stopping the entire job.
+The shell will notice that the job stopped, and will resume running after
+placing itself in the foreground.
+The shell also has commands for placing stopped jobs in the background,
+and for placing stopped or background jobs into the foreground.
+.Ss Orphaned Process Groups
+An orphaned process group is a process group that has no process
+whose parent is in a different process group, yet is in the same
+session.  Conceptually it means a process group that doesn't have
+a parent that could do anything if it were to be stopped.  For example,
+the initial login shell is typically in an orphaned process group.
+Orphaned process groups are immune to keyboard generated stop
+signals and job control signals resulting from reads or writes to the
+controlling terminal.
+.Ss The Controlling Terminal
+A terminal may belong to a process as its controlling terminal.  Each
+process of a session that has a controlling terminal has the same
+controlling terminal.  A terminal may be the controlling terminal for at
+most one session.  The controlling terminal for a session is allocated by
+the session leader by issuing the
+.Dv TIOCSCTTY
+ioctl.  A controlling terminal
+is never acquired by merely opening a terminal device file.
+When a controlling terminal becomes
+associated with a session, its foreground process group is set to
+the process group of the session leader.
+.Pp
+The controlling terminal is inherited by a child process during a
+.Xr fork 2
+function call.  A process relinquishes its controlling terminal when it
+creates a new session with the
+.Xd setsid 2
+function; other processes
+remaining in the old session that had this terminal as their controlling
+terminal continue to have it.
+A process does not relinquish its
+controlling terminal simply by closing all of its file descriptors
+associated with the controlling terminal if other processes continue to
+have it open.
+.Pp
+When a controlling process terminates, the controlling terminal is
+disassociated from the current session, allowing it to be acquired by a
+new session leader.  Subsequent access to the terminal by other processes
+in the earlier session will be denied, with attempts to access the
+terminal treated as if modem disconnect had been sensed.
+.Ss Terminal Access Control
+If a process is in the foreground process group of its controlling
+terminal, read operations are allowed.
+Any attempts by a process
+in a background process group to read from its controlling terminal
+causes a
+.Dv SIGTTIN
+signal to be sent to
+the process's group
+unless one of the
+following special cases apply:  If the reading process is ignoring or
+blocking the
+.Dv SIGTTIN signal, or if the process group of the reading
+process is orphaned, the
+.Xr read 2
+returns -1 with
+.Va errno set to
+.Er Dv EIO
+and no
+signal is sent.  The default action of the
+.Dv SIGTTIN
+signal is to stop the
+process to which it is sent.
+.Pp
+If a process is in the foreground process group of its controlling
+terminal, write operations are allowed.
+Attempts by a process in a background process group to write to its
+controlling terminal will cause the process group to be sent a
+.Dv SIGTTOU
+signal unless one of the following special cases apply:  If
+.Dv TOSTOP
+is not
+set, or if
+.Dv TOSTOP
+is set and the process is ignoring or blocking the
+.Dv SIGTTOU
+signal, the process is allowed to write to the terminal and the
+.Dv SIGTTOU
+signal is not sent.  If
+.Dv TOSTOP
+is set, and the process group of
+the writing process is orphaned, and the writing process is not ignoring
+or blocking
+.Dv SIGTTOU ,
+the
+.Xr write
+returns -1 with
+errno set to
+.Er Dv EIO
+and no signal is sent.
+.Pp
+Certain calls that set terminal parameters are treated in the same
+fashion as write, except that
+.Dv TOSTOP
+is ignored; that is, the effect is
+identical to that of terminal writes when
+.Dv TOSTOP
+is set.
+.Ss Input Processing and Reading Data
+A terminal device associated with a terminal device file may operate in
+full-duplex mode, so that data may arrive even while output is occurring.
+Each terminal device file has associated with it an input queue, into
+which incoming data is stored by the system before being read by a
+process.  The system imposes a limit,
+.Pf \&{ Dv MAX_INPUT Ns \&} ,
+on the number of
+bytes that may be stored in the input queue.  The behavior of the system
+when this limit is exceeded depends on the setting of the
+.Dv IMAXBEL
+flag in the termios
+.Fa c_iflag .
+If this flag is set, the terminal
+is sent an
+.Tn ASCII
+.Dv BEL
+character each time a character is received
+while the input queue is full.  Otherwise, the input queue is flushed
+upon receiving the character.
+.Pp
+Two general kinds of input processing are available, determined by
+whether the terminal device file is in canonical mode or noncanonical
+mode. Additionally,
+input characters are processed according to the
+.Fa c_iflag
+and
+.Fa c_lflag
+fields.  Such processing can include echoing, which
+in general means transmitting input characters immediately back to the
+terminal when they are received from the terminal.  This is useful for
+terminals that can operate in full-duplex mode.
+.Pp
+The manner in which data is provided to a process reading from a terminal
+device file is dependent on whether the terminal device file is in
+canonical or noncanonical mode.
+.Pp
+Another dependency is whether the
+.Dv O_NONBLOCK
+flag is set by
+.Xr open()
+or
+.Xr fcntl() .
+If the
+.Dv O_NONBLOCK
+flag is clear, then the read request is
+blocked until data is available or a signal has been received.  If the
+.Dv O_NONBLOCK
+flag is set, then the read request is completed, without
+blocking, in one of three ways:
+.Bl -enum -offset indent
+.It
+If there is enough data available to satisfy the entire request,
+and the read completes successfully the number of
+bytes read is returned.
+.It
+If there is not enough data available to satisfy the entire
+request, and the read completes successfully, having read as
+much data as possible, the number of bytes read is returned.
+.It
+If there is no data available, the read returns -1, with
+errno set to
+.Er EAGAIN .
+.El
+.Pp
+When data is available depends on whether the input processing mode is
+canonical or noncanonical.
+.Ss Canonical Mode Input Processing
+In canonical mode input processing, terminal input is processed in units
+of lines.  A line is delimited by a newline
+.Ql \&\en
+character, an end-of-file
+.Pq Dv EOF
+character, or an end-of-line
+.Pq Dv EOL
+character.  See the
+.Sx "Special Characters"
+section for
+more information on
+.Dv EOF
+and
+.Dv EOL .
+This means that a read request will
+not return until an entire line has been typed, or a signal has been
+received.  Also, no matter how many bytes are requested in the read call,
+at most one line is returned.  It is not, however, necessary to
+read a whole line at once; any number of bytes, even one, may be
+requested in a read without losing information.
+.Pp
+.Pf \&{ Dv MAX_CANON Ns \&}
+is a limit on the
+number of bytes in a line.
+The behavior of the system when this limit is
+exceeded is the same as when the input queue limit
+.Pf \&{ Dv MAX_INPUT Ns \&} ,
+is exceeded.
+.Pp
+Erase and kill processing occur when either of two special characters,
+the
+.Dv ERASE
+and
+.Dv KILL
+characters (see the
+.Sx "Special Characters section" ) ,
+is received.
+This processing affects data in the input queue that has not yet been
+delimited by a newline
+.Dv NL,
+.Dv EOF ,
+or
+.Dv EOL
+character.  This un-delimited
+data makes up the current line.  The
+.Dv ERASE
+character deletes the last
+character in the current line, if there is any.  The
+.Dv KILL
+character
+deletes all data in the current line, if there is any.  The
+.Dv ERASE
+and
+.Dv KILL
+characters have no effect if there is no data in the current line.
+The
+.Dv ERASE
+and
+.Dv KILL
+characters themselves are not placed in the input
+queue.
+.Ss Noncanonical Mode Input Processing
+In noncanonical mode input processing, input bytes are not assembled into
+lines, and erase and kill processing does not occur.  The values of the
+.Dv MIN
+and
+.Dv TIME
+members of the
+.Fa c_cc
+array are used to determine how to
+process the bytes received.
+.Pp
+.Dv MIN
+represents the minimum number of bytes that should be received when
+the
+.Xr read
+function successfully returns.
+.Dv TIME
+is a timer of 0.1 second
+granularity that is used to time out bursty and short term data
+transmissions.  If
+.Dv MIN
+is greater than
+.Dv \&{ Dv MAX_INPUT Ns \&} ,
+the response to the
+request is undefined.  The four possible values for
+.Dv MIN
+and
+.Dv TIME
+and
+their interactions are described below.
+.Ss "Case A: MIN > 0, TIME > 0"
+In this case
+.Dv TIME
+serves as an inter-byte timer and is activated after
+the first byte is received.  Since it is an inter-byte timer, it is reset
+after a byte is received.  The interaction between
+.Dv MIN
+and
+.Dv TIME
+is as
+follows:  as soon as one byte is received, the inter-byte timer is
+started.  If
+.Dv MIN
+bytes are received before the inter-byte timer expires
+(remember that the timer is reset upon receipt of each byte), the read is
+satisfied.  If the timer expires before
+.Dv MIN
+bytes are received, the
+characters received to that point are returned to the user.  Note that if
+.Dv TIME
+expires at least one byte is returned because the timer would
+not have been enabled unless a byte was received.  In this case
+.Pf \&( Dv MIN
+> 0,
+.Dv TIME
+> 0) the read blocks until the
+.Dv MIN
+and
+.Dv TIME
+mechanisms are
+activated by the receipt of the first byte, or a signal is received.  If
+data is in the buffer at the time of the read(), the result is as
+if data had been received immediately after the read().
+.Ss "Case B: MIN > 0, TIME = 0"
+In this case, since the value of
+.Dv TIME
+is zero, the timer plays no role
+and only
+.Dv MIN
+is significant.  A pending read is not satisfied until
+.Dv MIN
+bytes are received (i.e., the pending read blocks until
+.Dv MIN
+bytes
+are received), or a signal is received.  A program that uses this case to
+read record-based terminal
+.Dv I/O
+may block indefinitely in the read
+operation.
+.Ss "Case C: MIN = 0, TIME > 0"
+In this case, since
+.Dv MIN
+= 0,
+.Dv TIME
+no longer represents an inter-byte
+timer.  It now serves as a read timer that is activated as soon as the
+read function is processed.  A read is satisfied as soon as a single
+byte is received or the read timer expires.  Note that in this case if
+the timer expires, no bytes are returned.  If the timer does not
+expire, the only way the read can be satisfied is if a byte is received.
+In this case the read will not block indefinitely waiting for a byte; if
+no byte is received within
+.Dv TIME Ns *0.1
+seconds after the read is initiated,
+the read returns a value of zero, having read no data.  If data is
+in the buffer at the time of the read, the timer is started as if
+data had been received immediately after the read.
+.Ss Case D: MIN = 0, TIME = 0
+The minimum of either the number of bytes requested or the number of
+bytes currently available is returned without waiting for more
+bytes to be input.  If no characters are available, read returns a
+value of zero, having read no data.
+.Ss Writing Data and Output Processing
+When a process writes one or more bytes to a terminal device file, they
+are processed according to the
+.Fa c_oflag
+field (see the
+.Sx "Output Modes
+section).  The
+implementation may provide a buffering mechanism; as such, when a call to
+write() completes, all of the bytes written have been scheduled for
+transmission to the device, but the transmission will not necessarily
+have been completed.
+.\" See also .Sx "6.4.2" for the effects of
+.\" .Dv O_NONBLOCK
+.\" on write.
+.Ss Special Characters
+Certain characters have special functions on input or output or both.
+These functions are summarized as follows:
+.Bl -tag -width indent
+.It Dv INTR
+Special character on input and is recognized if the
+.Dv ISIG
+flag (see the
+.Sx "Local Modes"
+section) is enabled.  Generates a
+.Dv SIGINT
+signal which is sent to all processes in the foreground
+process group for which the terminal is the controlling
+terminal.  If
+.Dv ISIG
+is set, the
+.Dv INTR
+character is
+discarded when processed.
+.It Dv QUIT
+Special character on input and is recognized if the
+.Dv ISIG
+flag is enabled.  Generates a
+.Dv SIGQUIT
+signal which is
+sent to all processes in the foreground process group
+for which the terminal is the controlling terminal.  If
+.Dv ISIG
+is set, the
+.Dv QUIT
+character is discarded when
+processed.
+.It Dv ERASE
+Special character on input and is recognized if the
+.Dv ICANON
+flag is set.  Erases the last character in the
+current line; see
+.Sx "Canonical Mode Input Processing" .
+It does not erase beyond
+the start of a line, as delimited by an
+.Dv NL ,
+.Dv EOF ,
+or
+.Dv EOL
+character.  If
+.Dv ICANON
+is set, the
+.Dv ERASE
+character is
+discarded when processed.
+.It Dv KILL
+Special character on input and is recognized if the
+.Dv ICANON
+flag is set.  Deletes the entire line, as
+delimited by a
+.Dv NL ,
+.Dv EOF ,
+or
+.Dv EOL
+character.  If
+.Dv ICANON
+is set, the
+.Dv KILL
+character is discarded when processed.
+.It Dv EOF
+Special character on input and is recognized if the
+.Dv ICANON
+flag is set.  When received, all the bytes
+waiting to be read are immediately passed to the
+process, without waiting for a newline, and the
+.Dv EOF
+is discarded.  Thus, if there are no bytes waiting (that
+is, the
+.Dv EOF
+occurred at the beginning of a line), a byte
+count of zero is returned from the read(),
+representing an end-of-file indication.  If
+.Dv ICANON
+is
+set, the
+.Dv EOF
+character is discarded when processed.
+.Dv NL
+Special character on input and is recognized if the
+.Dv ICANON
+flag is set.  It is the line delimiter
+.Ql \&\en .
+.It Dv EOL
+Special character on input and is recognized if the
+.Dv ICANON
+flag is set.  Is an additional line delimiter,
+like
+.Dv NL .
+.It Dv SUSP
+If the
+.Dv ISIG
+flag is enabled, receipt of the
+.Dv SUSP
+character causes a
+.Dv SIGTSTP
+signal to be sent to all processes in the
+foreground process group for which the terminal is the
+controlling terminal, and the
+.Dv SUSP
+character is
+discarded when processed.
+.It Dv STOP
+Special character on both input and output and is
+recognized if the
+.Dv IXON
+(output control) or
+.Dv IXOFF
+(input
+control) flag is set.  Can be used to temporarily
+suspend output.  It is useful with fast terminals to
+prevent output from disappearing before it can be read.
+If
+.Dv IXON
+is set, the
+.Dv STOP
+character is discarded when
+processed.
+.It Dv START
+Special character on both input and output and is
+recognized if the
+.Dv IXON
+(output control) or
+.Dv IXOFF
+(input
+control) flag is set.  Can be used to resume output that
+has been suspended by a
+.Dv STOP
+character.  If
+.Dv IXON
+is set, the
+.Dv START
+character is discarded when processed.
+.Dv CR
+Special character on input and is recognized if the
+.Dv ICANON
+flag is set; it is the
+.Ql \&\er ,
+as denoted in the
+.Tn \&C
+Standard {2}.  When
+.Dv ICANON
+and
+.Dv ICRNL
+are set and
+.Dv IGNCR
+is not set, this character is translated into a
+.Dv NL ,
+and
+has the same effect as a
+.Dv NL
+character.
+.El
+.Pp
+The following special characters are extensions defined by this
+system and are not a part of 1003.1 termios.
+.Bl -tag -width indent
+.It Dv EOL2
+Secondary
+.Dv EOL
+character.  Same function as
+.Dv EOL.
+.It Dv WERASE
+Special character on input and is recognized if the
+.Dv ICANON
+flag is set.  Erases the last word in the current
+line according to one of two algorithms.  If the
+.Dv ALTWERASE
+flag is not set, first any preceding whitespace is
+erased, and then the maximal sequence of non-whitespace
+characters.  If
+.Dv ALTWERASE
+is set, first any preceding
+whitespace is erased, and then the maximal sequence
+of alphabetic/underscores or non alphabetic/underscores.
+As a special case in this second algorithm, the first previous
+non-whitespace character is skipped in determining
+whether the preceding word is a sequence of
+alphabetic/undercores.  This sounds confusing but turns
+out to be quite practical.
+.It Dv REPRINT
+Special character on input and is recognized if the
+.Dv ICANON
+flag is set.  Causes the current input edit line
+to be retyped.
+.It Dv DSUSP
+Has similar actions to the
+.Dv SUSP
+character, except that
+the
+.Dv SIGTSTP
+signal is delivered when one of the processes
+in the foreground process group issues a read() to the
+controlling terminal.
+.It Dv LNEXT
+Special character on input and is recognized if the
+.Dv IEXTEN
+flag is set.  Receipt of this character causes the next
+character to be taken literally.
+.It Dv DISCARD
+Special character on input and is recognized if the
+.Dv IEXTEN
+flag is set.  Receipt of this character toggles the flushing
+of terminal output.
+.It Dv STATUS
+Special character on input and is recognized if the
+.Dv ICANON
+flag is set.  Receipt of this character causes a
+.Dv SIGINFO
+signal to be sent to the foreground process group of the
+terminal.  Also, if the
+.Dv NOKERNINFO
+flag is not set, it
+causes the kernel to write a status message to the terminal
+that displays the current load average, the name of the
+command in the foreground, its process ID, the symbolic
+wait channel, the number of user and system seconds used,
+the percentage of cpu the process is getting, and the resident
+set size of the process.
+.El
+.Pp
+The
+.Dv NL
+and
+.Dv CR
+characters cannot be changed.
+The values for all the remaining characters can be set and are
+described later in the document under
+Special Control Characters.
+.Pp
+Special
+character functions associated with changeable special control characters
+can be disabled individually by setting their value to
+.Dv {_POSIX_VDISABLE};
+see
+.Sx "Special Control Characters" .
+.Pp
+If two or more special characters have the same value, the function
+performed when that character is received is undefined.
+.Ss Modem Disconnect
+If a modem disconnect is detected by the terminal interface for a
+controlling terminal, and if
+.Dv CLOCAL
+is not set in the
+.Fa c_cflag
+field for
+the terminal, the
+.Dv SIGHUP
+signal is sent to the controlling
+process associated with the terminal.  Unless other arrangements have
+been made, this causes the controlling process to terminate.
+Any subsequent call to the read() function returns the value zero,
+indicating end of file.  Thus, processes that read a terminal
+file and test for end-of-file can terminate appropriately after a
+disconnect.
+.\" If the
+.\" .Er EIO
+.\" condition specified in 6.1.1.4 that applies
+.\" when the implementation supports job control also exists, it is
+.\" unspecified whether the
+.\" .Dv EOF
+.\" condition or the
+.\" .Pf [ Dv EIO
+.\" ] is returned.
+Any
+subsequent write() to the terminal device returns -1, with
+.Va errno
+set to
+.Er EIO ,
+until the device is closed.
+.Sh General Terminal Interface
+.Pp
+.Ss Closing a Terminal Device File
+The last process to close a terminal device file causes any output
+to be sent to the device and any input to be discarded.  Then, if
+.Dv HUPCL
+is set in the control modes, and the communications port supports a
+disconnect function, the terminal device performs a disconnect.
+.Ss Parameters That Can Be Set
+Routines that need to control certain terminal
+.Tn I/O
+characteristics
+do so by using the termios structure as defined in the header
+.Aq Pa termios.h .
+This structure contains minimally four scalar elements of bit flags
+and one array of special characters.  The scalar flag elements are
+named:
+.Fa c_iflag ,
+.Fa c_oflag ,
+.Fa c_cflag ,
+and
+.Fa c_lflag .
+The character array is named
+.Fa c_cc ,
+and its maximum index is
+.Dv NCCS .
+.Ss Input Modes
+Values of the
+.Fa c_iflag
+field describe the basic
+terminal input control, and are composed of
+following masks:
+.Pp
+.Bl -tag -width IMAXBEL -offset indent -compact
+.It Dv IGNBRK
+/* ignore BREAK condition */
+.It Dv BRKINT
+/* map BREAK to SIGINTR */
+.It Dv IGNPAR
+/* ignore (discard) parity errors */
+.It Dv PARMRK
+/* mark parity and framing errors */
+.It Dv INPCK
+/* enable checking of parity errors */
+.It Dv ISTRIP
+/* strip 8th bit off chars */
+.It Dv INLCR
+/* map NL into CR */
+.It Dv IGNCR
+/* ignore CR */
+.It Dv ICRNL
+/* map CR to NL (ala CRMOD) */
+.It Dv IXON
+/* enable output flow control */
+.It Dv IXOFF
+/* enable input flow control */
+.It Dv IXANY
+/* any char will restart after stop */
+.It Dv IMAXBEL
+/* ring bell on input queue full */
+.El
+.Pp
+In the context of asynchronous serial data transmission, a break
+condition is defined as a sequence of zero-valued bits that continues for
+more than the time to send one byte.  The entire sequence of zero-valued
+bits is interpreted as a single break condition, even if it continues for
+a time equivalent to more than one byte.  In contexts other than
+asynchronous serial data transmission the definition of a break condition
+is implementation defined.
+.Pp
+If
+.Dv IGNBRK
+is set, a break condition detected on input is ignored, that
+is, not put on the input queue and therefore not read by any process.  If
+.Dv IGNBRK
+is not set and
+.Dv BRKINT
+is set, the break condition flushes the
+input and output queues and if the terminal is the controlling terminal
+of a foreground process group, the break condition generates a
+single
+.Dv SIGINT
+signal to that foreground process group.  If neither
+.Dv IGNBRK
+nor
+.Dv BRKINT
+is set, a break condition is read as a single
+.Ql \&\e0 ,
+or if
+.Dv PARMRK
+is set, as
+.Ql \&\e377 ,
+.Ql \&\e0 ,
+.Ql \&\e0 .
+.Pp
+If
+.Dv IGNPAR
+is set, a byte with a framing or parity error (other than
+break) is ignored.
+.Pp
+If
+.Dv PARMRK
+is set, and
+.Dv IGNPAR
+is not set, a byte with a framing or parity
+error (other than break) is given to the application as the
+three-character sequence
+.Ql \&\e377 ,
+.Ql \&\e0 ,
+X, where
+.Ql \&\e377 ,
+.Ql \&\e0
+is a two-character
+flag preceding each sequence and X is the data of the character received
+in error.  To avoid ambiguity in this case, if
+.Dv ISTRIP
+is not set, a valid
+character of
+.Ql \&\e377
+is given to the application as
+.Ql \&\e377 ,
+.Ql \&\e377 .
+If
+neither
+.Dv PARMRK
+nor
+.Dv IGNPAR
+is set, a framing or parity error (other than
+break) is given to the application as a single character
+.Ql \&\e0 .
+.Pp
+If
+.Dv INPCK
+is set, input parity checking is enabled.  If
+.Dv INPCK
+is not set,
+input parity checking is disabled, allowing output parity generation
+without input parity errors.  Note that whether input parity checking is
+enabled or disabled is independent of whether parity detection is enabled
+or disabled (see
+.Sx "Control Modes" ) .
+If parity detection is enabled but input
+parity checking is disabled, the hardware to which the terminal is
+connected recognizes the parity bit, but the terminal special file
+does not check whether this bit is set correctly or not.
+.Pp
+If
+.Dv ISTRIP
+is set, valid input bytes are first stripped to seven bits,
+otherwise all eight bits are processed.
+.Pp
+If
+.Dv INLCR
+is set, a received
+.Dv NL
+character is translated into a
+.Dv CR
+character.  If
+.Dv IGNCR
+is set, a received
+.Dv CR
+character is ignored (not
+read).  If
+.Dv IGNCR
+is not set and
+.Dv ICRNL
+is set, a received
+.Dv CR
+character is
+translated into a
+.Dv NL
+character.
+.Pp
+If
+.Dv IXON
+is set, start/stop output control is enabled.  A received
+.Dv STOP
+character suspends output and a received
+.Dv START
+character
+restarts output. If
+.Dv IXANY
+is also set, then any character may
+restart output. When
+.Dv IXON
+is set,
+.Dv START
+and
+.Dv STOP
+characters are not
+read, but merely perform flow control functions.  When
+.Dv IXON
+is not set,
+the
+.Dv START
+and
+.Dv STOP
+characters are read.
+.Pp
+If
+.Dv IXOFF
+is set, start/stop input control is enabled.  The system shall
+transmit one or more
+.Dv STOP
+characters, which are intended to cause the
+terminal device to stop transmitting data, as needed to prevent the input
+queue from overflowing and causing the undefined behavior described in
+.Sx "Input Processing and Reading Data" ,
+and shall transmit one or more
+.Dv START
+characters, which are
+intended to cause the terminal device to resume transmitting data, as
+soon as the device can continue transmitting data without risk of
+overflowing the input queue.  The precise conditions under which
+.Dv STOP
+and
+START
+characters are transmitted are implementation defined.
+.Pp
+If
+.Dv IMAXBEL
+is set and the input queue is full, subsequent input shall cause an
+.Tn ASCII
+.Dv BEL
+character to be transmitted to the
+the output queue.
+.Pp
+The initial input control value after open() is implementation defined.
+.Ss Output Modes
+Values of the
+.Fa c_oflag
+field describe the basic terminal output control,
+and are composed of the following masks:
+.Pp
+.Bl -tag -width OXTABS -offset indent -compact
+.It Dv OPOST
+/* enable following output processing */
+.It Dv ONLCR
+/* map NL to CR-NL (ala
+.Dv CRMOD)
+*/
+.It Dv OXTABS
+/* expand tabs to spaces */
+.It Dv ONOEOT
+/* discard
+.Dv EOT Ns 's
+.Ql \&^D
+on output) */
+.El
+.Pp
+If
+.Dv OPOST
+is set, the remaining flag masks are interpreted as follows;
+otherwise characters are transmitted without change.
+.Pp
+If
+.Dv ONLCR
+is set, newlines are translated to carriage return, linefeeds.
+.Pp
+If
+.Dv OXTABS
+is set, tabs are expanded to the appropriate number of
+spaces (assuming 8 column tab stops).
+.Pp
+If
+.Dv ONOEOT
+is set,
+.Tn ASCII
+.Dv EOT NS 's
+are discarded on output.
+.Ss Control Modes
+Values of the
+.Fa c_cflag
+field describe the basic
+terminal hardware control, and are composed of the
+following masks.
+Not all values
+specified are supported by all hardware.
+.Pp
+.Bl -tag -width CRTSXIFLOW -offset indent -compact
+.It Dv CSIZE
+/* character size mask */
+.It Dv CS5
+/* 5 bits (pseudo) */
+.It Dv CS6
+/* 6 bits */
+.It Dv CS7
+/* 7 bits */
+.It Dv CS8
+/* 8 bits */
+.It Dv CSTOPB
+/* send 2 stop bits */
+.It Dv CREAD
+/* enable receiver */
+.It Dv PARENB
+/* parity enable */
+.It Dv PARODD
+/* odd parity, else even */
+.It Dv HUPCL
+/* hang up on last close */
+.It Dv CLOCAL
+/* ignore modem status lines */
+.It Dv CCTS_OFLOW
+/*
+.Dv CTS
+flow control of output */
+.It Dv CRTSCTS
+/* same as
+.Dv CCTS_OFLOW
+*/
+.It Dv CRTS_IFLOW
+/* RTS flow control of input */
+.It Dv MDMBUF
+/* flow control output via Carrier */
+.El
+.Pp
+The
+.Dv CSIZE
+bits specify the byte size in bits for both transmission and
+reception.  The
+.Fa c_cflag
+is masked with
+.Dv CSIZE
+and compared with the
+values
+.Dv CS5 ,
+.Dv CS6 ,
+.Dv CS7 ,
+or
+.Dv CS8 .
+This size does not include the parity bit, if any.  If
+.Dv CSTOPB
+is set, two stop bits are used, otherwise one stop bit.  For example, at
+110 baud, two stop bits are normally used.
+.Pp
+If
+.Dv CREAD
+is set, the receiver is enabled.  Otherwise, no character is
+received. 
+Not all hardware supports this bit.  In fact, this flag
+is pretty silly and if it were not part of the
+.Nm termios
+specification
+it would be omitted.
+.Pp
+If
+.Dv PARENB
+is set, parity generation and detection are enabled and a parity
+bit is added to each character.  If parity is enabled,
+.Dv PARODD
+specifies
+odd parity if set, otherwise even parity is used.
+.Pp
+If
+.Dv HUPCL
+is set, the modem control lines for the port are lowered
+when the last process with the port open closes the port or the process
+terminates.  The modem connection is broken.
+.Pp
+If
+.Dv CLOCAL
+is set, a connection does not depend on the state of the modem
+status lines.  If
+.Dv CLOCAL
+is clear, the modem status lines are
+monitored.
+.Pp
+Under normal circumstances, a call to the open() function waits for
+the modem connection to complete.  However, if the
+.Dv O_NONBLOCK
+flag is set
+or if
+.Dv CLOCAL
+has been set, the open() function returns
+immediately without waiting for the connection.
+.Pp
+The
+.Dv CCTS_OFLOW
+.Pf ( Dv CRTSCTS )
+flag is currently unused.
+.Pp
+If
+.Dv MDMBUF
+is set then output flow control is controlled by the state
+of Carrier Detect.
+.Pp
+If the object for which the control modes are set is not an asynchronous
+serial connection, some of the modes may be ignored; for example, if an
+attempt is made to set the baud rate on a network connection to a
+terminal on another host, the baud rate may or may not be set on the
+connection between that terminal and the machine it is directly connected
+to.
+.Ss Local Modes
+Values of the
+.Fa c_lflag
+field describe the control of
+various functions, and are composed of the following
+masks.
+.Pp
+.Bl -tag -width NOKERNINFO -offset indent -compact
+.It Dv ECHOKE
+/* visual erase for line kill */
+.It Dv ECHOE
+/* visually erase chars */
+.It Dv ECHO
+/* enable echoing */
+.It Dv ECHONL
+/* echo
+.Dv NL
+even if
+.Dv ECHO
+is off */
+.It Dv ECHOPRT
+/* visual erase mode for hardcopy */
+.It Dv ECHOCTL
+/* echo control chars as ^(Char) */
+.It Dv ISIG
+/* enable signals
+.Dv INTR ,
+.Dv QUIT ,
+.Dv [D]SUSP
+*/
+.It Dv ICANON
+/* canonicalize input lines */
+.It Dv ALTWERASE
+/* use alternate
+.Dv WERASE
+algorithm */
+.It Dv IEXTEN
+/* enable
+.Dv DISCARD
+and
+.Dv LNEXT
+*/
+.It Dv EXTPROC
+/* external processing */
+.It Dv TOSTOP
+/* stop background jobs from output */
+.It Dv FLUSHO
+/* output being flushed (state) */
+.It Dv NOKERNINFO
+/* no kernel output from
+.Dv VSTATUS
+*/
+.It Dv PENDIN
+/* XXX retype pending input (state) */
+.It Dv NOFLSH
+/* don't flush after interrupt */
+.El
+.Pp
+If
+.Dv ECHO
+is set, input characters are echoed back to the terminal.  If
+.Dv ECHO
+is not set, input characters are not echoed.
+.Pp
+If
+.Dv ECHOE
+and
+.Dv ICANON
+are set, the
+.Dv ERASE
+character causes the terminal
+to erase the last character in the current line from the display, if
+possible.  If there is no character to erase, an implementation may echo
+an indication that this was the case or do nothing.
+.Pp
+If
+.Dv ECHOK
+and
+.Dv ICANON
+are set, the
+.Dv KILL
+character causes
+the current line to be discarded and the system echoes the
+.Ql \&\en
+character after the
+.Dv KILL
+character.
+.Pp
+If
+.Dv ECHOKE
+and
+.Dv ICANON
+are set, the
+.Dv KILL
+character causes
+the current line to be discarded and the system causes
+the terminal
+to erase the line from the display.
+.Pp
+If
+.Dv ECHOPRT
+and
+.Dv ICANON
+are set, the system assumes
+that the display is a printing device and prints a
+backslash and the erased characters when processing
+.Dv ERASE
+characters, followed by a forward slash.
+.Pp
+If
+.Dv ECHOCTL
+is set, the system echoes control characters
+in a visible fashion using a caret followed by the control character.
+.Pp
+If
+.Dv ALTWERASE
+is set, the system uses an alternative algorithm
+for determining what constitutes a word when processing
+.Dv WERASE
+characters (see
+.Dv WERASE ) .
+.Pp
+If
+.Dv ECHONL
+and
+.Dv ICANON
+are set, the
+.Ql \&\en
+character echoes even if
+.Dv ECHO
+is not set.
+.Pp
+If
+.Dv ICANON
+is set, canonical processing is enabled.  This enables the
+erase and kill edit functions, and the assembly of input characters into
+lines delimited by
+.Dv NL,
+.Dv EOF ,
+and
+.Dv EOL,
+as described in
+.Sx "Canonical Mode Input Processing" .
+.Pp
+If
+.Dv ICANON
+is not set, read requests are satisfied directly from the input
+queue.  A read is not satisfied until at least
+.Dv MIN
+bytes have been
+received or the timeout value
+.Dv TIME
+expired between bytes.  The time value
+represents tenths of seconds.  See
+.Sx "Noncanonical Mode Input Processing"
+for more details.
+.Pp
+If
+.Dv ISIG
+is set, each input character is checked against the special
+control characters
+.Dv INTR ,
+.Dv QUIT ,
+and
+.Dv SUSP
+(job control only).  If an input
+character matches one of these control characters, the function
+associated with that character is performed.  If
+.Dv ISIG
+is not set, no
+checking is done.  Thus these special input functions are possible only
+if
+.Dv ISIG
+is set.
+.Pp
+If
+.Dv IEXTEN
+is set, implementation-defined functions are recognized
+from the input data.  How
+.Dv IEXTEN
+being set
+interacts with
+.Dv ICANON ,
+.Dv ISIG ,
+.Dv IXON ,
+or
+.Dv IXOFF
+is implementation defined.
+If
+.Dv IEXTEN
+is not set, then
+implementation-defined functions are not recognized, and the
+corresponding input characters are not processed as described for
+.Dv ICANON ,
+.Dv ISIG ,
+.Dv IXON ,
+and
+.Dv IXOFF .
+.Pp
+If
+.Dv NOFLSH
+is set, the normal flush of the input and output queues
+associated with the
+.Dv INTR ,
+.Dv QUIT ,
+and
+.Dv SUSP
+characters
+are not be done.
+.Pp
+If
+.Dv TOSTOP
+is set, the signal
+.Dv SIGTTOU
+is sent to the process group of a process that tries to write to
+its controlling terminal if it is not in the foreground process group for
+that terminal.  This signal, by default, stops the members of the process
+group.  Otherwise, the output generated by that process is output to the
+current output stream.  Processes that are blocking or ignoring
+.Dv SIGTTOU
+signals are excepted and allowed to produce output and the
+.Dv SIGTTOU
+signal
+is not sent.
+.Pp
+If
+.Dv NOKERNINFO
+is set, the kernel does not produce a status message
+when processing
+.Dv STATUS
+characters (see
+.Dv STATUS ) .
+.Ss Special Control Characters
+The special control characters values are defined by the array
+.Fa c_cc .
+This table lists the array index, the corresponding special character,
+and the system default value.  For an accurate list of
+the system defaults, consult the header file
+.Aq Pa ttydefaults.h .
+.Pp
+.Bl -column "Index Name" "Special Character" -offset indent -compact
+.It Em "Index Name	Special Character	Default Value"
+.It Dv VEOF Ta EOF Ta \&^D
+.It Dv VEOL Ta EOL Ta _POSIX_VDISABLE
+.It Dv VEOL2 Ta EOL2 Ta _POSIX_VDISABLE
+.It Dv VERASE Ta ERASE Ta \&^? Ql \&\e177
+.It Dv VWERASE  Ta WERASE Ta \&^W
+.It Dv VKILL Ta KILL Ta \&^U
+.It Dv VREPRINT Ta REPRINT Ta \&^R
+.It Dv VINTR Ta INTR Ta \&^C
+.It Dv VQUIT Ta QUIT Ta \&^\e\e Ql \&\e34
+.It Dv VSUSP Ta SUSP Ta \&^Z
+.It Dv VDSUSP Ta DSUSP Ta \&^Y
+.It Dv VSTART Ta START Ta \&^Q
+.It Dv VSTOP Ta STOP Ta \&^S
+.It Dv VLNEXT Ta LNEXT Ta \&^V
+.It Dv VDISCARD Ta DISCARD Ta \&^O
+.It Dv VMIN Ta --- Ta \&1
+.It Dv VTIME Ta --- Ta \&0
+.It Dv VSTATUS Ta STATUS Ta \&^T
+.El
+.Pp
+If the
+value of one of the changeable special control characters (see
+.Sx "Special Characters" )
+is
+.Dv {_POSIX_VDISABLE} ,
+that function is disabled; that is, no input
+data is recognized as the disabled special character.
+If
+.Dv ICANON
+is
+not set, the value of
+.Dv {_POSIX_VDISABLE}
+has no special meaning for the
+.Dv VMIN
+and
+.Dv VTIME
+entries of the
+.Fa c_cc
+array.
+.Pp
+The initial values of the flags and control characters
+after open() is set according to
+the values in the header
+.Aq Pa sys/ttydefaults.h .
diff --git a/share/man/man4/tp.4 b/share/man/man4/tp.4
new file mode 100644
index 0000000..fdfd578
--- /dev/null
+++ b/share/man/man4/tp.4
@@ -0,0 +1,722 @@
+.\" Copyright (c) 1990, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)tp.4	8.4 (Berkeley) 4/19/94
+.\"
+.Dd April 19, 1994
+.Dt TP 4
+.Os
+.Sh NAME
+.Nm TP
+.Nd
+.Tn ISO
+Transport Protocol
+.Sh SYNOPSIS
+.Fd #include <sys/socket.h>
+.Fd #include <netiso/iso_errno.h>
+.Fd #include <netiso/tp_param.h>
+.Fd #include <netiso/tp_user.h>
+.Ft int
+.Fn socket "[AF_INET, AF_ISO]" SOCK_SEQPACKET 0
+.Sh DESCRIPTION
+.Pp
+The
+.Tn TP
+protocol provides reliable, flow-controlled, two-way
+transmission of data and record boundaries. 
+It is a byte-stream protocol and is accessed according to
+the
+.Dv SOCK_SEQPACKET
+abstraction.
+The
+.Tn TP
+protocol makes use of a standard
+.Tn ISO
+address format,
+including a Network Service Access Point, and a Transport Service Entity
+Selector.
+Subclass 4 may make use of the internet
+Internet address format.
+.Pp
+Sockets utilizing the tp protocol are either
+.Dq active
+or
+.Dq passive .
+Active sockets initiate connections to passive
+sockets.  By default
+.Tn TCP
+sockets are created active; to create a
+passive socket the
+.Xr listen 2
+system call must be used
+after binding the socket with the
+.Xr bind 2
+system call.  Only
+passive sockets may use the 
+.Xr accept 2
+call to accept incoming connections.  Only active sockets may
+use the
+.Xr connect 2
+call to initiate connections.
+.Pp
+Passive sockets may
+.Dq underspecify
+their location to match
+incoming connection requests from multiple networks.  This
+technique, termed
+.Dq wildcard addressing ,
+allows a single
+server to provide service to clients on multiple networks.
+To create a socket which listens on all networks, the
+.Tn NSAP
+portion
+of the bound address must be void (of length zero).
+The Transport Selector may still be specified
+at this time; if the port is not specified the system will assign one.
+Once a connection has been established the socket's address is
+fixed by the peer entity's location.   The address assigned the
+socket is the address associated with the network interface
+through which packets are being transmitted and received.
+.Pp
+The
+.Tn ISO
+Transport Protocol implemented for
+.Tn AOS R2
+at the University of Wisconsin - Madison,
+and modified for inclusion in the Berkeley Software Distribution,
+includes classes 0 and 4 
+of the
+.Tn ISO
+transport protocols
+as specified in
+the June 1986 version of
+.Tn IS
+8073.
+Class 4 of the protocol provides reliable, sequenced,
+flow-controlled, two-way
+transmission of data packets with an alternate stop-and-wait data path called
+the "expedited data" service.
+Class 0 is essentially a null transport protocol, which is used
+when the underlying network service provides reliable, sequenced,
+flow-controlled, two-way data transmission.
+Class 0 does not provide the expedited data service.
+The protocols are implemented as a single transport layer entity 
+that coexists with the Internet protocol suite.
+Class 0 may be used only in the
+.Tn ISO
+domain.
+Class 4 may be used in the Internet domain as well as in the
+.Tn ISO
+domain.
+.Pp
+Two system calls were modified from the previous
+release of the Berkeley Software Distribution
+to permit the support of the end-of-transport-service-data-unit
+.Pq Dv EOTSDU
+indication, and for the receipt and transmission of user
+connect, confirm, and disconnect data.
+See
+.Xr sendmsg 2
+and
+.Xr recvmsg 2 ,
+and further discussion
+below for the formats of the data in the ancillary data buffer.
+If the
+.Dv EOTSDU
+is not needed, the normal
+.Xr read 2 ,
+and
+.Xr write 2
+system calls may be used.
+.Pp
+Through the 
+.Xr getsockopt
+and
+.Xr setsockopt
+system calls,
+.Tn TP
+supports several options 
+to control such things as negotiable options
+in the protocol and protocol strategies.
+The options are defined in
+.Aq Pa netiso/tp_user.h ,
+and are described below.
+.Pp
+In the tables below,
+the options marked with a pound sign
+.Ql \&#
+may be used 
+with
+.Xr setsockopt
+after a connection is established.
+Others must be used before the connection
+is established, in other words,
+before calling
+.Xr connect
+or 
+.Xr accept .
+All options may be used 
+with
+.Xr getsockopt
+before or
+after a connection is established.
+.Bl -tag -width TPOPT_PSTATISTICS
+.It Dv TPOPT_CONN_DATA
+(char *) [none]
+.br
+Data to send on
+.Xr connect .
+The passive user may issue a
+.Xr getsockopt
+call to retrieve a connection request's user data,
+after having done the
+.Xr accept
+system call without implying confirmation of the connection.
+.Pp
+The data may also be retrieved by issuing a
+.Xr recvmsg
+request for ancillary data only,
+without implying confirmation of the connection.
+The returned
+.Va cmsghdr
+will contain
+.Dv SOL_TRANSPORT
+for the
+.Va csmg_level
+and
+.Dv TPOPT_CONN_DATA
+for
+.Va cmsg_type.
+.It Dv TPOPT_DISC_DATA \&#
+(char *) [none]
+.br
+Data to send on
+.Xr close .
+Disconnect data may be sent by the side initiating the close
+but not by the passive side ("passive" with respect to the closing
+of the connection), so there is no need to read disconnect data
+after calling
+.Xr close .
+This may be sent by a
+.Xr setsockopt
+system call, or by issuing a
+.Xr sendmsg
+request specifying ancillary data only.
+The user-provided
+.Va cmsghdr
+must contain
+.Dv SOL_TRANSPORT
+for
+.Va csmg_level
+and
+.Dv TPOPT_DISC_DATA
+for
+.Va cmsg_type .
+Sending of disconnect data will in of itself tear down (or reject)
+the connection.
+.It Dv TPOPT_CFRM_DATA \&#
+(char *) [none]
+.br
+Data to send when confirming a connection.
+This may also be sent by a 
+.Xr setsockopt
+system call, or by issuing a
+.Xr sendmsg
+request, as above.
+Sending of connect confirm data will cause the connection
+to be confirmed rather than rejected.
+.It Dv TPOPT_PERF_MEAS \&#
+Boolean.
+.br
+When
+.Xr true ,
+performance measurements will be kept
+for this connection.  
+When set before a connection is established, the
+active side will use a locally defined parameter on the
+connect request packet; if the peer is another
+.Tn ARGO
+implementation, this will cause performance measurement to be
+turned on 
+on the passive side as well.
+See
+.Xr tpperf 8 .
+.It Dv TPOPT_PSTATISTICS
+No associated value on input.
+On output,
+.Ar struct tp_pmeas .
+.Pp
+This command is used to read the performance statistics accumulated
+during a connection's lifetime.
+It can only be used with
+.Xr getsockopt .
+The structure it returns is described in
+.Aq Pa netiso/tp_stat.h .
+See
+.Xr tpperf 8 .
+.It Dv TPOPT_FLAGS
+unsigned integer. [0x0]
+.br
+This command can only be used with
+.Xr getsockopt .
+See the description of the flags below.
+.It Dv TPOPT_PARAMS
+.Ar struct tp_conn_param
+.br
+Used to get or set a group parameters for a connection.
+The
+.Ar struct tp_conn_param
+is the argument used with the
+.Xr getsockopt
+or
+.Xr setsockopt
+system call. 
+It is described in 
+.Aq Pa netiso/tp_user.h .
+.Pp
+The fields of the
+.Ar tp_conn_param
+structure are
+described below.
+.El
+.Pp
+.Em Values for TPOPT_PARAMS:
+.Bl -tag -width p_sendack_ticks
+.It Ar p_Nretrans
+nonzero short integer [1]
+.br
+Number of times a TPDU
+will be retransmitted before the
+local TP entity closes a connection.
+.It Ar p_dr_ticks
+nonzero short integer [various]
+.br
+Number of clock ticks between retransmissions of disconnect request
+TPDUs.
+.It Ar p_dt_ticks
+nonzero short integer [various]
+.br
+Number of clock ticks between retransmissions of data
+TPDUs.
+This parameter applies only to class 4.
+.It Ar p_cr_ticks
+nonzero short integer [various]
+.br
+Number of clock ticks between retransmissions of connection request
+TPDUs.
+.It Ar p_cc_ticks
+nonzero short integer [various]
+.br
+Number of clock ticks between retransmissions of connection confirm
+TPDUs.
+This parameter applies only to class 4.
+.It Ar p_x_ticks
+nonzero short integer [various]
+.br
+Number of clock ticks between retransmissions of expedited data
+TPDUs.
+This parameter applies only to class 4.
+.It Ar p_sendack_ticks
+nonzero short integer [various]
+.br
+Number of clock ticks that the local TP entity
+will wait before sending an acknowledgment for normal data
+(not applicable if the acknowledgement strategy is
+.Dv TPACK_EACH ) .
+This parameter applies only to class 4.
+.It Ar p_ref_ticks
+nonzero short integer [various]
+.br
+Number of clock ticks for which a reference will
+be considered frozen after the connection to which
+it applied is closed.
+This parameter applies to classes 4 and 0 in the 
+.Tn ARGO
+implementation, despite the fact that
+the frozen reference function is required only for
+class 4.
+.It Ar p_inact_ticks
+nonzero short integer [various]
+.br
+Number of clock ticks without an incoming packet from the peer after which 
+.Tn TP
+close the connection.
+This parameter applies only to class 4.
+.It Ar p_keepalive_ticks
+nonzero short integer [various]
+.br
+Number of clock ticks between acknowledgments that are sent
+to keep an inactive connection open (to prevent the peer's
+inactivity control function from closing the connection).
+This parameter applies only to class 4.
+.It Ar p_winsize
+short integer between 128 and 16384. [4096 bytes]
+.br
+The buffer space limits in bytes for incoming and outgoing data.
+There is no way to specify different limits for incoming and outgoing
+paths.
+The actual window size at any time
+during the lifetime of a connection
+is a function of the buffer size limit, the negotiated
+maximum TPDU
+size, and the 
+rate at which the user program receives data.
+This parameter applies only to class 4.
+.It Ar p_tpdusize
+unsigned char between 0x7 and 0xd. 
+[0xc for class 4] [0xb for class 0]
+.br
+Log 2 of the maximum TPDU size to be negotiated.
+The
+.Tn TP
+standard
+.Pf ( Tn ISO
+8473) gives an upper bound of 
+0xd for class 4 and 0xb for class 0.
+The
+.Tn ARGO
+implementation places upper bounds of
+0xc on class 4 and 0xb on class 0.
+.It Ar p_ack_strat
+.Dv TPACK_EACH
+or
+.Dv TPACK_WINDOW.
+.Bq Dv TPACK_WINDOW
+.br
+This parameter applies only to class 4.
+Two acknowledgment strategies are supported:
+.Pp
+.Dv TPACK_EACH means that each data TPDU
+is acknowledged
+with an AK TPDU.
+.Pp
+.Dv TPACK_WINDOW
+means that upon receipt of the packet that represents
+the high edge of the last window advertised, an AK TPDU is generated.
+.It Ar p_rx_strat
+4 bit mask
+.Bq Dv TPRX_USE_CW No \&|\  Dv TPRX_FASTSTART
+over
+connectionless network protocols]
+.Pf [ Dv TPRX_USE_CW
+over
+connection-oriented network protocols]
+.br
+This parameter applies only to class 4.
+The bit mask may include the following values:
+.Pp
+.Dv TPRX_EACH :
+When a retransmission timer expires, retransmit
+each packet in the send window rather than
+just the first unacknowledged packet.
+.Pp
+.Dv TPRX_USE_CW :
+Use a "congestion window" strategy borrowed
+from Van Jacobson's congestion window strategy for TCP.
+The congestion window size is set to one whenever
+a retransmission occurs.
+.Pp
+.Dv TPRX_FASTSTART :
+Begin sending the maximum amount of data permitted
+by the peer (subject to availability).
+The alternative is to start sending slowly by 
+pretending the peer's window is smaller than it is, and letting
+it slowly grow up to the peer window's real size.
+This is to smooth the effect of new connections on a congested network
+by preventing a transport connection from suddenly 
+overloading the network with a burst of packets.
+This strategy is also due to Van Jacobson.
+.It Ar p_class
+5 bit mask
+.Bq Dv TP_CLASS_4 No \&|\  Dv TP_CLASS_0
+.br
+Bit mask including one or both of the values
+.Dv TP_CLASS_4
+and
+.Dv TP_CLASS_0 .
+The higher class indicated is the preferred class.
+If only one class is indicated, negotiation will not occur
+during connection establishment.
+.It Ar p_xtd_format
+Boolean.
+[false]
+.br
+Boolean indicating that extended format is negotiated.
+This parameter applies only to class 4.
+.It Ar p_xpd_service
+Boolean.
+[true]
+.br
+Boolean indicating that 
+the expedited data transport service will be negotiated.
+This parameter applies only to class 4.
+.It Ar p_use_checksum
+Boolean.
+[true]
+.br
+Boolean indicating the the use of checksums will be negotiated.
+This parameter applies only to class 4.
+.It Ar p_use_nxpd
+Reserved for future use.
+.It Ar p_use_rcc
+Reserved for future use.
+.It Ar p_use_efc
+Reserved for future use.
+.It Ar p_no_disc_indications
+Boolean.
+[false]
+.Pp
+Boolean indicating that the local
+.Tn TP
+entity will not issue
+indications (signals) when a
+.Tn TP
+connection is disconnected.
+.It Ar p_dont_change_params
+Boolean.  [false]
+.br
+If
+.Em true
+the
+.Tn TP
+entity will not override
+any of the other values given in this structure.
+If the values cannot be used, the
+.Tn TP
+entity will drop, disconnect,
+or refuse to establish the connection to which this structure pertains.
+.It Ar p_netservice
+One of {
+.Dv ISO_CLNS ,
+.Dv ISO_CONS ,
+.Dv ISO_COSNS ,
+.Dv IN_CLNS } .
+.Pf [ Dv ISO_CLNS ]
+.br
+Indicates which network service is to be used.
+.Pp
+.Dv ISO_CLNS
+indicates the connectionless network service provided
+by CLNP 
+.Pf ( Tn ISO
+8473).
+.Pp
+.Dv ISO_CONS
+indicates the connection-oriented network service provided
+by X.25
+.Pf ( Tn ISO
+8208) and
+.Tn ISO
+8878.
+.Pp
+.Dv ISO_COSNS
+indicates the 
+connectionless network service running over a
+connection-oriented subnetwork service: CLNP 
+.Pf ( Tn ISO
+8473) over X.25
+.Pf ( Tn ISO
+8208).
+.Pp
+.Dv IN_CLNS
+indicates the 
+DARPA Internet connectionless network service provided by IP (RFC 791).
+.It Ar p_dummy
+Reserved for future use.
+.El
+.Pp
+The
+.Dv TPOPT_FLAGS
+option is used for obtaining
+various boolean-valued options.
+Its meaning is as follows.
+The bit numbering used is that of the RT PC, which means that bit
+0 is the most significant bit, while bit 8 is the least significant bit.
+.sp 1
+.Em Values for TPOPT_FLAGS:
+.Bl -tag -width Bitsx
+.It Sy Bits
+.Sy Description [Default]
+.It \&0
+.Dv TPFLAG_NLQOS_PDN :
+set when the quality of the 
+network service is
+similar to that of a public data network.
+.It \&1
+.Dv TPFLAG_PEER_ON_SAMENET :
+set when the peer
+.Tn TP
+entity
+is considered to be on the same network as the local
+.Tn TP
+entity.
+.It \&2
+Not used.
+.It \&3
+.Dv TPFLAG_XPD_PRES :
+set when expedited data are present
+[0]
+.It 4\&..7
+Reserved.
+.El
+.Sh ERROR VALUES
+.Pp
+The
+.Tn TP
+entity returns
+.Va errno
+error values as defined in
+.Aq Pa sys/errno.h
+and
+.Aq Pa netiso/iso_errno.h .
+User programs may print messages associated with these value by
+using an expanded version of
+.Xr perror
+found in the
+.Tn ISO
+library,
+.Pa libisodir.a .
+.Pp
+If the
+.Tn TP
+entity encounters asynchronous events
+that will cause a transport connection to be closed,
+such as
+timing out while retransmitting a connect request TPDU,
+or receiving a DR TPDU,
+the
+.Tn TP
+entity issues a
+.Dv SIGURG
+signal, indicating that
+disconnection has occurred.
+If the signal is issued during a 
+a system call, the system call may be interrupted,
+in which case the
+.Va errno
+value upon return from the system call is
+.Er EINTR.
+If the signal
+.Dv SIGURG
+is being handled by reading
+from the socket, and it was an
+.Xr accept 2
+that
+timed out, the read may result in
+.Er ENOTSOCK ,
+because the
+.Xr accept
+call had not yet returned a
+legitimate socket descriptor when the signal was handled.
+.Dv ETIMEDOUT
+(or a some other errno value appropriate to the
+type of error) is returned if
+.Dv SIGURG
+is blocked
+for the duration of the system call.
+A user program should take one of the following approaches:
+.Bl -tag -width Ds
+.It Block Dv SIGURG
+If the program is servicing
+only one connection, it can block or ignore
+.Dv SIGURG
+during connection 
+establishment.
+The advantage of this is that the
+.Va errno
+value
+returned is somewhat meaningful.
+The disadvantage of this is that
+if ignored, disconnection and expedited data indications could be
+missed.
+For some programs this is not a problem.
+.It Handle Dv SIGURG
+If the program is servicing more than one connection at a time
+or expedited data may arrive or both, the program may elect to
+service
+.Dv SIGURG .
+It can use the
+.Fn getsockopt ...TPOPT_FLAGS...
+system 
+call to see if the signal
+was due to the arrival of expedited data or due to a disconnection.
+In the latter case, 
+.Xr getsockopt
+will return
+.Er ENOTCONN .
+.El
+.Sh SEE ALSO
+.Xr tcp 4 ,
+.Xr netstat 1 ,
+.Xr iso 4 ,
+.Xr clnp 4 ,
+.Xr cltp 4 ,
+.Xr ifconfig 8 .
+.Sh BUGS
+The protocol definition of expedited data is slightly problematic,
+in a way that renders expedited data almost useless,
+if two or more packets of expedited data are send within
+time \(*e, where \(*e
+depends on the application.
+The problem is not of major significance since most applications
+do not use transport expedited data.
+The problem is this:
+the expedited data acknowledgment TPDU
+has no field for conveying
+credit, thus it is not possible for a
+.Tn TP
+entity to inform its peer
+that "I received your expedited data but have no room to receive more."
+The
+.Tn TP
+entity has the choice of acknowledging receipt of the
+XPD TPDU:
+.Bl -tag -width Ds
+.It "when the user receives the" XPD TSDU
+which may be a fairly long time,
+which may cause the sending
+.Tn TP
+entity to retransmit the packet,
+and possibly to close the connection after retransmission, or
+.It "when the" Tn TP No "entity receives it"
+so the sending entity does not retransmit or close the connection.
+If the sending user then tries to send more expedited data
+.Dq soon ,
+the expedited data will not be acknowledged (until the
+receiving user receives the first XPD TSDU).
+.El
+.Pp
+The
+.Tn ARGO
+implementation acknowledges XPD TPDUs
+immediately,
+in the hope that most users will not use expedited data frequently
+enough for this to be a problem.
diff --git a/share/man/man4/tty.4 b/share/man/man4/tty.4
new file mode 100644
index 0000000..a39ef1a
--- /dev/null
+++ b/share/man/man4/tty.4
@@ -0,0 +1,394 @@
+.\" Copyright (c) 1991, 1992, 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
+.\" 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.
+.\"
+.\"     @(#)tty.4	8.3 (Berkeley) 4/19/94
+.\"
+.Dd August 14, 1992
+.Dt TTY 4
+.Os BSD 4
+.Sh NAME
+.Nm tty
+.Nd general terminal interface
+.Sh SYNOPSIS
+.Fd #include <sys/ioctl.h>
+.Sh DESCRIPTION
+This section describes the interface to the terminal drivers
+in the system.
+.Ss Terminal Special Files
+Each hardware terminal port on the system usually has a terminal special device
+file associated with it in the directory ``/dev/'' (for
+example, ``/dev/tty03'').
+When a user logs into
+the system on one of these hardware terminal ports, the system has already
+opened the associated device and prepared the line for normal interactive
+use (see
+.Xr getty 8 .)
+There is also a special case of a terminal file that connects not to
+a hardware terminal port, but to another program on the other side.
+These special terminal devices are called
+.Em ptys
+and provide the mechanism necessary to give users the same interface to the
+system when logging in over a network (using
+.Xr rlogin 1 ,
+or
+.Xr telnet 1
+for example.)  Even in these cases the details of how the terminal
+file was opened and set up is already handled by special software
+in the system.
+Thus, users do not normally need to worry about the details of
+how these lines are opened or used.  Also, these lines are often used
+for dialing out of a system (through an out-calling modem), but again
+the system provides programs that hide the details of accessing
+these terminal special files (see
+.Xr tip 2 .)
+.Pp
+When an interactive user logs in, the system prepares the line to
+behave in a certain way (called a
+.Em "line discipline" ) ,
+the particular details of which is described in
+.Xr stty 1
+at the command level, and in
+.Xr termios 4
+at the programming level.  A user may be concerned with changing
+settings associated with his particular login terminal and should refer
+to the preceding man pages for the common cases.  The remainder of
+this man page is concerned
+with describing details of using and controlling terminal devices
+at a low level, such as that possibly required by a program wishing
+to provide features similar to those provided by the system.
+.Ss Line disciplines
+A terminal file is used like any other file in the system in that
+it can be opened, read, and written to using standard system
+calls.  For each existing terminal file, there is a software processing module
+called a
+.Em "line discipline"
+is associated with it.  The
+.Em "line discipline"
+essentially glues the low level device driver code with the high
+level generic interface routines (such as
+.Xr read 2
+and
+.Xr write 2 ),
+and is responsible for implementing the semantics associated
+with the device.  When a terminal file is first opened by a program,
+the default
+.Em "line discipline"
+called the
+.Dv termios
+line discipline is associated with the file.  This is the primary
+line discipline that is used in most cases and provides the semantics
+that users normally associate with a terminal.  When the
+.Dv termios
+line discipline is in effect, the terminal file behaves and is
+operated according to the rules described in
+.Xr termios 4 .
+Please refer to that man page for a full description of the terminal
+semantics.
+The operations described here
+generally represent features common
+across all
+.Em "line disciplines" ,
+however some of these calls may not
+make sense in conjunction with a line discipline other than
+.Dv termios ,
+and some may not be supported by the underlying
+hardware (or lack thereof, as in the case of ptys).
+.Ss Terminal File Operations
+All of the following operations are invoked using the
+.Xr ioctl 2
+system call.  Refer to that man page for a description of
+the
+.Em request
+and
+.Em argp
+parameters.
+In addition to the ioctl
+.Em requests
+defined here, the specific line discipline
+in effect will define other
+.Em requests
+specific to it (actually
+.Xr termios 4
+defines them as function calls, not ioctl
+.Em requests . )
+The following section lists the available ioctl requests.  The
+name of the request, a description of its purpose, and the typed
+.Em argp
+parameter (if any)
+are listed.  For example, the first entry says
+.Pp
+.D1 Em "TIOCSETD int *ldisc"
+.Pp
+and would be called on the terminal associated with
+file descriptor zero by the following code fragment:
+.Bd -literal
+	int ldisc;
+
+	ldisc = TTYDISC;
+	ioctl(0, TIOCSETD, &ldisc);
+.Ed
+.Ss Terminal File Request Descriptions
+.Bl -tag -width TIOCGWINSZ
+.It Dv TIOCSETD Fa int *ldisc
+Change to the new line discipline pointed to by
+.Fa ldisc .
+The available line disciplines are listed in
+.Pa Aq sys/termios.h
+and currently are:
+.Pp
+.Bl -tag -width TIOCGWINSZ -compact
+.It TTYDISC
+Termios interactive line discipline.
+.It TABLDISC
+Tablet line discipline.
+.It SLIPDISC
+Serial IP line discipline.
+.El
+.Pp
+.It Dv TIOCGETD Fa int *ldisc
+Return the current line discipline in the integer pointed to by
+.Fa ldisc .
+.It Dv TIOCSBRK Fa void
+Set the terminal hardware into BREAK condition.
+.It Dv TIOCCBRK Fa void
+Clear the terminal hardware BREAK condition.
+.It Dv TIOCSDTR Fa void
+Assert data terminal ready (DTR).
+.It Dv TIOCCDTR Fa void
+Clear data terminal ready (DTR).
+.It Dv TIOCGPGRP Fa int *tpgrp
+Return the current process group the terminal is associated
+with in the integer pointed to by
+.Fa tpgrp .
+This is the underlying call that implements the
+.Xr termios 4
+.Fn tcgetattr
+call.
+.It Dv TIOCSPGRP Fa int *tpgrp
+Associate the terminal with the process group (as an integer) pointed to by
+.Fa tpgrp .
+This is the underlying call that implements the
+.Xr termios 4
+.Fn tcsetattr
+call.
+.It Dv TIOCGETA Fa struct termios *term
+Place the current value of the termios state associated with the
+device in the termios structure pointed to by
+.Fa term .
+This is the underlying call that implements the
+.Xr termios 4
+.Fn tcgetattr
+call.
+.It Dv TIOCSETA Fa struct termios *term
+Set the termios state associated with the device immediately.
+This is the underlying call that implements the
+.Xr termios 4
+.Fn tcsetattr
+call with the
+.Dv TCSANOW
+option.
+.It Dv TIOCSETAW Fa struct termios *term
+First wait for any output to complete, then set the termios state
+associated with the device.
+This is the underlying call that implements the
+.Xr termios 4
+.Fn tcsetattr
+call with the
+.Dv TCSADRAIN
+option.
+.It Dv TIOCSETAF Fa struct termios *term
+First wait for any output to complete, clear any pending input,
+then set the termios state associated with the device.
+This is the underlying call that implements the
+.Xr termios 4
+.Fn tcsetattr
+call with the
+.Dv TCSAFLUSH
+option.
+.It Dv TIOCOUTQ Fa int *num
+Place the current number of characters in the output queue in the
+integer pointed to by
+.Fa num .
+.It Dv TIOCSTI Fa char *cp
+Simulate typed input.  Pretend as if the terminal received the
+character pointed to by
+.Fa cp .
+.It Dv TIOCNOTTY Fa void
+This call is obsolete but left for compatibility.  In the past, when
+a process that didn't have a controlling terminal (see
+.Em The Controlling Terminal
+in
+.Xr termios 4 )
+first opened a terminal device, it acquired that terminal as its
+controlling terminal.  For some programs this was a hazard as they
+didn't want a controlling terminal in the first place, and this
+provided a mechanism to disassociate the controlling terminal from
+the calling process.  It
+.Em must
+be called by opening the file
+.Pa /dev/tty
+and calling
+.Dv TIOCNOTTY
+on that file descriptor.
+.Pp
+The current system does not allocate a controlling terminal to
+a process on an
+.Fn open
+call: there is a specific ioctl called
+.Dv TIOSCTTY
+to make a terminal the controlling
+terminal.
+In addition, a program can
+.Fn fork
+and call the
+.Fn setsid
+system call which will place the process into its own session - which
+has the effect of disassociating it from the controlling terminal.  This
+is the new and preferred method for programs to lose their controlling
+terminal.
+.It Dv TIOCSTOP Fa void
+Stop output on the terminal (like typing ^S at the keyboard).
+.It Dv TIOCSTART Fa void
+Start output on the terminal (like typing ^Q at the keyboard).
+.It Dv TIOCSCTTY Fa void
+Make the terminal the controlling terminal for the process (the process
+must not currently have a controlling terminal).
+.It Dv TIOCDRAIN Fa void
+Wait until all output is drained.
+.It Dv TIOCEXCL Fa void
+Set exclusive use on the terminal.  No further opens are permitted
+except by root.  Of course, this means that programs that are run by
+root (or setuid) will not obey the exclusive setting - which limits
+the usefulness of this feature.
+.It Dv TIOCNXCL Fa void
+Clear exclusive use of the terminal.  Further opens are permitted.
+.It Dv TIOCFLUSH Fa int *what
+If the value of the int pointed to by
+.Fa what
+contains the
+.Dv FREAD
+bit as defined in
+.Pa Aq sys/file.h ,
+then all characters in the input queue are cleared.  If it contains
+the
+.Dv FWRITE
+bit, then all characters in the output queue are cleared.  If the
+value of the integer is zero, then it behaves as if both the
+.Dv FREAD
+and
+.Dv FWRITE
+bits were set (i.e. clears both queues).
+.It Dv TIOCGWINSZ Fa struct winsize *ws
+Put the window size information associated with the terminal in the
+.Va winsize
+structure pointed to by
+.Fa ws .
+The window size structure contains the number of rows and columns (and pixels
+if appropriate) of the devices attached to the terminal.  It is set by user software
+and is the means by which most full\&-screen oriented programs determine the
+screen size.  The
+.Va winsize
+structure is defined in
+.Pa Aq sys/ioctl.h .
+.It Dv TIOCSWINSZ Fa struct winsize *ws
+Set the window size associated with the terminal to be the value in
+the
+.Va winsize
+structure pointed to by
+.Fa ws
+(see above).
+.It Dv TIOCCONS Fa int *on
+If
+.Fa on
+points to a non-zero integer, redirect kernel console output (kernel printf's)
+to this terminal.
+If
+.Fa on
+points to a zero integer, redirect kernel console output back to the normal
+console.  This is usually used on workstations to redirect kernel messages
+to a particular window.
+.It Dv TIOCMSET Fa int *state
+The integer pointed to by
+.Fa state
+contains bits that correspond to modem state.  Following is a list
+of defined variables and the modem state they represent:
+.Pp
+.Bl -tag -width TIOCMXCTS -compact
+.It TIOCM_LE
+Line Enable.
+.It TIOCM_DTR
+Data Terminal Ready.
+.It TIOCM_RTS
+Request To Send.
+.It TIOCM_ST
+Secondary Transmit.
+.It TIOCM_SR
+Secondary Receive.
+.It TIOCM_CTS
+Clear To Send.
+.It TIOCM_CAR
+Carrier Detect.
+.It TIOCM_CD
+Carier Detect (synonym).
+.It TIOCM_RNG
+Ring Indication.
+.It TIOCM_RI
+Ring Indication (synonym).
+.It TIOCM_DSR
+Data Set Ready.
+.El
+.Pp
+This call sets the terminal modem state to that represented by
+.Fa state .
+Not all terminals may support this.
+.It Dv TIOCMGET Fa int *state
+Return the current state of the terminal modem lines as represented
+above in the integer pointed to by
+.Fa state .
+.It Dv TIOCMBIS Fa int *state
+The bits in the integer pointed to by
+.Fa state
+represent modem state as described above, however the state is OR-ed
+in with the current state.
+.It Dv TIOCMBIC Fa int *state
+The bits in the integer pointed to by
+.Fa state
+represent modem state as described above, however each bit which is on
+in
+.Fa state
+is cleared in the terminal.
+.El
+.Sh SEE ALSO
+.Xr getty 8 ,
+.Xr ioctl 2 ,
+.Xr pty 4 ,
+.Xr stty 1 ,
+.Xr termios 4
diff --git a/share/man/man4/udp.4 b/share/man/man4/udp.4
new file mode 100644
index 0000000..939866b
--- /dev/null
+++ b/share/man/man4/udp.4
@@ -0,0 +1,137 @@
+.\" Copyright (c) 1983, 1991, 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
+.\" 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.
+.\"
+.\"     @(#)udp.4	8.1 (Berkeley) 6/5/93
+.\"
+.Dd June 5, 1993
+.Dt UDP 4
+.Os BSD 4.2
+.Sh NAME
+.Nm udp
+.Nd Internet User Datagram Protocol
+.Sh SYNOPSIS
+.Fd #include <sys/socket.h>
+.Fd #include <netinet/in.h>
+.Ft int
+.Fn socket AF_INET SOCK_DGRAM 0
+.Sh DESCRIPTION
+.Tn UDP
+is a simple, unreliable datagram protocol which is used
+to support the
+.Dv SOCK_DGRAM
+abstraction for the Internet
+protocol family.
+.Tn UDP
+sockets are connectionless, and are
+normally used with the
+.Xr sendto
+and
+.Xr recvfrom
+calls, though the
+.Xr connect 2
+call may also be used to fix the destination for future
+packets (in which case the 
+.Xr recv 2
+or
+.Xr read 2
+and 
+.Xr send 2
+or
+.Xr write 2
+system calls may be used).
+.Pp
+.Tn UDP
+address formats are identical to those used by
+.Tn TCP .
+In particular
+.Tn UDP
+provides a port identifier in addition
+to the normal Internet address format.  Note that the
+.Tn UDP
+port
+space is separate from the
+.Tn TCP
+port space (i.e. a
+.Tn UDP
+port
+may not be
+.Dq connected
+to a
+.Tn TCP
+port).  In addition broadcast
+packets may be sent (assuming the underlying network supports
+this) by using a reserved
+.Dq broadcast address ;
+this address
+is network interface dependent.
+.Pp
+Options at the
+.Tn IP
+transport level may be used with
+.Tn UDP ;
+see
+.Xr ip 4 .
+.Sh DIAGNOSTICS
+A socket operation may fail with one of the following errors returned:
+.Bl -tag -width [EADDRNOTAVAIL]
+.It Bq Er EISCONN
+when trying to establish a connection on a socket which
+already has one, or when trying to send a datagram with the destination
+address specified and the socket is already connected;
+.It Bq Er ENOTCONN
+when trying to send a datagram, but
+no destination address is specified, and the socket hasn't been
+connected;
+.It Bq Er ENOBUFS
+when the system runs out of memory for
+an internal data structure;
+.It Bq Er EADDRINUSE
+when an attempt
+is made to create a socket with a port which has already been
+allocated;
+.It Bq Er EADDRNOTAVAIL
+when an attempt is made to create a 
+socket with a network address for which no network interface
+exists.
+.El
+.Sh SEE ALSO
+.Xr getsockopt 2 ,
+.Xr recv 2 ,
+.Xr send 2 ,
+.Xr socket 2 ,
+.Xr intro 4 ,
+.Xr inet 4 ,
+.Xr ip 4
+.Sh HISTORY
+The
+.Nm
+protocol appeared in
+.Bx 4.2 .
diff --git a/share/man/man4/unix.4 b/share/man/man4/unix.4
new file mode 100644
index 0000000..3d05dcd
--- /dev/null
+++ b/share/man/man4/unix.4
@@ -0,0 +1,161 @@
+.\" Copyright (c) 1991, 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
+.\" 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.
+.\"
+.\"     @(#)unix.4	8.1 (Berkeley) 6/9/93
+.\"
+.Dd June 9, 1993
+.Dt UNIX 4
+.Os
+.Sh NAME
+.Nm unix
+.Nd UNIX-domain protocol family
+.Sh SYNOPSIS
+.Fd #include <sys/types.h>
+.Fd #include <sys/un.h>
+.Sh DESCRIPTION
+The
+.Tn UNIX Ns -domain
+protocol family is a collection of protocols
+that provides local (on-machine) interprocess
+communication through the normal
+.Xr socket 2
+mechanisms.
+The 
+.Tn UNIX Ns -domain
+family supports the
+.Dv SOCK_STREAM
+and
+.Dv SOCK_DGRAM
+socket types and uses
+filesystem pathnames for addressing.
+.Sh ADDRESSING
+.Tn UNIX Ns -domain
+addresses are variable-length filesystem pathnames of
+at most 104 characters.
+The include file
+.Aq Pa sys/un.h
+defines this address:
+.Bd -literal -offset indent
+struct sockaddr_un {
+u_char	sun_len;
+u_char	sun_family;
+char	sun_path[104];
+};
+.Ed
+.Pp
+Binding a name to a
+.Tn UNIX Ns -domain
+socket with
+.Xr bind 2
+causes a socket file to be created in the filesystem.
+This file is
+.Em not
+removed when the socket is closed\(em\c
+.Xr unlink 2
+must be used to remove the file.
+.Pp
+The
+.Tn UNIX Ns -domain
+protocol family does not support broadcast addressing or any form
+of
+.Dq wildcard
+matching on incoming messages. 
+All addresses are absolute- or relative-pathnames
+of other
+.Tn UNIX Ns -domain
+sockets.
+Normal filesystem access-control mechanisms are also
+applied when referencing pathnames; e.g., the destination
+of a
+.Xr connect 2
+or
+.Xr sendto 2
+must be writable.
+.Sh PROTOCOLS
+The 
+.Tn UNIX Ns -domain
+protocol family is comprised of simple
+transport protocols that support the
+.Dv SOCK_STREAM
+and
+.Dv SOCK_DGRAM
+abstractions.
+.Dv SOCK_STREAM
+sockets also support the communication of 
+.Ux
+file descriptors through the use of the
+.Ar msg_control
+field in the
+.Ar msg
+argument to
+.Xr sendmsg 2
+and
+.Xr recvmsg 2 .
+.Pp
+Any valid descriptor may be sent in a message.
+The file descriptor(s) to be passed are described using a 
+.Ar struct cmsghdr
+that is defined in the include file
+.Aq Pa sys/socket.h .
+The type of the message is
+.Dv SCM_RIGHTS ,
+and the data portion of the messages is an array of integers
+representing the file descriptors to be passed.
+The number of descriptors being passed is defined
+by the length field of the message;
+the length field is the sum of the size of the header
+plus the size of the array of file descriptors.
+.Pp
+The received descriptor is a 
+.Em duplicate
+of the sender's descriptor, as if it were created with a call to
+.Xr dup 2 .
+Per-process descriptor flags, set with
+.Xr fcntl 2 ,
+are 
+.Em not
+passed to a receiver.
+Descriptors that are awaiting delivery, or that are
+purposely not received, are automatically closed by the system
+when the destination socket is closed.
+.Sh SEE ALSO
+.Xr socket 2 ,
+.Xr intro 4
+.Rs
+.%T "An Introductory 4.3 BSD Interprocess Communication Tutorial"
+.%B PS1
+.%N 7
+.Re
+.Rs
+.%T "An Advanced 4.3 BSD Interprocess Communication Tutorial"
+.%B PS1
+.%N 8
+.Re