Aren/NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

new doc set from Lite

Browse Source
This commit is contained in:
cgd 1994-06-19 00:07:16 +00:00
parent 53ba44f2bd
commit d9158b13b5
262 changed files with 64201 additions and 191 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
share/doc/iso/README Normal file
View File

@ -0,0 +1,3 @@
The documentation contained here is horribly out of
date and not to be trusted. However, it's probably
better than nothing at all.

155
share/doc/iso/ucb/addr.nr Normal file
View File

@ -0,0 +1,155 @@
.NC "NSAP Addresses & Routing"
.sh 1 "OSI Address Formats"
.pp
ARGO supports an ISO address family, AF_ISO, in addition to the
DoD Internet address family, AF_INET.
Addresses in the family AF_ISO
take the form described by ISO 8348/DAD2, which is an addendum to the
OSI network service standard that describes network layer addressing.
.sh 2 "ISO 8348/DAD2 Tutorial"
.pp
.\" FIGURE
.\".so figs/osi_addr.nr
.so ../wisc/figs/addrfmt.nr
.CF
shows the
format of an OSI NSAP-address.
The address has two major parts: the initial domain part
(IDP) and the domain specific part (DSP). The IDP is further divided into
two parts: the authority and format identifier (AFI) and the
initial domain identifier (IDI). The AFI specifies the format of the
IDI, the authority responsible for allocating values of the IDI, and
the syntax of the DSP. The IDI specifies the network addressing domain
from which DSP values are allocated, and the authority responsible for
allocating DSP values.
.sh 2 "Supported Formats"
.pp
ARGO supports three types of ISO NSAP-addresses:
one type with AFI 37(hex) and two types with AFI 47(hex).
.sh 3 "AFI 37"
.pp
This value of the AFI defines the IDI to be an X.121 address or DTE
address.
The DTE address is encoded in binary coded decimal.
The DSP syntax is binary.
This form is intended to be used when communicating
across a public data network (PDN).
The ARGO software and documentation
refer to this type of NSAP-address as a
\*(lqtype 37.\*(rq
address.
.sh 3 "AFI 47"
.pp
The value of 47 for the AFI defines the IDI to be a 4 digit International
Code Designator (ICD) allocated according to ISO 6523.
ARGO support two
ICD values.
.sh 4 "ICD 0004"
.pp
The ICD value of 0004 is assigned to OSINET,
an experimental OSI network overseen by
National Institute of Science and Technology.\**
.(f
\** formerly the National Bureau of Standards
.)f
When this style of NSAP-address
is used,
the DSP is divided into four parts: an organization identifier (2 bytes),
a subnet identifier (2 bytes),
an SNPA-part (4-8 bytes), and
an NSAP selector (1 byte).
The use of these fields is defined by the OSINET steering committee.
This type of address is known as an
\*(lqOSINET\*(rq
address.
.sh 4 "ICD 0006"
.pp
The ICD value of 0006 is assigned to the Department of Defense (DoD).
In ARGO, NSAP-addresses with an ICD value of 0006
are of the format defined in RFC 986, a proposal for embedding DARPA Internet
addresses within an OSI NSAP-address.
In this case, the DSP takes the form:
version (1 byte), DARPA Internet Address (4 bytes), upper layer protocol
identifier (1 byte).
This is called an
\*(lqrfc986\*(rq
address.
.sh 1 "Internal Representation"
.pp
Internally, an NSAP address takes the form
.(b
\fC
.TS
tab(+);
l s s s s.
struct iso_addr {
.T&
l l l l l.
+u_char+isoa_afi;+/* authority &
+++format id */
+union+{+
++struct addr_37+addr_37;+/* x.121 */
++struct addr_osinet+addr_osinet;+/* OSINET */
++struct addr_rfc986+addr_rfc986;+/* Internet*/
+}+isoa_u;
+u_char+isoa_len;+/* length */
}
.TE
\fR
.)b
The field \fIisoa_afi\fR contains the AFI for the address.
The union
\fIisoa_u\fR contains the remainder of the address.
The length of the entire address (the AFI, IDI, and DSP) is
stored in \fIisoa_len\fR.
.sh 1 "Network Layer Routing"
.pp
Routing at the network layer is performed by the
routing procedure \fIrtalloc()\fR as described in Chapter 5.
\fIRtalloc()\fR was designed for used in the DoD Internet
domain.
An unfortunate
effect of this is that routing decisions are based upon either the
entire NSAP address or the network portion of the address.
The problem is defining the network portion of an NSAP address.
The location and extent of the
network portion of an NSAP address depends on the
style of NSAP address.
This decision is made by the function \fIiso_netof()\fR.
.sh 2 "Network Portion of Type 37 Addresses"
.pp
There is no network portion of an X.121 address.
In ARGO, the network portion of a type 37 address
is defined to be just the AFI.
The obvious consequence of this is that all type 37 addresses will
match all other type 37 addresses
in a network-portion comparison.
.sh 2 "Network Portion of OSINET Addresses"
.pp
The network portion of an OSINET address is the organization identifier and
the subnet identifier.
.sh 2 "Network Portion of RFC986 Addresses"
.pp
The network portion of an RFC986 address is the network portion of the
embedded DARPA Internet address.
ARGO does not support subnetting, a method of subdividing Internet addresses.
.sh 1 "NSAP Address / Subnetwork Point of Attachment Mapping"
.pp
In order to transmit a packet on a real subnetwork, the destination
NSAP address
must be mapped to an SNPA address.
An SNPA address is the real, "hardware" address
of a system on a network.
This address corresponds to the 6 byte Ethernet or Token Ring
Adapter address,
or to the DTE address, which may be up to 7 bytes
long (14 decimal digits).
.pp
A table, \fIsnpa_cache\fR is kept in the kernel which contains the
translation between NSAP-addresses and SNPA-addresses.
This table is used by \fIiso_snparesolve()\fR whenever a
datagram must be dispatched.
The table is maintained by the the ISO ES-IS protocol entity.
Entries can be added and deleted
by the user program \fIclnlutil(8)\fR and
by the CONS entity.

144
share/doc/iso/ucb/def.nr Normal file
View File

@ -0,0 +1,144 @@
.NC "Definitions"
.sh 1 "General Terms"
.ip "Kernel" 5
The source code or binary module for the Acis Operating System
(also know as AOS and IBM/4.3).
.ip "User process" 5
An instance of a program that is
running in unprivileged mode, in the unprivileged address space
commonly know as "user address space", in other words, not
part of the kernel.
.ip "IPC" 5
Interprocess communication, the mechanism by which two different
user processes send messages to each other.
.ip "Unix, AOS" 5
ACIS Operating System, the special testing release of Berkeley Unix 4.4BSD.
.ip "PCB, pcb" 5
Protocol control block. Each instance of a protocol machine
keeps status information, addresses, and in some cases queues
in a pcb for each connection or socket.
.ip "Domain" 5
In the Berkeley Unix environment, a domain is an abstract entity which
comprises a network architecture, addressing scheme, address format,
network protocols, and transport protocols.
.sh 1 "Transport Layer Terms"
.ip "ISO 8073"
ISO Draft International Standard 8073, Transport Protocol Specification
.ip "TP" 5
The collection of transport
classes that have been implemented in ARGO, classes 0 and 4.
Also means the ARGO implementation of TP.
.ip "TP 0" 5
Transport class 0.
.ip "TP 4" 5
Transport class 4.
.ip "Transport entity" 5
Software or hardware that implements the elements of procedure
described in ISO 8073.
.ip "Transport user" 5
User process that make use of the services
provided by a transport entity.
.ip "Transport service interface" 5
The syntax and semantics of the set of procedures, functions, and system calls
that are invoked by a transport user,
through which the services of the transport entity are delivered.
.ip "TPDU" 5
Transport protocol data unit, a packet that is
passed from one transport entity to another.
.ip "TSDU" 5
Transport service data unit, the logical unit of data that is
passed from a transport entity to a transport user, or from
a transport user to a transport entity.
.ip "CR TPDU" 5
Connection request TPDU.
.ip "CC TPDU" 5
Connection confirm TPDU.
.ip "DR TPDU" 5
Disconnect request TPDU.
.ip "DC TPDU" 5
Disconnect confirm TPDU.
.ip "DT TPDU" 5
Normal data TPDU.
.ip "XPD TPDU" 5
Expedited data TPDU.
.ip "AK TPDU" 5
Normal data acknowledgment TPDU.
.ip "XAK TPDU" 5
Expedited data acknowledgment TPDU.
.ip "ER TPDU" 5
Error TPDU.
.sh 1 "Network Layer Terms"
.ip "ISO 8473"
ISO Draft International Standard 8473, connectionless network protocol.
.ip "CONS"
Connection Oriented Network Service.
.ip "COSNS"
Connection Oriented Sub-Network Service.
.ip "CLNS"
Connectionless Network Service.
.ip "CLNP"
Connectionless Network Protocol, or ISO 8473.
.ip "Network Entity"
Software or hardware that implements the elements of procedure described
in ISO 8473.
.ip "Network Service User"
Software components that make use of the services provided by a network
entity.
.ip "Network Service Provider"
Software components that provide the services of a network entity.
.ip "NSAP"
Network Service Access Point. The point at which the OSI network service
is made available to the network service user by the network service
provider.
.ip "NSAP address"
Information that the network service provider needs to identify an
NSAP. The source and destination address fields of a CLNP packet
are NSAP addresses.
.ip "ES"
End system. A system running the complete suite of OSI protocols which can
act as an end point for communication.
.ip "IS"
Intermediate system. A system running the OSI layers 1, 2, and 3 which
can act only a packet router.
.ip "SNPA"
The Subnetwork Point of Attachement is the point where a \fIreal\fR
end or intermediate system is attached to a \fIreal\fR subnetwork.
.ip "SNPA address"
Information that a \fIreal\fR subnetwork need to identify a \fIreal\fR end
or intermediate system. This is commonly referred to as the hardware address.
.ip "NPDU"
Network Protocol Data Unit. The unit of data which is exchanged between
network entities.
.ip "DT NPDU"
Normal data NPDU.
.ip "ER NPDU"
Error report NPDU.
.ip "Initial NPDU"
A NPDU carrying the whole of the user data from an N-UNITDATA request.
.ip "Derived NPDU"
a NPDU whose field ar identical to those of an initial NPDU, except that it
carries only a segment of the user data from an N-UNITDATA request.
.ip "Segment"
A distinct unit of data consisting of part or all of the user data provided
in the N-UNITDATA request and delivered in the N-UNITDATA indication.
.ip "Segmentation"
The act of generation two or more derived NPDUs from an initial or derived
NPDU.
.ip "Fragment"
A DoD Internet Protocol term with the same meaning as "segment". Used
synonymously with "segment."
.ip "Fragmentation"
A DoD Internet Protocol term with the same meaning as "segmentation". Used
synonymously with "segmentation."
.ip "Reassembly"
The act of regenerating an initial NPDU from two ore more derived NPDUs.
.ip "MTU"
Maximum transmission unit. The maximum size of a packet that can be
transmitted on a medium or through a protocol.
For example, the MTU of the TP protocol is 8192 bytes, the MTU
of and Ethernet device is 1500 bytes, and the MTU of the OSI Network
service is 512 bytes.
.ip "Network interface"
The device used to attach a computer to a network, for example,
an Ethernet adapter, or a Token Ring adapter.
This terminology is inherited from BSD Unix.

72
share/doc/iso/ucb/intro.nr Normal file
View File

@ -0,0 +1,72 @@
.NC "Introduction"
.sh 1 "Introduction"
.pp
This document describes the usage of the ISO
transport and network layers written for the ACIS Operating System,
the IBM ACIS port of Berkeley 4.3 Unix\**
.(f
\** Unix is a registered trademark of AT&T.
.)f
for the IBM RT PC,
hereafter called AOS, as modified by UC Berkeley.
This document describes work in progress and is an extremely
hasty job of editing an earlier document written by colleagues
at the university of Wisconsin.
It is to be regarded as an emergency manual prepared for testers
at NIST and should not be redistributed further.
As such, there are philosophical
statements that Berkeley fundamentally disagrees with, which
we do not presently have the time to rip out.
Collectively, this work is called the Wisconsin ARGO kernel.
The ARGO kernel supports the
the connection-oriented ISO transport service (COTS), the
ISO connectionless network service (CLNS)
and a
connection-oriented network service (CONS).
The COTS is provided by the ISO transport protocol TP,
ISO 8073 Revised.
The CLNS is provided by the connectionless network protocol,
ISO 8473.
The CONS is provided by the X.25 protocols.
The ARGO implementation of the CONS is not a complete
ISO CONS, but contains enough of the CONS to support
the COTS and the CLNS (in the latter case, the CONS can be
viewed as a subnetwork service).
.pp
The purposes of this document are
.ip "1) "
to describe the transport service and the software interface
between the user and provider of this service,
.ip "2) "
to describe the network service and the software interface it
provides.
.pp
It is assumed that the reader is familiar with the \fBC\fR
programming language,
with Unix conventions, and with the ISO specifications listed in Appendix A.
.sh 1 "Organization"
.pp
This document is composed of several chapters.
Chapter One contains this introduction. Chapter Two presents a
definition of terms and phrases used throughout the document.
Chapter Three describes the transport service interface, which is
the interface between the transport protocol implementation software and the transport user software.
Chapter Four describes the network service interface, and the interface
above and below the network layer.
Chapter Five explains the format of an OSI address.
Chapter Six describes the
the architecture of the interprocess communication support in the
kernel, which to a large degree mandates
the design of a protocol implementation for a 4.3 Unix kernel.
.\" Appendix A is a list of the applicable ISO standards.
.\" The manual pages relevant to the transport and network layers
.\" are included as Appendix B.
.pp
Several conventions are followed in this document.
All procedure names and system call names are followed
by a pair of parentheses, for example,
.i read ().
References to manual pages consist of the name of the
manual page, followed by the section in which
the man page is found:
.i read (2).

331
share/doc/iso/ucb/ipc.nr Normal file
View File

@ -0,0 +1,331 @@
.NC "The Design of Unix IPC"
.sh 1 "General"
.pp
The ARGO implementation of
TP and CLNP was designed to fit into the AOS
kernel
as easily as possible.
All the standard protocol hooks are used.
To understand the design, it is useful to have
read
Leffler, Joy, and Fabry:
\*(lq4.2 BSD Networking Implementation Notes\*(rq July 1983.
This section describes the
design of the IPC support in the AOS kernel.
.sh 1 "Functional Unit Overview"
.pp
The
AOS
kernel
is a monolithic program of considerable size and complexity.
The code can be separated into parts of distinct function,
but there are no kernel processes per se.
The kernel code is either executed on behalf of a user
process, in which case the kernel was entered by a system call,
or it is executed on behalf of a hardware or software interrupt.
The following sections describe briefly the major functional units
of the kernel.
.\" FIGURE
.so ../wisc/figs/func_units.nr
.CF
shows the arrangement of these kernel units and
their interactions.
.sh 2 "The file system."
.pp
.sh 2 "Virtual memory support."
.pp
This includes protection, swapping, paging, and
text sharing.
.sh 2 "Blocked device drivers (disks, tapes)."
.pp
All these drivers share some minor functional units,
such as buffer management and bus support
for the various types of busses on the machine.
.sh 2 "Interprocess communication (IPC)."
.pp
This includes
support for various protocols,
buffer management, and a standard interface for inter-protocol
communication.
.sh 2 "Network interface drivers."
.pp
These drivers are closely tied to the IPC support.
They use the IPC's buffer management unit rather
than the buffers used by the blocked device drivers.
The interface between these drivers and the rest of the kernel
differs from the interface used by the blocked devices.
.sh 2 "Tty driver"
.pp
This is terminal support, including the user interface
and the device drivers.
.sh 2 "System call interface."
.pp
This handles signals, traps, and system calls.
.sh 2 "Clock."
.pp
The clock is used in various forms by many
other units.
.sh 2 "User process support (the rest)."
.pp
This includes support for accounting, process creation,
control, scheduling, and destruction.
.pp
.sh 2 "IPC"
.pp
The major functional unit that supports IPC
can be divided into the following smaller functional
units.
.sh 3 "Buffer management."
.pp
All protocols share a pool of buffers called \fImbufs\fR.
The internal structure has changed considerably since 4.3:
.(b
\fC
.TS
tab(+);
l s s s.
struct mbuf {
.T&
l l l l.
+struct mbuf+*m_next;+/* next buffer in chain */
+struct mbuf+*m_act;+/* link in 2-d structure */
+u_long+m_len;+/* amount of data */
+char *+m_data;+/* location of data */
+short+m_type;+/* type of data */
+short+m_flags;+/* note if EOR, Packet HDR, Ext. stored */
+++/* If packet header add: */
int+m_pkthdr.len;+/* total packet length */
struct ifnet+*m_pkthdr.recvif;+/* rcv interface*/
+++/* If external storage add: */
+char +*m_ext.ext_buf;+/* start of buffer */
+void+(*m_ext.ext_free)();+/* free routine if not the usual */
+u_int+m_ext.ext_size;+/* size of buffer, for ext_free */
+++/* For non external */
+char+m_dat[depending];+/* done by unions, etc. */
};
.TE
\fR
.)b
.pp
There are two forms of mbufs - with and without external storage.
Small ones are 128 octets in 4.4BSD.
The data in these mbufs are located
in the mbuf structure itself.
Large mbufs, called \fIclusters\fR, are page-sized
and page-aligned.
They may be \*(lqcopied\*(rq by multiply mapping the pages they occupy.
They consist of a page of memory plus a small mbuf structure
whose fields are used
to link clusters into chains, but whose \fIm_dat\fR array is
not used.
The \fIm_data\fR field of the structure
is a pointer to the active data in all cases.
The remainder of the description in the argo document
is generally obsolete, and I am merely deleting the
rest of it at this point.
.sh 3 "Routing."
.pp
Routing decisions in the kernel are made by the procedure \fIrtalloc()\fR.
This procedure will scan the kernel routing tables (stored in mbufs)
looking for a route.
The argo document here also is quite obsolete.
We know keep a tree structure routing table,
and do matching under masks.
The structure for the routing entry contains tree related
stuff pointers (parent, l-r child for internal nodes, mask and address
for external nodes), and may be completely revised again
to make use of patricia trees.
.pp
If a route is not found, then a default route is used (if present).
.pp
If a route is found, the entity which called \fIrtalloc()\fR can use information
from the \fIrtentry\fR structure to dispatch the datagram. Specifically, the
datagram is queued on the interface identified by the interface
pointer \fIrt_ifp\fR.
.sh 3 "Socket code."
.pp
This is the protocol-independent part of the IPC support.
Each communication endpoint (which may or may not be associated
with a connection) is represented by the following structure:
.(b
\fC
.TS
tab(+);
l s s s.
struct socket {
.T&
l l l l.
+short+so_type;+/* type, e.g. SOCK_DGRAM */
+short+so_options;+/* from socket call */
+short+so_linger;+/* time to linger @ close */
+short+so_state;+/* internal state flags */
+caddr_t+so_pcb;+/* network layer pcb */
+struct protosw+*so_proto;+/* protocol handle */
+struct socket+*so_head;+/* ptr to accept socket */
+struct socket+*so_q0;+/* queue of partial connX */
+short+so_q0len;+/* # partials on so_q0 */
+struct socket+*so_q;+/* queue of incoming connX */
+short+so_qlen;+/* # connections on so_q */
+short+so_qlimit;+/* max # queued connX */
+struct sockbuf+{
++short+sb_cc;+/* actual chars in buffer */
++short+sb_hiwat;+/* max actual char count */
++short+sb_mbcnt;+/* chars of mbufs used */
++short+sb_mbmax;+/* max chars of mbufs to use */
++short+sb_lowat;+/* low water mark (not used yet) */
++short+sb_timeo;+/* timeout (not used ) */
++struct mbuf+*sb_mb;+/* the mbuf chain */
++struct proc+*sb_sel;+/* process selecting */
++short+sb_flags;+/* flags, see below */
+} so_rcv, so_snd;
+short+so_timeo;+/* connection timeout */
+u_short+so_error;+/* error affecting connX */
+short+so_oobmark;+/* oob mark (TCP only) */
+short+so_pgrp;+/* pgrp for signals */
}
.TE
\fR
.)b
.pp
The socket code maintains a pair of queues for each socket,
\fIso_rcv\fR and \fIso_snd\fR.
Each queue is associated with a count of the number of characters
in the queue, the maximum number of characters allowed to be put
in the queue, some status information (\fIsb_flags\fR), and
several unused fields.
For a send operation, data are copied from the user's address space
into chains of mbufs.
This is done by the socket module, which then calls the underlying
transport protocol module to place the data
on the send queue.
This is generally done by
appending to the chain beginning at \fIsb_mb\fR.
The socket module copies data from the \fIso_rcv\fR queue
to the user's address space to effect a receive operation.
The underlying transport layer is expected to have put incoming
data into \fIso_rcv\fR by calling procedures in this module.
.in -5
.sh 3 "Transport protocol management."
.pp
All protocols and address types must be \*(lqregistered\*(rq in a
common way in order to use the IPC user interface.
Each protocol must have an entry in a protocol switch table.
Each entry takes the form:
.(b
\fC
.TS
tab(+);
l s s s.
struct protosw {
.T&
l l l l.
+short+pr_type;+/* socket type used for */
+short+pr_family;+/* protocol family */
+short+pr_protocol;+/* protocol # from the database */
+short+pr_flags;+/* status information */
+++/* protocol-protocol hooks */
+int+(*pr_input)();+/* input (from below) */
+int+(*pr_output)();+/* output (from above) */
+int+(*pr_ctlinput)();+/* control input */
+int+(*pr_ctloutput)();+/* control output */
+++/* user-protocol hook */
+int+(*pr_usrreq)();+/* user request: see list below */
+++/* utility hooks */
+int+(*pr_init)();+/* initialization hook */
+int+(*pr_fasttimo)();+/* fast timeout (200ms) */
+int+(*pr_slowtimo)();+/* slow timeout (500ms) */
+int+(*pr_drain)();+/* free some space (not used) */
}
.TE
\fR
.)b
.pp
Associated with each protocol are the types of socket
abstractions supported by the protocol (\fIpr_type\fR), the
format of the addresses used by the protocol (\fIpr_family\fR),
the routines to be called to perform
a standard set of protocol functions (\fIpr_input\fR,...,\fIpr_drain\fR),
and some status information (\fIpr_flags\fR).
The field pr_flags keeps such information as
SS_ISCONNECTED (this socket has a peer),
SS_ISCONNECTING (this socket is in the process of establishing
a connection),
SS_ISDISCONNECTING (this socket is in the process of being disconnected),
SS_CANTSENDMORE (this socket is half-closed and cannot send),
SS_CANTRCVMORE (this socket is half-closed and cannot receive).
There are some flags that are specific to the TCP concept
of out-of-band data.
A flag SS_OOBAVAIL was added for the ARGO implementation, to support
the TP concept of out-of-band data (expedited data).
.sh 3 "Network Interface Drivers"
.pp
The drivers for the devices attaching a Unix machine to a network
medium share a common interface to the protocol
software.
There is a common data structure for managing queues,
not surprisingly, a chain of mbufs.
There is a set of macros that are used to enqueue and
dequeue mbuf chains at high priority.
A driver
delivers an indication to a protocol entity when
an incoming packet has been placed on a queue by
issuing a
software
interrupt.
.sh 3 "Support for individual protocols."
.pp
Each protocol is written as a separate functional unit.
Because all protocols share the clock and the mbuf pool, they
are not entirely insulated from each other.
The details of TP are described in a section that
follows.
.\"*****************************************************
.\" FIGURE
.so ../wisc/figs/unix_ipc.nr
.pp
.CF
shows the arrangement of the IPC support.
.pp
The AOS
IPC was designed for DoD Internet protocols, all of
which run over DoD IP.
The assumptions that DoD Internet is the domain
and that DoD IP is the network layer
appear in the code and data structures in numerous places.
An example is that the transport protocols all directly call
IP routines.
There are no hooks in the data structures through
which the transport layer can choose a network level protocol.
Another example is that headers are assumed to
fit in one small mbuf (112 bytes for data in AOS).
Another example is this:
It is assumed in many places that buffer space is managed
in units of characters or octets.
The user data are copied from user address space into the kernel mbufs
amorphously
by the socket code, a protocol-independent part of the kernel.
This is fine for a stream protocol, but it means that a
packet protocol, in order to \*(lqpacketize\*(rq the data,
must perform a memory-to-memory copy
that might have been avoided had the protocol layer done the original
copy from user address space.
Furthermore, protocols that count credit in terms of packets or
buffers rather than characters do not work efficiently because
the computation of buffer space is not in the protocol module,
but rather it is in the socket code module.
This list of examples is not complete.
.pp
To summarize, adding a new transport protocol to the kernel consists of
adding entries to the tables in the protocol management
unit,
modifying the network interface driver(s) to recognize
new network protocol identifiers,
adding the
new system calls to the kernel and to the user library,
and
adding code modules for each of the protocols,
and correcting deficiencies in the socket code,
where the assumptions made about the nature of
transport protocols do not apply.
.i
(Touchy touchy, aren't we!?! -- Sklower)

50
share/doc/iso/ucb/macros.nr Normal file
View File

@ -0,0 +1,50 @@
.\"
.\" Macro to initialize chapter macros
.\"
.de IC
.nr CN 0 1
..
.\"
.\" Macro to begin new chapter
.\"
.de NC
.he 'ARGO user\'s Guide, Berkeley Hack Job''Chapter \\n+(CN'
.bp
.sh 0 "_" 1 1 1 1 1 1
.sz +2
.(l C
CHAPTER \\n(CN
\fB\\$1\fR
.)l
.sp 1
.(x
Chapter \\n(CN \\$1
.)x
.sz -2
..
.\"
.\" Figure conventions:
.\" 1) do .so of figure source - figure reg incremented here
.\" 2) make references to figure via CF
.\"
.\"
.\" Macro to initialize figure register
.\"
.de IF
.nr FG 0 1
..
.\"
.\" Macro for current figure number
.\"
.de CF
Figure \\n(FG
..
.\"
.\" Define this macro to include section headings in table of contents
.\"
.de $0
.(x
Section \\$2 \\$1
.)x
..

163
share/doc/iso/ucb/net_serv.nr Normal file
View File

@ -0,0 +1,163 @@
.NC "Network Service Interface"
.sh 1 "Connectionless Network Service"
.pp
This section describes the interface to the ISO connectionless network service.
There are really two interfaces to the CLNS: the internal interface
and the IPC interface.
The internal interface is based on
procedure calls. It is used only within the kernel. The IPC interface
allows a user process to access the CLNS directly. This is used only
for testing and debugging purposes.
.sh 2 "Primitives"
.pp
The CLNS is, by definition, connectionless. Therefore, there are no
primitives associated with connection establishment or connection release.
There is one primitive associated with data transfer: N-UNITDATA.
The parameters to a N-UNITDATA request are: source NSAP address,
destination NSAP address, quality of service, and user data.
The parameters of a N-UNITDATA indication are identical to those of the
request.
In this implementation, the quality of service parameter is not supported.
.sh 2 "Internal Interface"
.pp
Within the kernel, an N-UNITDATA request is effected by the procedure
\fIclnp_output()\fR:
.(b
\fC
.TS
tab(+);
l s s.
clnp_output(m0, isop, datalen, flags)
.T&
l l l.
+struct mbuf+*m0;+/* data */
+struct isopcb+*isop;+/* ISO protocol control block */
+int+datalen;+
+int+flags;+/* flags */
.TE
\fR
.)b
This procedure will construct a DT NPDU, route it, and transmit it on
the appropriate subnetwork. \fIM0\fR is an mbuf chain containing the
user data portion of the N-UNITDATA request. \fIIsopcb\fR is the iso protocol
control block previously allocated. \fIClnp_output\fR will use the following
fields: \fIisop_laddr\fR, isop_faddr, isop_route, isop_options,
isop_optindex, \fI and \fRisop_clnpcache\fR.
\fIDatalen\fR specifies the number of bytes of user data.
The \fIflags\fR parameter will be discussed in a subsequent chapter.
.pp
A N-UNITDATA indication occurs when a DT NPDU arrives. The indication is
generated by calling the appropriate upper layer protocol input routine.
In the case of TP, the procedure \fItpclnp_input()\fR is called:
.(b
\fC
.TS
tab(+);
l s s.
tpclnp_input(m, src, dst, len)
.T&
l l l.
+struct mbuf+*m;+/* DT NPDU */
+struct iso_addr+*src;+/* source of packet */
+struct iso_addr+*dst;+/* destination of packet */
+int+len;+/* length of clnp header */
.TE
\fR
.)b
\fIM\fR contains the entire DT NPDU packet. \fILen\fR indicates the size
of the CLNP header. In other words, the user data of the DT NPDU begins
\fIlen\fR bytes into \fIm\fR. \fISrc\fR and \fIdst\fR indicate the
source and destination NSAP addresses of the packet.
.sh 3 "CLNP/Subnetwork Interface"
.pp
The design of the interface between the subnetwork and the CLNP is
determined by the design of the Unix network interface drivers. CLNP
follows the conventional mechanisms for exchanging packets with a network
interface. See the section on Network Interface Drivers in Chapter Five
for more information on these conventions.
.sh 2 "IPC (\*(lqRaw\*(rq) Interface"
.pp
The IPC interface to the CLNS allows direct (called \*(lqraw\*(rq)
access to CLNP.
This interface is intended for testing and debugging only.
Its use results in the
transmission of CLNP datagrams with nonstandard identification fields.
These raw packets may be rejected by a system not employing the same
convention. See the section on network implementation for more information
about the conventions.
.pp
In order to gain access to the raw interface
a \fIsocket\fR, with address family AF_ISO and type SOCK_RAW must be created.
With this socket in hand,
the system calls \fIsendto()\fR and \fIrecvfrom()\fR can be used to
transmit and receive raw CLNP datagrams.
.sh 3 "Sending raw datagrams"
.pp
The format of the \fIsendto()\fR system call is:
.(b
\fC
.TS
tab(+);
l s s.
cc = sendto(s, msg, len, flags, to, tolen)
.T&
l l l.
int+cc,s;
char+*msg;
int+len,flags;
struct sockaddr+*to;
int+to;
.TE
\fR
.)b
\f\fIS\fR is the socket previously created. \fIMsg\fR is a pointer to
the data for the NPDU. CLNP will prepend a header to this data before
transmission. \fILen\fR specifies the number of bytes of data. The
\fIflags\fR parameter is unused and should be zero. \fITo\fR specifies the
NSAP address to be used as the destination address. The size (in bytes)
of \fIto\fR is given in \fItolen\fR. CLNP will automatically insert
the source address based upon the route taken by the packet. The number of
user data bytes transmitted is returned as \fIcc\fR. See \fIsendto(2)\fR
for more information on this system call.
.sh 3 "Receiving raw datagrams"
.pp
The format of the \fIrecvfrom()\fR system call is:
.(b
\fC
.TS
tab(+);
l s s.
cc = recvfrom(s, buf, len, flags, from, fromlen)
.T&
l l l.
int+cc,s;
char+*buf;
int+len,flags;
struct sockaddr+*from;
int+*fromlen;
.TE
\fR
.)b
When used with a CLNP raw socket \fIs\fR, \fIrecvfrom()\fR will read a
NPDU from the CLNS. If no packet is available, the call will block.
\fIBuf\fR specifies a buffer of \fIlen\fR bytes into which the NPDU will
be read. The entire packet, including the header, will be read into the
buffer. The \fIflags\fR parameter is unused, and should be zero. If
\fIfrom\fR is non-zero, the source address of the NPDU is filled in.
\fIFromlen\fR is a value-result parameter, initialized to the size of
the buffer associated with \fIfrom\fR, and modified on return to
indicate the actual size of the address stored there. The total number
of bytes received (header and data) is returned as \fIcc\fR.
See \fIrecvfrom(2)\fR for more information about this system call.
.sh 1 "Connection Oriented Network Service"
.pp
The ARGO Connection Oriented Network Service (CONS) is not a complete
implementation of the
OSI network service.
It is that subset of the OSI network service that is used
by ARGO Transport and by ARGO CLNP.
.\" FIGURE
.so ../wisc/figs/NS_primitives.nr
.pp
.CF
shows which CONS service elements are provided.

42
share/doc/iso/ucb/program.nr Normal file
View File

@ -0,0 +1,42 @@
.\"$Header: /cvsroot/src/share/doc/iso/ucb/Attic/program.nr,v 1.1.1.1 1994/06/19 00:07:24 cgd Exp $
.\"$Source: /cvsroot/src/share/doc/iso/ucb/Attic/program.nr,v $
.\"
.\"
.\" FONT CONVENTIONS
.\"
.\" \fIprocedure()\fR
.\" \fIsyscall()\fR
.\" \fImanpage(3)\fR
.\" \fIdata_structure_name\fR
.\" \fC/file/or/directory/name\fR
.\" \fC
.\" section of code
.\" \fR
.\"
.\"
.\" LOOK FOR ALL CASES OF 'writing' (as in, "at this writing")
.\" to be sure you've updated everything before distributing this!
.\"
.\"This file uses -me and tbl macros.
.so macros.nr
.\" .pn 1
.IC
.IF
.\" .(l C
.\" .sz 16
.\" Berkeley's Hack at the first 6 chapters of
.\" Wisconsin ARGO 1.0 Kernel Programmer's Guide for
.\" Academic Operating Systems 4.3
.\" .sz 8
.\" .)l
.he 'ARGO 1.0 Berkeley Revision User\'s Guide'''
.fo '%''December 9, 1988'
.\" .bp
.so intro.nr
.so def.nr
.so trans_serv.nr
.so net_serv.nr
.so ipc.nr
.so addr.nr
.bp
.xp

697
share/doc/iso/ucb/trans_serv.nr Normal file
View File

@ -0,0 +1,697 @@
.NC "Transport Service Interface"
.sh 1 "General"
.pp
It is assumed that the reader is acquainted with the
set of system calls and library routines that
compose the
Berkeley
Unix interprocess communication service (IPC).
To every extent possible
the ARGO transport service is provided by the same IPC mechanisms
that support
the transport-level services
included in the
AOS distribution.
In some instances, the interface
provided by AOS does not support
the services required by ISO 8073,
so system calls were added to support these services.
It is felt that this is superior to modifying
existing system calls, in order to avoid the
recoding of existing Unix utilities.
.pp
What follows is a description of the system calls
that are used to provide the transport service.
According to Unix custom,
the return value of a system call is 0
if the call succeeds and -1 if
the call fails for any reason.
In the latter case,
the global variable
\fIerrno\fR contains more information
about the error that caused the failure.
In the descriptions of all the system calls for which
this custom is followed,
the return value is named
\fIstatus\fR.
.sh 1 "Connection establishment"
.pp
Establishing a TP connection is similar to
establishing a connection using any other
transport protocol supported by Unix.
The same system calls are used, and the passive open
is required.
Some of the parameters to the system calls differ.
.pp
The following call creates a communication endpoint called a
\fIsocket\fR.
It returns
a positive integer called a
\fIsocket descriptor\fR,
which
will be a parameter in all communication primitives.
.(b
\fC
.TS
tab(+);
l s s s.
s = socket( af, type, protocol )
.T&
l l l.
+int+s,af,type,protocol;
.TE
\fR
.)b
.pp
The \fIaf\fR parameter describes the format of addresses
used in this communication.
Existing formats include AF_INET (DoD Internet addresses),
AF_PUP (Xerox PUP-I Internet addresses), and AF_UNIX
(addresses are Unix file names, for intra-machine IPC only).
TP runs in either the Internet domain or the ISO domain (AF_ISO).
When using the Internet domain, the network layer is the DoD Internet IP
with Internet-style addresses. The ISO domain uses the ISO
network service and ISO-style addresses\**.
.(f
\**ISO/DP 8348/DAD2 Addendum to the Network
Service Definition Covering Network Layer Addressing.
.)f
Regardless of the address family used, an address takes the
general form,
.(b
\fC
.TS
tab(+);
l s s s.
struct sockaddr {
.T&
l l l l.
+u_char+sa_len;+/* length of sockaddr */
+u_char+sa_family;+/* address family */
+char+sa_data[14];+/* space for an address */
}+
.TE
\fR
.)b
.lp
.i
A sockaddr is no longer required to be precisely 16 bytes long.
The allocation of 14 bytes for sa_data is intended for backwards
compatibility.
.r
.sp 1
When viewed as an Internet address, it takes the form
.(b
\fC
.TS
tab(+);
l s s s.
struct sockaddr_in {
.T&
l l l l.
+u_char+sin_len;+/* address length */
+u_char+sin_family;+/* address family */
+u_short+sin_port;+/* internet port */
+struct in_addr+sin_addr;+/* network addr A.B.C.D */
+char+sin_zero[8];+/* unused */
}
.TE
\fR
.)b
.sp 1
When viewed as an ISO address, as supplied by the
university of wisconsin, it takes the form
.(b
\fC
.TS
tab(+);
l s s s.
struct sockaddr_iso {
.T&
l l l l.
+u_char+siso_len;+/* address length */
+u_char+siso_family;+/* address family */
+u_short+siso_tsuffix;+/* transport suffix */
+struct iso_addr+siso_addr;+/* ISO NSAP addr */
+char+siso_zero[2];+/* unused */
}
.TE
\fR
.)b
The address described by a \fIsockaddr_iso\fR structure
is a TSAP-address (transport service access point address).
It is made of an NSAP-address (network service access point address)
and a TSAP selector (also called a transport suffix or
transport selector, hereafter called a TSEL).
The structure \fIsockaddr_iso\fR contains a 2-byte TSEL.
This is for compatibility with Internet addressing.
ARGO supports
TSELs of length 1-64 bytes.
TSELs of any length other than 2
are called \*(lqextended TSELs\*(rq.
They are described in detail in the section \fB\*(lqExtended TSELs\*(rq\fR.
If extended TSELs are not requested, 2-byte TSELs are used by default.
.pp
Refer to Chapter Five for more information about ISO NSAP-addresses.
.pp
.i
It is our intent at Berkeley to revamp the sockaddr_iso
to use a more natural and uniform model, for ISO addresses.
We cannot guarantee this modification to be complete by the
time we are ready to have something for NIST to test.
We hope to remove this notion of extended TSEL's as soon as
possible, certainly by formal beta testing of 4.4.
.r
Since sockaddr can be 108 bytes long without breaking anything
in the current Berkeley kernel, we should be able to eliminate
extended TSEL's entirely by
providing a sockaddr_iso along the lines of:
.(b
\fC
.TS
tab(+);
l s s s.
struct sockaddr_iso {
.T&
l l l l.
+u_char+siso_len;+/* address length */
+u_char+siso_family;+/* address family */
+u_char+siso_slen;+/* session suffix length */
+u_char+siso_tlen;+/* transport suffix length */
+u_char+siso_nlen;+/* nsap length */
+char+siso_data[22];+/* minimum nsap + tsel */
}
.TE
\fR
.)b
.pp
The \fItype\fR parameter in the \fIsocket()\fR call
distinguishes
datagram protocols, stream protocols, sequenced
packet protocols, reliable datagram protocols, and
"raw" protocols (in other words, the absence of a transport protocol).
Unix provides manifest named constants for each of these types.
TP supports the sequenced packet protocol abstraction, to which
the manifest constant SOCK_SEQPACKET applies.
.pp
The \fIprotocol\fR
parameter is an integer that identifies the protocol to be used.
Unix provides a database of protocol names and their associated
protocol numbers.
Unix also provides user-level tools
for searching the database.
The tools take the form of library routines.
A protocol number for TP has been chosen
by the Internet NIC to allow TP to run in the Internet domain, and this
has been added to the Unix network protocol database.
The standard Internet database tools that serve TCP users
can
also serve user of TP
in the Internet domain, if the TP protocol number is added to the
proper Internet database file,
\fC/etc/protocols\fR.
This change must be made for TP to run in either the Internet or
in the ISO domain.
The ARGO package contains a set of tools and a database
for use with TP in the ISO domain.
This set of tools is described in the manual pages
\fIisodir(5)\fR and
\fIisodir(3)\fR.
.pp
When a socket is created, it is not given an address.
Since a socket cannot be reached by a remote entity unless it has an address,
the user must request that a socket be given an address by
using the \fIbind()\fR system call:
.(b
\fC
.TS
tab(+);
l s s s.
status = bind( s, addr, addrlen )
.T&
l l l.
+int+s;
+struct sockaddr+*addr;
+int+addrlen;
.TE
\fR
.)b
.pp
The address is expected to be in the format specified by the
\fIaf\fR parameter to the \fIsocket()\fR
call that yielded the socket descriptor \fIs\fR.
If the user
passes an address parameter with a zero-valued transport suffix,
the transport layer
assigns an unused 2-byte transport selector.
This is a 4.3 Unix convention; it is not part of any ISO standard.
.pp
The \fIconnect()\fR system call effects an active open.
It is used to establish a connection with an entity that is
passively waiting for connection requests, and whose
transport address is known.
.(b
\fC
.TS
tab(+);
l s s s.
status = connect( s, addr, addrlen )
.T&
l l l.
+int+s;
+struct sockaddr+*addr;
+int+addrlen;
.TE
\fR
.)b
.pp
The first parameter is a socket descriptor.
The \fIaddr\fR parameter is a transport address in the format
specified by the \fIaf\fR parameter to the \fIsocket()\fR
call that yielded the socket descriptor \fIs\fR.
.pp
A passive open is accomplished with two system calls,
\fIlisten()\fR followed by \fIaccept()\fR.
.(b
\fC
.TS
tab(+);
l s s s.
status = listen( s, queuelen )
.T&
l l l.
+int+s;
+int+queuelen;
.TE
\fR
.)b
.pp
The \fIqueuelen\fR argument specifies the maximum
number of pending connection
requests that will be queued for acceptance by this user.
Connections are then accepted by the
system call \fIaccept()\fR.
There is no way to refuse connections.
The functional equivalent of connection
refusal is accomplished by accepting a connection and immediately
disconnecting.
.(b
\fC
.TS
tab(+);
l s s s.
new_s = accept( s, addr, addrlen )
.T&
l l l.
+int+new_s, s;
+struct sockaddr+*addr;
+int+addrlen;
.TE
\fR
.)b
.pp
The \fIaccept()\fR call completes the connection
establishment. If a connection request from a prospective peer
is pending on the socket described by \fIs\fR, it is removed and
a new socket is created for use with this connection.
A socket descriptor for the new socket is returned by the
system call.
If no connection requests are pending, this call blocks.
If the \fIaccept()\fR call fails, -1 is returned.
The transport address of the entity requesting the connection
is returned in the \fIaddr\fR parameter, and the length
of the address is returned in the \fIaddrlen\fR parameter.
The address associated with the new socket is inherited
from the socket on which the \fIlisten()\fR and \fIaccept()\fR were performed.
.pp
It is possible for the \fIaccept()\fR call to be interrupted
by an asynchronous event such as the arrival of expedited
data.
When system calls are interrupted, Unix returns the value -1
to the caller and puts the constant
EINTR in the global variable \fIerrno\fR.
This can create problems with the system call \fIaccept()\fR.
In the case of incoming expedited data, the interruption does
not indicate a problem, but the data may have arrived before
the caller has received the new socket descriptor, which is the
socket descriptor on which the expedited data are to be received.
In order to prevent this problem from occurring, the caller must
prevent the issuance of asynchronous indications until the
\fIaccept()\fR
call has returned.
Asynchronous indications are discussed below, in
the section titled
"Indications from the transport layer to the transport user".
.pp
It is possible to discover the
address bound to a
socket with the
\fIgetsockname()\fR system call.
.(b
\fC
.TS
tab(+);
l s s s.
status = getsockname( s, addr, addrlen )
.T&
l l l.
+int+s;
+struct sockaddr+*addr;
+int+addrlen;
.TE
\fR
.)b
.pp
If the socket has a peer, that is, it is connected,
the system call
\fIgetpeername()\fR
is used to discover the peer's address.
.(b
\fC
.TS
tab(+);
l s s s.
status = getpeername( s, addr, addrlen )
.T&
l l l.
+int+s;
+struct sockaddr+*addr;
+int+addrlen;
.TE
\fR
.)b
.lp
The names returned by
\fIgetsockname()\fR and \fIgetpeername()\fR
do not contain extended TSELs.
Extended TSELs can be retrieved with
the \fIgetsockopt()\fR and
\fIsetsockopt()\fR system calls, described below.
.pp
Unix supports several protocol-independent options
and protocol-specific options
associated with sockets.
These options can be inspected and changed by using
the \fIgetsockopt()\fR and
\fIsetsockopt()\fR system calls.
.(b
\fC
.TS
tab(+);
l s s s.
status = getsockopt( s, level, option, value, valuelen )
.T&
l l l.
+int+s, level, option;
+char+*value;
+int+*valuelen;
.TE
\fR
.)b
.(b
\fC
.TS
tab(+);
l s s s.
status = setsockopt( s, level, option, value, valuelen )
.T&
l l l.
+int+s, level, option;
+char+*value;
+int+valuelen;
.TE
\fR
.)b
.pp
The \fIlevel\fR argument may indicate
either
that this option applies to sockets or that it applies to
a specific protocol.
The constants SOL_SOCKET, SOL_TRANSPORT, and SOL_NETWORK
are possible values for the \fIlevel\fR argument.
The \fIoption\fR argument is an integer that identifies
the option chosen.
.\" LIST THE OPTIONS HERE
The options available to TP users provide the
user with the ability to control various TP protocol options
including but not limited to
TP class, TPDU size negotiated, TPDU format used,
acknowledgment and retransmission strategies.
For a detail list of the options, see the manual page \fItp(4p)\fR.
.sh 1 "Extended TSELs"
.pp
ARGO supports TSELs
of length 1 byte - 64 bytes for sockets bound to addresses in the
AF_ISO address family.
The ARGO user program uses the
\fIgetsockopt()\fR
and
\fIsetsockopt()\fR
system calls to
discover and assign extended TSELs.
.pp
To create a socket with an extended TSEL,
the process
.ip \(bu 5
opens a socket with \fCsocket(AF_ISO, SOCK_SEQPACKET, ISOPROTO_TP)\fR
.ip \(bu 5
binds an NSAP-address to the socket with \fIbind()\fR.
The address bound may contain a 2-byte selector (\fIiso_tsuffix\fR).
.ip \(bu 5
uses \fIsetsockopt()\fR with the command TPOPT_MY_TSEL,
to assign a TSEL to the socket.
.ip \(bu 5
calls \fIlisten(), connect()\fR, or any other appopriate system calls
to use the socket as desired.
.lp
To connect to a transport entity that is bound to a TSAP-address with
an extended TSEL, the
process
.ip \(bu 5
opens a socket with \fCsocket(AF_ISO, SOCK_SEQPACKET, ISOPROTO_TP)\fR
.ip \(bu 5
uses \fIsetsockopt()\fR, with the command TPOPT_PEER_TSEL,
to assign a PEER TSEL to the socket.
This TSEL is used by the transport entity
for all subsequent connect requests made on this socket,
unless the peer TSEL is changed by another call to
\fIsetsockopt()\fR employing the command TPOPT_PEER_TSEL.
.lp
To discover the TSEL of the peer of a connected socket,
the process
.ip \(bu 5
uses \fIgetsockopt()\fR with the command TPOPT_PEER_TSEL.
.lp
To discover the TSEL of socket's own address,
the process
.ip \(bu 5
uses \fIgetsockopt()\fR with the command TPOPT_MY_TSEL.
.sh 1 "Data transfer"
.pp
Earlier BSD-based systems have provided system calls for data transfer
having bugs and semantics that are problematic for TP.
These should be correct as presented in the test system.
The problem was in the manner in which the kernel
handled interrupted system calls.
The send and receive primitives
may be interrupted by signals.
A signal is the mechanism used to indicate
the presence of expedited data or out-of-band data.
If the send primitive as interrupted before completion,
the user could not determine how many octets of data were sent.
All forms of the existing interface
(\fIsend()\fR,
\fIrecv()\fR,
\fIsendmsg()\fR,
\fIrecvmsg()\fR,
\fIsendto()\fR,
\fIrecvfrom()\fR,
\fIwrite()\fR,
\fIread\fR,
\fIwritev()\fR,
and \fIreadv()\fR system calls)
return an octet count
when the system call completes, and to return a short count
if the system call is interrupted.
.pp
The system calls sendmsg and recvmsg
have been revised to make them more convenient for receipt of
out of band data.
.(b
\fC
.TS
tab(+);
l s s s.
cc = sendmsg( s, msg, flags )
.T&
l l l.
+int+s;
+istruct msghdr+msg;
+unsigned int+flags;
.TE
\fR
.)b
.(b
\fC
.TS
tab(+);
l s s s.
cc = recvmsg( s, msg, flags )
.T&
l l l.
+int+s;
+istruct msghdr+msg;
+unsigned int+flags;
.TE
\fR
.)b
.pp
The reader should now consult the manual page for recvmsg
for an explanation of the elements of the msghdr structure,
and how the calls may be used to glean user-connection-request data.
.pp
The \fIflags\fR parameter serves several purposes.
The TP specification requires that TSDUs be unlimited in size.
System calls cannot pass unlimited amounts of data between the user
and the kernel, so
there cannot be a one-to-one correspondence between TSDUs and
system calls.
The \fIflags\fR
parameter is used to mark the end-of-TSDU on sending data.
When receiving,
TP sets this bit
in the flags element of the msghdr structure
when the end of a TSDU is consumed.
This way one TSDU can span several system calls.
It is possible for the peer to send an empty TPDU with the end-of-TSDU
flag set, in which case the transport user
may receive zero octets with the end-of-TSDU flag set.
.pp
The \fIflags\fR parameter also serves to distinguish data transfer primitives
from expedited data transfer primitives.
The flag bit MSG_OOB is provided for "out of band data" in the
DoD Internet protocols. It is also used to provide the expedited data service
of the ISO protocols.
The transport layer will deliver one expedited datum (there will be a
one-to-one correspondence between expedited TSDUs and XPD TPDUs)
at a time.
The user must receive the datum before the transport
layer will accept more expedited data.
Each expedited datum my contain up to 16 octets.
.pp
.sh 1 "Disconnection"
.pp
The \fIclose\fR system call will disconnect any association
between two TP entities.
.(b
\fC
.TS
tab(+);
l s s s.
status = close( s )
.T&
l l l.
+int+s;
.TE
\fR
.)b
.pp
The argument \fIs\fR is a socket descriptor.
If a Unix user process terminates, Unix will close all files and
sockets associated with the process, which means all transport
connections associated with the process will be disconnected.
.sh 1 "Indications from the transport layer to the transport user"
.pp
The above set of system calls allows you to establish
a connection, transfer data, and disconnect.
The
presence or reception of expedited data is indicated
by TP setting the MSG_OOB bit in the flags element of the msg structure.
A disconnection initiated by the peer or by one of the
cooperating TP entities can be signalled by a control message,
although we have not yet implemented this.
.pp
The Unix signal mechanism may be used to provide these
service elements, as well.
When an expedited data TSDU arrives, the TP may interrupt
the user with a SIGURG signal ("urgent condition present on socket").
The user must have previously registered a procedure to handle
the signal by using the \fIsigvec()\fR system call or the
\fIsignal()\fR library routine provided for that purpose.
The signal handler takes the form
.(b
\fC
.TS
tab(+);
l s s s.
int sighandler( signal_number)
.T&
l l l.
+int+signal_number;
.TE
\fR
.)b
.pp
The \fIsignal_number\fR argument will be the well-known constant SIGURG.
There are two reasons for
the transport layer to issue
a SIGURG:
expedited data
are present or
disconnection was initiated by a transport entity or by the peer.
Should the user have more than one transport connection open,
another system call is used to determine to which socket(s)
the urgent condition applies.
This is the \fIselect()\fR system call, described below.
.pp
When the SIGURG indicates a disconnection, there may be
user data from the peer present.
TP saves the disconnect data for the user to receive via the
\fIgetsockopt()\fR system call, or through the
.IR recvmsg ()
ancillary data mechanism.
.\"
.\"If the user does not receive the disconnect data before the
.\"reference timer expires, the data will be discarded and the
.\"socket will be closed.
.pp
Transport service users may use more than one transport
connection at a time.
The \fIselect()\fR system call facilitates this.
.(b
\fC
.TS
tab(+);
l s s s.
#include <sys/types.h>
+
nfound = select( num_to_scan, recvmask, sendmask,
+exceptmask, timeout )
.T&
l l l.
+int+nfound, num_to_scan;
+fd_set+*recvmask, *sendmask, *exceptmask;
+time+timeout;
.TE
\fR
.)b
.pp
This system call takes as parameters a set of masks
that specify a subset of the socket descriptors that are in
use by the user program.
\fISelect()\fR inspects the sockets to see if they have data
to be received, can service a send without blocking, or
have an exceptional condition pending, respectively.
The masks will be set upon return to indicate the socket descriptors
for which the respective conditions exist.
The \fInum_to_scan\fR argument limits the number of sockets that are
inspected.
The call will return within the amount of time given in the
\fItimeout\fR parameter, or, if the parameter is zero, \fIselect()\fR
will block indefinitely.
.\" FIGURE
.so ../wisc/figs/TS_primitives.nr
.pp
.CF
summarizes the mapping of the transport service primitives
to Unix facilities.

73
share/doc/iso/wisc/Makefile Normal file
View File

@ -0,0 +1,73 @@
#
# Makefile for the tp documents:
# design: TP design/source guide
# appendix_a: index of tp kernel routines & macros by macro/routine name
# appendix_b: index of tp kernel routines & macros by file name
#
PRINTER = 3a
TAGS = ../../sys/tags
SRCS = ../../sys/netargo/tp_*.c ../../sys/netargo/tp_*.h ../../sys/netargo/tp*.trans
TROFF = /usr/local/lib/troff
#
# Print via speedy for cycles sake...
# (assumes postscript printer...)
#
program:
@echo printer is $(PRINTER)
(cd figs; make)
format -P$(PRINTER) -t program.nr | rsh speedy psdit \| lpr -P$(PRINTER)
parts:
@echo printer is $(PRINTER)
(cd figs; make)
format -P$(PRINTER) -t parts.nr | rsh speedy psdit \| lpr -P$(PRINTER)
# format -P$(PRINTER) -t parts.nr > /dev/null
# soelim parts.nr | grn -P$(PRINTER) |\
# $(TROFF) -Tpsc | rsh speedy psdit \> /tmp/test
# soelim parts.nr | tbl > /tmp/parts.nr
clean:
/bin/rm -f core junk* a.out *.o spell_errs made
touch spell_errs
spell:
(cd figs; make)
(cd ../icon; make)
/usr/ucb/soelim program.nr | /usr/bin/spell -d hlista > spell_errs
newdict:
cat spell_errs | spellin /usr/dict/hlista > hlista
all: program appendix_a appendix_b appendix_c
appendix_c:
format -P$(PRINTER) appendix_c.nr
tbl ../man/man4/table1.src > ../man/man4/table1.nr
tbl ../man/man4/table2.src > ../man/man4/table2.nr
tbl ../man/man4/table3.src > ../man/man4/table3.nr
soelim ../man/man4/tp.4p.src > ../man/man4/tp.4p
ditroff -man -P$(PRINTER) ../man/man1/xebec.1
ditroff -man -P$(PRINTER) ../man/man2/sendv.2
ditroff -man -P$(PRINTER) ../man/man2/recvv.2
ditroff -man -P$(PRINTER) ../man/man3/libtp.3
ditroff -man -P$(PRINTER) ../man/man4/tp.4p
ditroff -man -P$(PRINTER) ../man/man8/tppt.8
ditroff -man -P$(PRINTER) ../man/man8/tpdebug.8
ditroff -man -P$(PRINTER) ../man/man8/tpstat.8
appendix_a:
ctags -x $(SRCS) | awk '{printf("%s %s %s\n", $$1, $$3, $$2)}'\
| sed -e 's-../../sys/netargo/--' > index_by_func.nr
format -P$(PRINTER) appendix_a.nr
appendix_b:
ctags -x $(SRCS) | awk '{printf("%s %s %s\n", $$3, $$1, $$2)}'\
| sed -e 's-../../sys/netargo/--' \
| sort \
| fmtxref -w 80 \
| sed -e 's/ / /' \
-e 's/ / /' \
> index_by_file.nr
format -P$(PRINTER) appendix_b.nr

18
share/doc/iso/wisc/Outline Normal file
View File

@ -0,0 +1,18 @@
Ch 1 Intro
Ch 2 Definitions
Ch 3 Transport Service Interface
Ch 4 Network Service Interface
- user interface
- kernel interface
Ch 5 Addressing
Ch 6 Design of Transport
Ch 7 Design of Network
Ch 8 Error Handling
- transport
- network
Ch 9 Guide to Transport Source Code
Ch 10 Guide to Network Source Code
Ch 11 Guide to Common Source Code
Ch 12 Testing & Debugging
- transport
- network

2
share/doc/iso/wisc/TODO Normal file
View File

@ -0,0 +1,2 @@
update clnp echo doc
add esis

155
share/doc/iso/wisc/addr.nr Normal file
View File

@ -0,0 +1,155 @@
.NC "NSAP Addresses & Routing"
.sh 1 "OSI Address Formats"
.pp
ARGO supports an ISO address family, AF_ISO, in addition to the
DoD Internet address family, AF_INET.
Addresses in the family AF_ISO
take the form described by ISO 8348/DAD2, which is an addendum to the
OSI network service standard that describes network layer addressing.
.sh 2 "ISO 8348/DAD2 Tutorial"
.pp
.\" FIGURE
.\".so figs/osi_addr.nr
.so figs/addrfmt.nr
.CF
shows the
format of an OSI NSAP-address.
The address has two major parts: the initial domain part
(IDP) and the domain specific part (DSP). The IDP is further divided into
two parts: the authority and format identifier (AFI) and the
initial domain identifier (IDI). The AFI specifies the format of the
IDI, the authority responsible for allocating values of the IDI, and
the syntax of the DSP. The IDI specifies the network addressing domain
from which DSP values are allocated, and the authority responsible for
allocating DSP values.
.sh 2 "Supported Formats"
.pp
ARGO supports three types of ISO NSAP-addresses:
one type with AFI 37(hex) and two types with AFI 47(hex).
.sh 3 "AFI 37"
.pp
This value of the AFI defines the IDI to be an X.121 address or DTE
address.
The DTE address is encoded in binary coded decimal.
The DSP syntax is binary.
This form is intended to be used when communicating
across a public data network (PDN).
The ARGO software and documentation
refer to this type of NSAP-address as a
\*(lqtype 37.\*(rq
address.
.sh 3 "AFI 47"
.pp
The value of 47 for the AFI defines the IDI to be a 4 digit International
Code Designator (ICD) allocated according to ISO 6523.
ARGO support two
ICD values.
.sh 4 "ICD 0004"
.pp
The ICD value of 0004 is assigned to OSINET,
an experimental OSI network overseen by
National Institute of Science and Technology.\**
.(f
\** formerly the National Bureau of Standards
.)f
When this style of NSAP-address
is used,
the DSP is divided into four parts: an organization identifier (2 bytes),
a subnet identifier (2 bytes),
an SNPA-part (4-8 bytes), and
an NSAP selector (1 byte).
The use of these fields is defined by the OSINET steering committee.
This type of address is known as an
\*(lqOSINET\*(rq
address.
.sh 4 "ICD 0006"
.pp
The ICD value of 0006 is assigned to the Department of Defense (DoD).
In ARGO, NSAP-addresses with an ICD value of 0006
are of the format defined in RFC 986, a proposal for embedding DARPA Internet
addresses within an OSI NSAP-address.
In this case, the DSP takes the form:
version (1 byte), DARPA Internet Address (4 bytes), upper layer protocol
identifier (1 byte).
This is called an
\*(lqrfc986\*(rq
address.
.sh 1 "Internal Representation"
.pp
Internally, an NSAP address takes the form
.(b
\fC
.TS
tab(+);
l s s s s.
struct iso_addr {
.T&
l l l l l.
+u_char+isoa_afi;+/* authority &
+++format id */
+union+{+
++struct addr_37+addr_37;+/* x.121 */
++struct addr_osinet+addr_osinet;+/* OSINET */
++struct addr_rfc986+addr_rfc986;+/* Internet*/
+}+isoa_u;
+u_char+isoa_len;+/* length */
}
.TE
\fR
.)b
The field \fIisoa_afi\fR contains the AFI for the address.
The union
\fIisoa_u\fR contains the remainder of the address.
The length of the entire address (the AFI, IDI, and DSP) is
stored in \fIisoa_len\fR.
.sh 1 "Network Layer Routing"
.pp
Routing at the network layer is performed by the
routing procedure \fIrtalloc()\fR as described in Chapter 5.
\fIRtalloc()\fR was designed for used in the DoD Internet
domain.
An unfortunate
effect of this is that routing decisions are based upon either the
entire NSAP address or the network portion of the address.
The problem is defining the network portion of an NSAP address.
The location and extent of the
network portion of an NSAP address depends on the
style of NSAP address.
This decision is made by the function \fIiso_netof()\fR.
.sh 2 "Network Portion of Type 37 Addresses"
.pp
There is no network portion of an X.121 address.
In ARGO, the network portion of a type 37 address
is defined to be just the AFI.
The obvious consequence of this is that all type 37 addresses will
match all other type 37 addresses
in a network-portion comparison.
.sh 2 "Network Portion of OSINET Addresses"
.pp
The network portion of an OSINET address is the organization identifier and
the subnet identifier.
.sh 2 "Network Portion of RFC986 Addresses"
.pp
The network portion of an RFC986 address is the network portion of the
embedded DARPA Internet address.
ARGO does not support subnetting, a method of subdividing Internet addresses.
.sh 1 "NSAP Address / Subnetwork Point of Attachment Mapping"
.pp
In order to transmit a packet on a real subnetwork, the destination
NSAP address
must be mapped to an SNPA address.
An SNPA address is the real, "hardware" address
of a system on a network.
This address corresponds to the 6 byte Ethernet or Token Ring
Adapter address,
or to the DTE address, which may be up to 7 bytes
long (14 decimal digits).
.pp
A table, \fIsnpa_cache\fR is kept in the kernel which contains the
translation between NSAP-addresses and SNPA-addresses.
This table is used by \fIiso_snparesolve()\fR whenever a
datagram must be dispatched.
The table is maintained by the the ISO ES-IS protocol entity.
Entries can be added and deleted
by the user program \fIclnlutil(8)\fR and
by the CONS entity.

51
share/doc/iso/wisc/appendix_a.nr Normal file
View File

@ -0,0 +1,51 @@
.\" $Header: /cvsroot/src/share/doc/iso/wisc/Attic/appendix_a.nr,v 1.1.1.1 1994/06/19 00:07:17 cgd Exp $
.(x
Appendix A
.)x
.bp
.sz +2
.ce 3
Appendix A
\fBStandards Documents\fR
.sz -2
.lp
The following appendix lists many of the standards documents which were
consumed during development.
.ip "\fBNetwork Layer\fR"
.ip "ISO 8348" 15
Network Service Definition
.ip "ISO 8348/AD1" 15
Connectionless-mode Transmission
.ip "ISO 8348/AD2" 15
Network Layer Addressing
.ip "ISO 8648" 15
Internal Organization of the Network layer
.ip "ISO 8473" 15
Protocol for Providing the Connectionless Network Service
.ip "ISO 8473/DAD1" 15
Provision of the Underlying Service Assumed by ISO 8473
.ip "ISO 8473/DAD2" 15
Formal Description of ISO 8473
.ip "ISO 9542" 15
End System to Intermediate System Routing Exchange Protocol
for use in conjuction with the Protocol providing the Connectionless-mode
Network Service
.ip "ISO 8208" 15
X.25 packet level protocol for data terminal equipment
.ip "ISO 8878" 15
Use of X.25 to Provide the Connection-mode Network Service
.ip "\fBTransport Layer\fR"
.ip "ISO 8072" 15
Transport Service
.ip "ISO 8073" 15
Transport Protocol
.ip "ISO 8073/PDAD2" 15
Class 4 over Connectionless Network
.ip "\fBFunctional Standards Profiles\fI"
.ip "OSINET" 15
Implementation Agreements Among Participants of OSINET, December 1987
.ip "NBS" 15
Implementors's Agreements
.ip "GOSIP" 15
Government OSI Profile

10
share/doc/iso/wisc/appendix_b.nr Normal file
View File

@ -0,0 +1,10 @@
.\" $Header: /cvsroot/src/share/doc/iso/wisc/Attic/appendix_b.nr,v 1.1.1.1 1994/06/19 00:07:17 cgd Exp $
.(x
Appendix B
.)x
.bp
.sz +2
.ce 3
Appendix B
\fBManual Pages\fR

1043
share/doc/iso/wisc/debug.nr Normal file
View File

File diff suppressed because it is too large Load Diff

144
share/doc/iso/wisc/def.nr Normal file
View File

@ -0,0 +1,144 @@
.NC "Definitions"
.sh 1 "General Terms"
.ip "Kernel" 5
The source code or binary module for the Acis Operating System
(also know as AOS and IBM/4.3).
.ip "User process" 5
An instance of a program that is
running in unprivileged mode, in the unprivileged address space
commonly know as "user address space", in other words, not
part of the kernel.
.ip "IPC" 5
Interprocess communication, the mechanism by which two different
user processes send messages to each other.
.ip "Unix, AOS" 5
ACIS Operating System, the IBM ACIS port of Berkeley Unix 4.3BSD.
.ip "PCB, pcb" 5
Protocol control block. Each instance of a protocol machine
keeps status information, addresses, and in some cases queues
in a pcb for each connection or socket.
.ip "Domain" 5
In the Berkeley Unix environment, a domain is an abstract entity which
comprises a network architecture, addressing scheme, address format,
network protocols, and transport protocols.
.sh 1 "Transport Layer Terms"
.ip "ISO 8073"
ISO Draft International Standard 8073, Transport Protocol Specification
.ip "TP" 5
The collection of transport
classes that have been implemented in ARGO, classes 0 and 4.
Also means the ARGO implementation of TP.
.ip "TP 0" 5
Transport class 0.
.ip "TP 4" 5
Transport class 4.
.ip "Transport entity" 5
Software or hardware that implements the elements of procedure
described in ISO 8073.
.ip "Transport user" 5
User process that make use of the services
provided by a transport entity.
.ip "Transport service interface" 5
The syntax and semantics of the set of procedures, functions, and system calls
that are invoked by a transport user,
through which the services of the transport entity are delivered.
.ip "TPDU" 5
Transport protocol data unit, a packet that is
passed from one transport entity to another.
.ip "TSDU" 5
Transport service data unit, the logical unit of data that is
passed from a transport entity to a transport user, or from
a transport user to a transport entity.
.ip "CR TPDU" 5
Connection request TPDU.
.ip "CC TPDU" 5
Connection confirm TPDU.
.ip "DR TPDU" 5
Disconnect request TPDU.
.ip "DC TPDU" 5
Disconnect confirm TPDU.
.ip "DT TPDU" 5
Normal data TPDU.
.ip "XPD TPDU" 5
Expedited data TPDU.
.ip "AK TPDU" 5
Normal data acknowledgment TPDU.
.ip "XAK TPDU" 5
Expedited data acknowledgment TPDU.
.ip "ER TPDU" 5
Error TPDU.
.sh 1 "Network Layer Terms"
.ip "ISO 8473"
ISO Draft International Standard 8473, connectionless network protocol.
.ip "CONS"
Connection Oriented Network Service.
.ip "COSNS"
Connection Oriented Sub-Network Service.
.ip "CLNS"
Connectionless Network Service.
.ip "CLNP"
Connectionless Network Protocol, or ISO 8473.
.ip "Network Entity"
Software or hardware that implements the elements of procedure described
in ISO 8473.
.ip "Network Service User"
Software components that make use of the services provided by a network
entity.
.ip "Network Service Provider"
Software components that provide the services of a network entity.
.ip "NSAP"
Network Service Access Point. The point at which the OSI network service
is made available to the network service user by the network service
provider.
.ip "NSAP address"
Information that the network service provider needs to identify an
NSAP. The source and destination address fields of a CLNP packet
are NSAP addresses.
.ip "ES"
End system. A system running the complete suite of OSI protocols which can
act as an end point for communication.
.ip "IS"
Intermediate system. A system running the OSI layers 1, 2, and 3 which
can act only a packet router.
.ip "SNPA"
The Subnetwork Point of Attachement is the point where a \fIreal\fR
end or intermediate system is attached to a \fIreal\fR subnetwork.
.ip "SNPA address"
Information that a \fIreal\fR subnetwork need to identify a \fIreal\fR end
or intermediate system. This is commonly referred to as the hardware address.
.ip "NPDU"
Network Protocol Data Unit. The unit of data which is exchanged between
network entities.
.ip "DT NPDU"
Normal data NPDU.
.ip "ER NPDU"
Error report NPDU.
.ip "Initial NPDU"
A NPDU carrying the whole of the user data from an N-UNITDATA request.
.ip "Derived NPDU"
a NPDU whose field ar identical to those of an initial NPDU, except that it
carries only a segment of the user data from an N-UNITDATA request.
.ip "Segment"
A distinct unit of data consisting of part or all of the user data provided
in the N-UNITDATA request and delivered in the N-UNITDATA indication.
.ip "Segmentation"
The act of generation two or more derived NPDUs from an initial or derived
NPDU.
.ip "Fragment"
A DoD Internet Protocol term with the same meaning as "segment". Used
synonymously with "segment."
.ip "Fragmentation"
A DoD Internet Protocol term with the same meaning as "segmentation". Used
synonymously with "segmentation."
.ip "Reassembly"
The act of regenerating an initial NPDU from two ore more derived NPDUs.
.ip "MTU"
Maximum transmission unit. The maximum size of a packet that can be
transmitted on a medium or through a protocol.
For example, the MTU of the TP protocol is 8192 bytes, the MTU
of and Ethernet device is 1500 bytes, and the MTU of the OSI Network
service is 512 bytes.
.ip "Network interface"
The device used to attach a computer to a network, for example,
an Ethernet adapter, or a Token Ring adapter.
This unfortunate terminology is inherited from BSD Unix.

6
share/doc/iso/wisc/dogrn Executable file
View File

@ -0,0 +1,6 @@
#! /bin/csh -f
set dev=fa
foreach m ($argv)
echo grn -P$dev $m.grn ">" $m.nr
grn -P$dev $m.grn > $m.nr
end

729
share/doc/iso/wisc/eicon.nr Normal file
View File

@ -0,0 +1,729 @@
.sh 2 "X.25 Public Data Network Support"
.pp
This ARGO release includes support for an X.25 Public Data Network (PDN)
in the form of a device driver for the Eicon Technology
Network Adapter \**.
.(f
This adapter, its software, and its documentation are
available from Eicon Technology Corporation, 3452 Ashby Street, Montreal,
Quebec, Canada H4R 2C1.
.)f
The adapter and its software, together with
the ARGO \fIecn(4)\fR driver, implement
the X.25 packet layer protocol as required to support the OSI connection
oriented network service.
The remainder of this section of this manual
destribes the ARGO device driver (hereinafter called "the driver")
for the Eicon Technology Network Adapter (hereinafter called "the adapter"),
the interface between the driver
and the CONS software described above, and the interface
between the driver and the software on the adapter.
.sh 3 "Software Modules"
.lp
The modules relevant to the design of the driver are listed below.
.ip "\fICONS -\fR"
The Connection Oriented Network Service (CONS) provides the upper ISO layers
with an interface to the PDN.
In this release,
the PDN is 1980 X.25, although support for 1984 X.25 is included.
CONS can receive requests
from the CLNP entity and
from the OSI transport entity.
In addition, the CONS module
supports \fIioctl()\fR commands used by
\fIifconfig(8)\fR to configure
the X.25 network address and to
declare the adapter to be up or down.
See \fIcons(4p)\fR.
.ip "\fIDriver -\fR"
The driver accepts commands from CONS, formats these commands
for the adapter, and interprets error indications delivered by the adapter.
This driver supports all the UNIX configuration device structures.
See \fIecn(4)\fR.
.ip "\fIEcnconf -\fR"
\fIEcnconf\fR is a program that allows the privileged user to
reconfigure
the options offered by the software on the adapter.
\fIEcnconf\fR can be run at any time.
See \fIecnconf(8)\fR.
.ip "\fIEcnload -\fR"
\fIEcnload\fR is a program that downloads Eicon Technology software
to the adapter and passes the configuration changes made
with the \fIecnconf\fR program to the driver.
\fIEcnload must be run only when the X.25 link is considered down\fR.
See \fIecnload(8)\fR.
.ip "\fIEcnstat -\fR"
\fIEcnstat\fR is a program that
prints the connection state information and counters kept by
the adapter and by the driver.
The statistics include the number of sends and receives,
active connections, and errors.
For more information, see \fI ecnstat(8)\fR.
.ip "\fIAdapter -\fR"
The adapter's interface to the driver is the Network Control
Block and Request Vector that exist within the adapter's shared memory (often
called the "Common Data Area").
This is described in detail below.
.sh 3 "Interactions Among the Modules"
.lp
The commands
passed between CONS and the driver can be any one of the \fIECN\fR
commands outlined in the
sections "ECN Requests" and "ECN Replies", below.
CONS uses the \fCecnrestart()\fR procedure for restart requests,
\fCecnshutdown()\fR procedure for shutdown requests, and
\fCecnoutput()\fR procedure for all
normal data transfer requests.
CONS uses the \fCecnioctl()\fR procedure call for
servicing adapter status requests from the X.25 statistics program \fIecnstat\fR.
.lp
Commands passed between the driver and the adapter can
be any one of the network control block (\fINCB\fR)
commands described in the section "NCB Commands", below.
All commands to and from the adapter are
communicated in the Network Control Block and Request Vector within
the adapter's Common Data Area.
.lp
\fIEcnload\fR starts the
Eicon Technology Network Adapter software on the adapter
and downloads the validated configuration
to the driver.
.sh 3 "ECN Requests"
.lp
The \fIECN\fR request types that CONS can pass to the driver are listed below.
.ip "\fIECN_STOP - (by calling ecnshutdown())\fR"
This request instructs the driver to restart the network but not to listen for
any incoming calls.
CONS issues this request in response to an \fIioctl()\fR command
issued by the utility program \fIifconfig\fR, when
\fIifconfig\fR is used to bring down the adapter.
.ip "\fIECN_RESTART - (by calling ecnrestart())\fR"
This request instructs the driver to restart the network \fIand\fR to listen
and accept any incoming calls.
CONS issues this request in response to an \fIioctl()\fR command
issued by the utility program \fIifconfig\fR, when
\fIifconfig\fR is used to bring the adapter up.
.ip "\fIECN_CALL - 0x90\fR"
This request instructs the driver to place
a call request
to the specified DTE.
.ip "\fIECN_CLEAR - 0x92\fR"
This request instructs the driver to clear a given virtual circuit.
All outbound data are acknowledged by the remote DTE
before the circuit is cleared.
.ip "\fIECN_SEND - 0x94\fR"
This request instructs the driver to transmit a data buffer across a given
virtual circuit.
.ip "\fIECN_RESET - 0x04\fR"
This request instructs the driver to reset the given virtual circuit and
clear out all outstanding requests
associated with that virtual circuit.
.ip "\fIECN_STATUS - 0xb4 (exclusively through ecnioctl())\fR"
This requests instructs the driver to
solicit the adapter's current connection state information and
counters.
.sh 3 "ECN Replies"
.lp
The \fIECN\fR responses
the driver can give
to CONS are listed below.
.ip "\fIECN_CONNECT - 0x01\fR"
This reply notifies CONS that the driver has established a virtual circuit
connection initiated by the remote DTE.
.ip "\fIECN_ACCEPT - 0x03\fR"
This reply notifies CONS that an ECN_CALL request has succeeded. The
reply contains a pointer to a protocol control block.
.ip "\fIECN_REFUSE - 0x02\fR"
This reply notifies CONS that a previous \fIECN_CALL\fR request has failed.
The reply contains a pointer to a protocol control block.
.ip "\fIECN_CLEAR - 0x92\fR"
This reply notifies CONS that a given virtual circuit has been cleared
either by the DCE or by the remote DTE.
.ip "\fIECN_RECEIVE - 0x95\fR"
This reply notifies CONS that the driver has received a data packet from
the remote DTE.
.ip "\fIECN_RESET - 0x04\fR"
This reply notifies CONS that the virtual circuit has been reset either
by the DCE or by the remote DTE.
.ip "\fIECN_ACK - 0x05\fR"
This reply tells CONS that the associated ECN_SEND request has been been
completed by the adapter.
.sh 3 "NCB Commands"
.lp
The driver hides from the CONS module
many of the idiosyncrasies of the adapter's
software interface
by mapping many of the above \fIECN\fR requests into corresponding
\fINCB\fR commands. Below is a list of requests that the driver can place to
the adapter. For each request that the driver places to the adapter, the adapter
returns with a command completion.
.ip "\fINCB_CALL - 0x90\fR"
This command creates a virtual circuit.
.ip "\fINCB_LISTEN - 0x91\fR"
This command tells the adapter that our host is
willing to accept incoming calls.
.ip "\fINCB_CLEAR (and NCB_ABORT) - 0x92\fR"
This command clears a virtual circuit. An option exists to clear the circuit
immediately, without waiting first for outstanding acknowledgments.
.ip "\fINCB_SEND (and NCB_RESET) - 0x94\fR"
This command sends data to the remote DTE. An option is
available for resetting the
virtual circuit. This command can return a status indicating that the
circuit has been cleared by the DCE or the remote DTE.
.ip "\fINCB_RECEIVE - 0x95\fR"
This command tells the adapter that our host is
willing to receive data on a given virtual circuit. This command can return
received data, a reset circuit, M-, D-, and Q-bits, interrupt packets,
or a cleared circuit.
.ip "\fINCB_STATUS - 0xb4\fR"
This command queries the adapter about
the status of a virtual circuit.
The driver uses this command to support the ECN_STATUS request.
.ip "\fINCB_RESTART - 0xb2\fR"
This command restarts the network. This command requires that a corresponding
configuration file be passed down to the adapter.
.bp
.sh 3 "ECN Request and Reply Structure"
.lp
Below is
the data structure used in CONS-driver
communications.
This data structure is a parameter to the
\fIecnoutput()\fR procedure.
\fC
.nf
/* Eicon Driver Request Structure -- used between CONS and the driver */
struct eicon_request {
struct ecn_ncb eicon_req_ncb; /* the network control block */
caddr_t eicon_req_pcb; /* CONS pcb used on CALL requests */
int eicon_req_state; /* used internally by the driver */
int eicon_retry_cnt; /* used internally by the driver */
int eicon_more; /* used internally by the driver */
u_char eicon_reason; /* source of CLEAR requests */
};
\fR
.lp
The \fCeicon_req_ncb\fR field in the eicon request structure is of
type \fCecn_ncb\fR, defined in the following section. This structure stores
the command block
that the driver uses in communicating with the adapter.
The command block contains a \fIlogical session number\fR (LSN),
which identifies a virtual circuit.
Requests such as ECN_CALL are made without an LSN to identify
a circuit.
When an LSN is not available, the request is identified by
the field
\fCeicon_req_pcb\fR, which is a pointer to a CONS protocol control block.
The \fCeicon_req_state\fR field is used by the driver to keep track
of the status of the given request.
The following list defines the various values for this field:
.ip "\fIREQ_NEW\fR"
The driver recognizes a new request, has placed the request into the driver's
own request queue, but has yet to interrupt the
adapter. (The driver maintains a pointer \fCecn_pending_req\fR that indicates
whether an interrupt to the adapter is outstanding. If one is outstanding, the
driver places any new requests in this \fIREQ_NEW\fR state. If an interrupt
is not
outstanding, the driver places the request immediately in the
\fIREQ_INTERRUPT\fR state defined below.)
.ip "\fIREQ_INTERRUPT\fR"
The driver has dequeued the CONS request, assigned \fCecn_pending_req\fR to
point to the request, and
interrupted the adapter for a chance to post this request.
.ip "\fIREQ_POSTED\fR"
The driver has sent the request to the adapter.
.ip "\fIREQ_COMPLETE\fR"
The driver has just completed the request, and if necessary, is now posting
it to CONS.
.lp
The \fCeicon_retry_cnt\fR field in the eicon request structure keeps track
of how many times the driver has tried posting this command to the adapter.
After the second retry, the driver gives up and performs the appropriate
error routine.
The \fCeicon_more\fR field defines a \fIRECEIVE\fR request that
has been re-posted to the adapter to take care of m-bit transfers.
The \fCeicon_reason\fR field quantifies the reason for a connection being
cleared. These reasons are defined in the include file \fCiso_errno.h\fR.
.lp
Any data associated with the request are linked to the request through the
request mbuf's \fCm_next\fR field.
This is done so that when
the driver calls the \fIMFREE_M\fR deallocation routine, both the request
and the data are freed together.
.lp
The following chart defines those fields within the eicon request structure
that are relevant in any CONS request
to the driver via the \fIecnoutput()\fR call.
.sp
.sz 8
.TS
center,box,tab(:);
c s s s s
c||c s s s
c||c|c|c|c
l||l|l|l|l.
\fBField Definitions for CONS \(-> Driver Requests\fR
_
\fI:Request Types (CONS \(-> Driver)\fR
\fIField:ECN_CALL:ECN_CLEAR:ECN_SEND:ECN_RESET\fR
=
\fIncb\(->command\fR:0x90:0x92:0x94:0x04
_
\fIncb\(->loc_ses_num\fR:T{
.na
leave as zero
T}:VC #:VC #:VC #
_
\fIncb\(->info\fR:0x0:0x0:0x0:0x2
_
\fIeicon_req_pcb\fR:T{
.na
address of CONS' protocol control block
T}:NULL:NULL:NULL
_
\fIeicon_req_data\fR:T{
.na
address of mbuf containing contents of Call Request packet (including DTE address, facilities, and call user data)
T}:T{
.na
NULL or address of mbuf containing contents of Clear Request packet
T}:T{
.na
address of mbuf containing contents of user data
T}:T{
.na
NULL or the address of mbuf containing a one byte Reset Diagnostic code
T}
.TE
.sz 10
.sh 3 "Structure of the Network Control Block (NCB)"
.lp
The \fCecn_ncb\fR structure is used by the driver to
make requests of the adapter.
\fC
.nf
/* Network Control Block -- used between the driver and the Eicon adapter */
struct ecn_ncb {
u_char command; /* command field */
u_char retcode; /* return code field */
u_char lsn; /* local session number */
u_char info; /* additional information */
caddr_t buffer; /* pointer to data buffer's mbuf */
u_short length; /* buffer length */
u_char callname[16]; /* module name on NA "X25" */
u_char appl_name[16]; /* application name */
u_char rxto; /* receive timeout in secs */
u_char txto; /* send(tx) timeout in secs */
caddr_t post; /* NULL */
u_char lana_num; /* specifies Eicon Tech NA */
u_char cmd_cplt; /* command status */
u_char reserve[14]; /* reserved area */
};
\fR
.sp
.lp
The chart below defines those fields that are relevant in any
reply passed by the driver back up to CONS.
.sp
.sz 7
.TS
center,box,tab(:);
c s s s s s s
c||c s s s s s
c||c|c|c|c|c|c
l||l|l|l|l|l|l.
\fBField Definitions for Driver \(-> CONS Replies\fR
_
\fI:Reply Types (Driver \(-> CONS)\fR
\fIField:ECN_CONNECT:ECN_ACCEPT:ECN_REFUSE:ECN_CLEAR:ECN_RECEIVE:ECN_RESET\fR
=
\fIncb\(->command\fR:0x01:0x03:0x02:0x92:0x95:0x04
_
\fIncb\(->loc_ses_num\fR:VC #:VC #:ignore:VC #:VC #:VC #
_
\fIncb\(->info\fR:ignore:ignore:ignore:ignore:T{
.na
Interrupt received (bit 0), D-bit set (bit 6), and/or Q-bit set (bit 7). Zero
info field implies a normal receive.
T}:ignore
_
\fIeicon_req_pcb\fR:NULL:T{
.na
address of CONS's protocol control block
T}:T{
.na
address of CONS's protocol control block
T}:ignore:ignore:ignore
_
\fIeicon_req_data\fR:T{
.na
NULL or address of mbuf containing contents of Call Indication packet
T}:T{
.na
NULL or address of mbuf containing contents of Call Connected data
T}:T{
.na
NULL or address of mbuf containing contents of Call Cleared data
T}:T{
.na
NULL or address of mbuf containing contents of Call Cleared data
T}:T{
.na
address of mbuf containing contents of user data
T}:T{
.na
NULL or address of mbuf containing one byte Reset Diagnostic code
T}
_
\fIeicon_reason\fR:ignore:ignore:T{
.na
reason for refusal
T}:T{
.na
reason for clear
.T}:ignore:T{
.na
reason for reset
T}
.TE
.sz 10
.bp
.sh 3 "Internal Driver Data Sructures"
.lp
The main driver data structure
is the \fIecn_softc\fR structure.
This structure keeps track of the interface request queue
(\fCecn_if\fR and \fCecn_pending_req\fR),
magic addresses on the adapter (\fCecn_iom_base, ecn_mem_base,\fR and
\fCecn_data_base\fR),
error statistics (\fCecn_errors\fR), the state
of each virtual circuit (\fCecn_vc_state\fR), the state of the \fILISTEN\fR
request (\fCecn_listen_pending\fR), and the current caller (\fCecn_cause\fR).
\fC
.nf
struct ecn_softc {
int ecn_errors[NCB_MAX][ST_MAX];
int ecn_cause[CAUSE_MAX]; /* ecn_work() causes */
struct mbuf *ecn_pending_req; /* waiting for command req */
char ecn_listen_pending; /* boolean = listen req pending? */
char ecn_vc_state[LSN_MAX]; /* the current state of each vc */
struct ecn_device
*ecn_iom_base; /* base address of io map */
struct ecn_request_vector
*ecn_mem_base; /* base address of memory map */
caddr_t ecn_data_base; /* base address for data area */
struct ifnet ecn_if; /* queue of new requests */
}
\fR
.so figs/ecn_queue.nr
.sh 2 "Queueing in the Driver"
.lp
.CF
illustrates the queueing mechanism used by the driver.
.lp
CONS queues its data transfer requests at the end of the queue managed by
\fCecn_if\fR field in the \fCecn_softc\fR structure.
At this point, each request has the state value of
\fIREQ_NEW\fR.
Once the driver notifies the adapter that it has a command to post,
the driver dequeues the first request from the \fCecn_if\fR queue
and sets the pointer
\fCecn_pending_req\fR to point to the request.
At this point, the request is in the \fIREQ_INTERRUPT\fR state.
.lp
Once the driver posts the request to the adapter, it
dequeues the next request in the \fCecn_if\fR queue, reassigns the
\fCecn_pending_req\fR pointer, and then indicates to the adapter
that it is ready to post another request.
The driver no longer has to keep track of the previous request,
because for every reply, the adapter includes the associated
mbuf pointer.
While the request is outstanding, the request is in the \fIREQ_POSTED\fR state.
.so figs/ecn_vc.nr
.lp
After the adapter completes the command, the driver may want to reply to CONS.
It does this by placing its reply in CONS's \fCconsintrq\fR queue, defined as
an external \fCifqueue\fR in the driver code.
.sh 2 "Virtual Circuit States"
.lp
The \fCecn_vc_state\fR array in the \fCecn_softc\fR structure above keeps track
of the state of each virtual circuit (VC).
This is necessary to avoid handing
the adapter any commands that may not apply during a given state.
This mechanism
is especially useful in dealing with unexpected aborts or clears where there
is the potential for all outstanding commands to complete with errors.
By changing
states, the driver can prevent redundant commands (like clears and aborts)
from being passed either to the adapter or to CONS.
.lp
The driver only keeps track of four different states, as illustrated in
.CF
.
These states are:
.ip "\fIVC_NO_CONNECTION\fR"
When a virtual circuit is in this state, the virtual circuit does not exits.
Only \fICALL\fR and \fILISTEN\fR commands are valid.
.ip "\fIVC_DATA_XFER\fR"
All commands, except \fICALL\fR and \fILISTEN\fR commands are valid once the
connection exists.
.ip "\fIVC_RESET_IN_PROGRESS\fR"
In this state, either the driver has issued an \fINCB_RESET\fR or it has
received a reset error code on the completion of a command.
Only reissued \fIRESET\fR commands and \fIRECEIVE\fRs are
valid.
\fIRECEIVE\fR is valid in this state because the adapter uses the
completion of this command to hand back the cause of the reset (the RESET
INDICATION packet).
.ip "\fIVC_CLEAR_IN_PROGRESS\fR"
The driver has either issued an \fINCB_CLEAR\fR command or has just
received a clear error code on the completion of a command.
Within this state, only reissued
\fICLEAR\fR and \fIABORT\fR commands are valid.
.sh 2 "Error Statistics"
.lp
With the \fCecn_errors\fR field in the \fCecn_softc\fR structure,
the driver maintains a two dimensional array of counters
if the frequencies of errors.
In order to inspect this array easily with
the kernel debugger, the first index to every command ( <command, 0> ) is
reserved for a four character ASCII command identifier.
.bp
.sh 3 "The Driver State Machine"
.sh 2 "Handling of Normal Command Completions"
.lp
The chart below lists
all the available adapter request types, at what level each of
these requests can be used, options, and the driver's action after a normal
completion of the command.
.sp
.sz 7
.TS
center,box,tab(:);
c s s s
c|c s|c
c|c|c|c
l|l|l|l.
\fBNormal Completion Handling\fR
_
\fINCB:Options:Action Based on Normal Competion of\fR
\fICommand:To Adapter:From Adapter:Driver\(->Adapter Command\fR
=
\fINCB_RESTART\fR:none:none:T{
.na
dequeue the request, and issue an NCB_LISTEN request to the adapter.
T}
_
\fINCB_CALL\fR:none:connected:T{
.na
dequeue the request, pass an ECN_ACCEPT reply to CONS, and issue a RECEIVE to
the adapter.
T}
_
\fINCB_LISTEN\fR:T{
.na
use zero-length Call User Data and a zero-length Calling DTE address
T}:none:T{
.na
dequeue the request, pass an ECN_CONNECT to CONS, and issue a RECEIVE to the
adapter. Re-issue another NCB_LISTEN
for another possible virtual circuit connection.
T}
_
\fINCB_CLEAR\fR:T{
.na
normal clearing with all outstanding ACKs returned
T}:none:T{
.na
dequeue the request.
T}
:_:_:_
:T{
.na
immediate clearing
T}:none:T{
.na
dequeue the request.
T}
_
\fINCB_SEND\fR:T{
.na
normal send
T}:none:T{
.na
dequeue the request and reply to CONS with an ECN_ACK.
T}
:_:_:_
:T{
.na
reset the virtual circuit
T}:none:T{
dequeue the request.
T}
_
\fINCB_RECEIVE\fR:none:T{
.na
normal, uncomplicated receive
T}:T{
.na
dequeue the request and bcopy the data into the request's associated mbuf. Ship to CONS. Re-issue another NCB_RECEIVE.
T}
:_:_:_
:none:T{
.na
m-bit set
T}:T{
.na
same as above (adapter does the resegmentation automatically).
T}
:_:_:_
:none:T{
.na
d-bit set
T}:T{
.na
same as above.
T}
:_:_:_
:none:T{
.na
q-bit set
T}:T{
.na
same as above.
T}
:_:_:_
:none:T{
.na
interrupt received
T}:T{
.na
same as above.
T}
:_:_:_
:none:T{
.na
reset received
T}:T{
dequeue the request, send an ECN_RESET back up to CONS, and issue another
receive.
T}
.TE
.sz 10
.sp
.uh "CONS \(-> Driver"
.lp
All entries in this column indicate that the CONS module can send this request
down to the driver. Command names in parenthesis define the mapping between
the \fIECN\fR and \fINCB\fR commands.
.uh "Driver \(-> Adapter"
.lp
All checks in this column indicate that the driver can send this request
to the adapter. The last column in the above table defines what the driver must
do upon normal completion of the command from the adapter.
Note that not all driver-to-adapter
commands have a CONS-to-driver equivalent.
This shows that this
command request is generated within the driver, rather than originating from
the CONS driver.
.uh "Driver \(-> CONS"
.lp
All entries in this column indicate that the driver can send this reply
back to CONS. Command names in parenthesis define the mapping between
the \fIECN\fR and \fINCB\fR commands.
.bp
.sh 3 "Handling of Errors upon Command Completion"
.lp
Below is listed all the driver request and pseudo request types, along with the
actions the driver must perform given a command completion error delivered by
the Eicon Network Adapter.
.sp
.sz 7
.TS
center,box,tab(:);
c s s s s s s s
c||c s s s s s s
c||c|c|c|c|c|c|c
c||c|c|c|c|c|c|c
l||l|l|l|l|l|l|l.
\fBError Completion Handling\fR
_
:\fIAction Based on Error Completion of Driver \(-> Adapter Command\fR
\fIError Returned\fR:_:_:_:_:_:_:_
\fI:NCB_CALL:NCB_LISTEN:NCB_CLEAR:NCB_ABORT:NCB_RESET:NCB_SEND:NCB_RECEIVE\fR
=
\fIST_BAD_LEN\fR:<soft-error>:<soft-error>:<soft-error>:<soft-error>:<soft-error>:<soft-error>:<soft-error>
_
\fIST_INVALID\fR:<soft-error>:<soft-error>:<dequeue>:<dequeue>:<dequeue>:<dequeue>:<dequeue>
_
\fIST_COMMAND_TO\fR:<retry>:<retry>:<retry>:<retry>:<abort>:<abort>:<retry>
_
\fIST_ISSUE_ANOTHER_RCV\fR:<refuse>:<retry>:<retry>:<retry>:<abort>:<abort>:T{
.na
requeue request and increment "more" count
T}
_
\fIST_BAD_LSN\fR:<soft-error>:<soft-error>:<dequeue>:<dequeue>:<dequeue>:<dequeue>:<dequeue>
_
\fIST_NO_RESOURCES\fR:<retry>:<retry>:<retry>:<retry>:<abort>:<abort>:<retry>
_
\fIST_CALL_CLEARED\fR:<refuse>:<retry>:<retry>:<retry>:<clear>:<clear>:<clear>
_
\fIST_COMMAND_CANCELLED\fR:<refuse>:<retry>:<retry>:<retry>:<abort>:<abort>:<abort>:
_
\fIST_NO_CIRCUITS\fR:<refuse>:<retry>:<retry>:<retry>:<abort>:<abort>:<abort>
_
\fIST_CALL_UNSUCCESSFUL\fR:<refuse>:<retry>:<retry>:<retry>:<abort>:<abort>:<abort>
_
\fIST_INCORRECT_CALLNAME\fR:<soft-error>:<soft-error>:<soft-error>:<soft-error>:<soft-error>:<soft-error>:<soft-error>
_
\fIST_X25_RESET\fR:<refuse>:<retry>:<retry>:<retry>:<dequeue>:<dequeue>:<retry>
_
\fIST_TOO_MANY_COMMANDS\fR:<retry>:<retry>:<retry>:<retry>:<abort>:<abort>:<retry>
_
\fIST_L1_NO_DATA_SET_READY\fR:<refuse>:<retry>:<retry>:<retry>:<abort>:<abort>:<abort>
_
\fIST_L1_NO_CLEAR_TO_SEND\fR:<refuse>:<retry>:<retry>:<retry>:<abort>:<abort>:<abort>
_
\fIST_L1_NO_CLOCK\fR:<refuse>:<retry>:<retry>:<retry>:<abort>:<abort>:<abort>
.TE
.sz 10
.sp
.lp
Each of the actions from the above chart are defined as follows.
.ip "\fI<abort>\fR -"
The driver should clear the connection by issuing an \fINCB_ABORT\fR
to the adapter and sending an \fIECN_CLEAR\fR to CONS.
.ip "\fI<refuse>\fR -"
The driver should send an \fIECN_REFUSE\fR back to CONS.
.ip "\fI<dequeue>\fR -"
The driver should simply dequeue the request. Usually these errors occur when a
reset or clear occurs on the adapter while the driver is in the midst of
issuing the command which subsequently completes with an error status.
.ip "\fI<clear>\fR -"
The driver should send an \fIECN_CLEAR\fR back up to CONS.
.ip "\fI<retry>\fR -"
The driver should requeue the request if and only if the
\fCecn_retry_cnt\fR field in the request structure does not exceed the
retry maximum.
.ip "\fI<soft-error>\fR -"
This action only takes place when a software error has occurred. The driver
should
print the error to the console in big bold letters and then panic.
.bp
.sh 3 "The IFP Flags"
.lp
The IFP flags in the standard \fCifnet\fR structure
should be used in the following way.
.ip "\fIIFF_UP on -\fR"
This flag is set by the driver only after the procedure \fIecnrestart()\fR
successfully completes.
.ip "\fIIFF_UP off -\fR"
This flag is set immediately upon entry into the procedure \fIecnshutdown()\fR.
.ip "\fIIFF_RUNNING on -\fR"
This flag is set on whenever the \fIecnwork()\fR procedure is active, eg. the
driver is actually doing something.
.ip "\fIIFF_RUNNING off -\fR"
This flag is turned off upon exit from the \fIecnwork()\fR procedure.

126
share/doc/iso/wisc/eicon.table5.1.orig.nr Normal file
View File

@ -0,0 +1,126 @@
.TS
center,box,tab(:);
c s s s s s s
c|c s s|c s|c
c|c|c|c|c|c|c
l|c|c|c|l|l|l.
\fBNormal Completion Handling\fR
_
\fINCB:Usage:Options:Action Based on Normal Competion of\fR
\fICommand:CONS\(->Driver:Driver\(->Board:Driver\(->CONS:To Board:From Board:Driver\(->Board Command\fR
=
\fINCB_RESTART\fR:T{
.na
(ECN_RESTART)
T}:\(sr::none:none:T{
.na
dequeue the request, and issue an NCB_LISTEN request to the board.
T}
_
\fINCB_CALL\fR:(ECN_CALL):\(sr:T{
.na
(ECN_ACCEPT)
T}:none:connected:T{
.na
dequeue the request, pass an ECN_ACCEPT reply to CONS, and issue a RECEIVE to
the board.
T}
_
\fINCB_LISTEN\fR::\(sr:T{
.na
(ECN_CONNECT)
T}:T{
.na
use zero-length Call User Data and a zero-length Calling DTE address
T}:none:T{
.na
dequeue the request, pass an ECN_CONNECT to CONS, and issue a RECEIVE to the
board. Re-issue another NCB_LISTEN
for another possible virtual circuit connection.
T}
_
\fINCB_CLEAR\fR:(ECN_CLEAR):\(sr:(ECN_CLEAR):T{
.na
normal clearing with all outstanding ACKs returned
T}:none:T{
.na
dequeue the request.
T}
:_:_:_:_:_:_
::\(sr::T{
.na
immediate clearing
T}:none:T{
.na
dequeue the request.
T}
_
\fINCB_SEND\fR:(ECN_SEND):\(sr::T{
.na
normal send
T}:none:T{
.na
dequeue the request and reply to CONS with an ECN_ACK.
T}
:_:_:_:_:_:_
:T{
.na
(ECN_RESET)
T}:\(sr::T{
.na
reset the virtual circuit
T}:none:T{
dequeue the request.
T}
_
\fINCB_RECEIVE\fR::\(sr:(ECN_RECEIVE):none:T{
.na
normal, uncomplicated receive
T}:T{
.na
dequeue the request and bcopy the data into the request's associated mbuf. Ship to CONS. Re-issue another NCB_RECEIVE.
T}
:_:_:_:_:_:_
:::(ECN_RECEIVE):none:T{
.na
m-bit set
T}:T{
.na
same as above (board does the resegmentation automatically).
T}
:_:_:_:_:_:_
:::(ECN_RECEIVE):none:T{
.na
d-bit set
T}:T{
.na
same as above.
T}
:_:_:_:_:_:_
:::(ECN_RECEIVE):none:T{
.na
q-bit set
T}:T{
.na
same as above.
T}
:_:_:_:_:_:_
:::(ECN_RECEIVE):none:T{
.na
interrupt received
T}:T{
.na
same as above.
T}
:_:_:_:_:_:_
:::T{
.na
(ECN_RESET)
T}:none:T{
.na
reset received
T}:T{
dequeue the request, send an ECN_RESET back up to CONS, and issue another
receive.
T}
.TE

363
share/doc/iso/wisc/errors.nr Normal file
View File

@ -0,0 +1,363 @@
.\"$Header: /cvsroot/src/share/doc/iso/wisc/Attic/errors.nr,v 1.1.1.1 1994/06/19 00:07:17 cgd Exp $
.\"$Source: /cvsroot/src/share/doc/iso/wisc/Attic/errors.nr,v $
.NC "Error Handling"
This section describes the various ways that the ARGO kernel
handles errors.
For the purpose of this description,
errors are divided into
three classes : user errors, remote-end errors, and internal errors.
These three classes of errors and the way
the ARGO kernel handles them are described below.
.sh 1 "Network Layer Errors"
.pp
The following section describes how errors are handled by CLNP.
.sh 2 "User Errors"
.pp
User errors occur when attempting to send a CLNP packet. These errors
are reflected back to the caller of \fIclnp_output()\fR as the return value
of the function. The following table indicates the types of errors possible
and their associated return codes:
.(b L
.TS
tab(+), expand box;
l l.
Problem+Return Code
=
Unsupported option selected+EINVAL
Incorrect address+ENAMETOOLONG
Insufficient \fImbufs\fR+ENOBUFS
Can't route packet+ENETUNREACH,EHOSTUNREACH
Insufficient \fImbufs\fR+ENOBUFS
.TE
.)b
.sh 2 "Remote-end Errors"
.pp
An error that occurs as the result of incoming NPDU
is a remote-end error.
.pp
In the case of CONS,
the majority of these are addressing problems,
PDN-generated errors (network or gateway congestion, number busy),
or higher layer negotiation problems.
All ISO 8208 diagnostic codes that may appear in a call clearing packet
are passed up to the higher layer.
Some of the higher layer protocols pass this error indication to the
user level program as well.
The CONS statistics that are maintained by the "glue" module
include counters for each of the possible
ISO 8208 diagnostic codes seen on incoming packets.
In addition to these error codes, there are some codes that may appear
due to device driver problems when an NPDU arrives, for example,
the driver may run out of buffers.
All possible errors that may occur in the CONS module are listed
in the file
\fC<netargo/iso_errno.h>\fR,
and the values listed in this file are passed to the user level
program in the global integer variable \fIerrno\fR.
The ARGO library
\fClibisodir.a\fR
includes an expanded version of
\fIperror()\fR that interprets these extra values.
.pp
In the case of CLNP,
the most remote-end errors are parsing errors.
When a remote-end error is discovered, processing of the NPDU stops. The
NPDU is discarded, and if error reporting is not disabled, and ER NPDU
is sent back to the source of the offending packet. The following
tables show the errors that may occur, and the error reason
that will specified when the ER NPDU is returned.
.pp
The following general errors may occur while parsing an NPDU:
.(b L
.TS
tab(+), box, expand;
l l.
Problem+Error Reason
=
NPDU arrives before interface is configured+ADDR_DESTUNREACH
Packet too short or too big+GEN_INCOMPLETE
Protocol identification wrong+GEN_HDRSYNTAX
Version wrong+DISC_UNSUPPVERS
Lifetime expired+TTL_EXPTRANSIT
Incorrect checksum+GEN_BADCSUM
Address section too short+GEN_INCOMPLETE
Segment section too short+GEN_INCOMPLETE
Options section too short+GEN_INCOMPLETE
Unknown packet type+GEN_HDRSYNTAX
Can't route packet (forwarding)+ADDR_DESTUNREACH
.TE
.)b
The following errors are related to options processing:
.(b L
.TS
tab(+), box, expand;
l l.
Problem+Error Reason
=
Duplicate option+GEN_DUPOPT
Unknown option+DISC_UNSUPPTOPT
Security format bad+GEN_HDRSYNTAX
Security option present+DISC_UNSUPPSECURE
Source route format bad+SRCRT_SYNTAX
Record route too short+GEN_INCOMPLETE
Record route format bad+GEN_HDRSYNTAX
QOS format bad+GEN_HDRSYNTAX
Priority format bad+GEN_HDRSYNTAX
Error reason format bad+GEN_HDRSYNTAX
Error reason on non-ER NPDU+DISC_UNSUPPOPT
Error reason absent from ER NPDU+GEN_HDRSYNTAX
.TE
.)b
.sh 2 "Internal Errors"
.pp
Internal errors occur as a result of a programmer error. These errors
will result in a kernel \fIpanic()\fR. The following panics have been
coded into CLNP:
.(b L
.TS
tab(+), box, expand;
l l.
\fIPanic()\fR message+Reason
=
clnp_init: no raw clnp+The raw clnp protocol is not
+configured into the kernel.
_
clnp_srcaddr: ifp does not match interface+The ifp
+passed to \fIclnp_srcaddr()\fR is invalid.
.TE
.)b
.sh 1 "Transport Layer Errors"
.pp
.sh 2 "User Errors"
.pp
TP handles these errors in the "standard"
way for 4.3BSD:
it causes an E\fIxxx\fR error constant (from the
list in /sys/h/errno.h)
to be put into the user program's
global variable \fIerrno\fR.
In most routines, in particular
those routines called directly or indirectly
the by system-call routines,
this is done
by simply returning
this integer value.
The errors that fall into this category are described
in the following table:
.(b L
.TS
expand box tab(+);
l l.
Error+Meaning
=
EAFNOSUPPORT+Attempting to use an address family
+other than AF_ISO and AF_INET.
_
ENOPROTOOPT+TP was not configured at boot time.
_
ESOCKTNOSUPPORT+The given socket type is not supported.
_
EPROTOTYPE+Attempting to use an inappropriate transport
+class for the network service. (e.g. class 0 over CLNS)
+or attempting to use an unknown network service.
_
EISCONN+Attempting to perform on a connected socket an action
+that is permitted only on unconnected sockets.
_
ENOTCONN+Attempting to perform on an unconnected socket an
+action that is permitted only on connected sockets.
_
EMSGSIZE+Trying to send more data than are permitted on
+connect, disconnect, or expedited data PDUs.
_
ENOTSOCK+The integer argument passed in the system
+call is not a socket descriptor or is a socket but
+has no transport pcb.
_
EINVAL+Some argument to the system call is invalid.
_
EOPNOTSUPP+Some command argument to the system call is invalid
+or the operation is not supported.
_
EACCES+An unprivileged user tried to use a privileged command.
_
ETOOMANYREFS+TP ran out of reference blocks.
_
ENOBUFS+TP ran out of memory (mbufs).
.TE
.)b
Errors that should be reported to the user
by \fIerrno\fR but which occur asynchronously
are detected by the socket layer when the value
of the field \fIso_error\fR in the socket
structure is non-zero.
This is used to report such errors as
ECONNRESET,
ECONNABORTED, and
ECONNTIMEDOUT, which are really remote-end errors.
.sh 2 "Remote-end Errors"
.pp
An error that occurs is the result of a timer
or is a result of an
incoming TPDU
is a remote-end error.
The majority of these errors are parsing errors.
They also include some protocol errors.
Some of these errors cause the connection to be
closed locally.
It is unfortunate that when a connection is closed,
the kernel will not permit the user program to perform
anything on the socket in question, so the user cannot
inquire about the reason for disconnection.
There is no clean way to pass this information to a
signal handler either, since the process being signalled
may be swapped out at the time.
Some of these errors cause TP to return an ER TPDU
or a DR TPDU to the sending site.
Some have no effect on the connection locally.
These errors and their effects are described below.
.(b L
.TS
expand box tab(+);
l l l.
Error+Meaning+Return code or action taken
=
Retransmission+The remote end has not responded +ETIMEDOUT
timeout+to repeated attempts to send.+
+This can occur during connection+
+or after connection establishment.+
_
Inactivity+The remote end has not sent anything +ETIMEDOUT
timeout+within the last \fIx\fR time, where+
+\fIx\fR is a locally defined+
+large value.+
_
Unacceptable+An unacceptable TPDU has arrived, and the+TPDU dropped
TPDU +remote end can be identified.+possibly DR/ER returned
_
DR TPDU+A DR TPDU arrived, with any+Disconnect indication,
arrived+value in the reason field.+so_error == ECONNRESET
_
ER TPDU+An ER TPDU arrived, with any+Disconnect indication,
arrived+anything in the reason field.+so_error == ECONNABORTED
.TE
.)b
TPDUs may be unacceptable for a variety of reasons:
.(b L
.TS
expand box tab(+);
l l.
Problem+Action taken by TP
=
No connection at destination+Respond with DR, reason: session entity
reference or reference frozen+not attached to TSAP
_
Invalid destination reference+Respond with DR, reason: mismatched
+references
_
Invalid parameter code+Respond with ER, cause: inval. param. code
_
Invalid DU type+Respond with ER, cause: invalid TPDU type
_
Invalid version number+ Respond with ER, cause: inval. param. code
_
Invalid suffix value+Respond with ER, cause: inval. param. value
_
Suffix missing or is of+Respond with DR, reason:
invalid length+header or parameter length invalid
_
Invalid checksum+packet discarded
_
Can't find a connection+Respond with DR, reason:
for (dest ref, src ref) pair+mismatched references
_
Old ACK TPDU+packet discarded, possibly send ACK w/ FCC
_
Class requested isn't supported+Respond with DR, reason: +negotiation failed
_
Invalid TPDU size parameter+Respond with ER, cause: inval. param. value
_
Illegal amount of data+Respond with DR, reason:
on CR, CC, DR, or XPD+header or parameter length invalid
_
Header length and length+Respond with DR, reason:
indicator field of TPDU don't agree+header or parameter length invalid
.TE
.)b
.lp
The file \fC<argo/iso_errno.h>\fR is a list
of the error codes and diagnostic that can be returned
from the peer transport entity in a DR TPDU or an ER TPDU,
and those that can be returned from the CONS, initiated by the DCE,
the remote DTE, or by the local network adapter.
These error values are too numerous to list here.
Most of them are taken from the ISO 8208 standard and the ISO 8073 standard.
The ARGO distribution contains an expanded form of the BSD library
routine \fIperror()\fR that prints an error messages for a given
\fIerrno\fR value.
.sh 2 "Internal Errors"
.pp
Some internal errors are the result of
a lack of resources such as buffers.
These are reported to the user with the
global variable
\fIerrno\fR
set to a value from
\fC<errno.h>\fR.
The errors that fall into this category are described
in the following table:
.(b L
.TS
expand box tab(+);
l l.
Return code+Problem
=
ENOBUFS+TP ran out of mbufs.
_
EPROTONOOPT+TP hasn't been configured.
_
ETOOMANYREFS+TP ran out of (unfrozen) reference numbers.
.TE
.)b
.pp
Other
internal errors are coding errors
or errors of misinterpretation of a specification.
They result in the printing of a message on the
console followed by a system panic.
The following panics have been coded into TP:
.(b L
.TS
expand box tab(+);
l l.
\fIPanic()\fR message+Problem
=
tp_emit CR/CC+The length indicator field of a TPDU is longer than the
+amount of space in an mbuf; TP is attempting to send a
+CR TPDU that is too large (perhaps legal but too large for
+this implementation to manage).
_
tp_rcvoob: unexpected cluster+An incoming XPD TPDU was put into a cluster
+mbuf by a lower layer.
_
tp timeout table overflow+The system ran out of structures for TP timers.
_
tp: T_DETACH+The connected socket that is being detached has
+no parent socket.
_
tp_soisdisconnected+The socket head queue is
+corrupted.
_
tp_soisdisconnecting+The socket head queue is
+corrupted.
_
tpclnp_input: bad clnp_len +The length parameter passed by clnp
+is bad.
_
iso_control: SIOCDIFADDR+ioctl() system call passed down
iso_control: SIOCSIFADDR+a null interface pointer
_
sofree dq+The list of socket structures is
+is inconsistent.
.TE
.)b

114
share/doc/iso/wisc/esis_design.nr Normal file
View File

@ -0,0 +1,114 @@
.NC "The Design of the ARGO Network Layer"
.sh 1 "End System to Intermediate System Routing Protocol"
.pp
The following sections describe the design of the End System to Intermediate
System (ES-IS) Routing Exchange Protocol.
.sh 2 "Overview"
.nf
- protocol involves sending/receiving hello pdus.
- timers determine
- when to send information
- when to discard information
- want to keep as much of the work outside of kernel
- only put functions and tables in kernel when necessary
.sh 2 "Supported Features (brief overview of each)"
- report configuration (both ES and IS)
- record configuration (both ES and IS)
- flush configuration (both ES and IS)
- query configuration (ES only)
- configuration response (ES only)
- request redirect (IS only)
- record redirect (ES only)
- flush old redirect (ES only)
- multicast vs. broadcast (using broadcast only)
.sh 2 "Kernel Resident Features"
.sh 3 "Support for PDU Transmission"
- need mechanism to send/receive PDUs
- utilize ES-IS socket (like raw socket)
- socket(AF_ISO, SOCK_DGRAM, ISOPROTO_ESIS)
.sh 4 "Sending PDUs"
- sendmsg() used for transmitting PDUS
- data will be pre-formed ES-IS PDU
- no checks will be made on the pdu format
- addr_snpa is the destination (to)
- before sending, socket must be associated with a particular interface
this is done via setsockopt():
ESISOPT_SETIF - option
buffer is name of interface, ie. "un0"
.sh 4 "Receiving PDUs"
- recvmsg() used for receiving PDUs
- data will be:
#define ESIS_PDU
#define ESIS_CONFIG_RESP
#define ESIS_REDIR_REQ
struct esis_indication {
short ei_type; /* type of indication */
union {
struct ? config_resp
struct ? redir_req
char pdu[0]
} ei_u;
}
- no checks will be made on the pdu format
- addr_snpa is the source (from)
.sh 4 "Addressing"
- ES-IS PDUs are sent to SNPA.
- addresses used are SN addresses, not NSAP addresses
- format of msg_name (part of msghdr) struct sockaddr_iso
afi = 0 /* means special snpa address */
isoa_u is struct addr_snpa
struct addr_snpa {
char sn_addr[7]; /* snpa addr */
}
isoa_len is number of bytes of sn_addr that are valid
- sn_addr may be a unicast or multicast address
- multicast addresses will be faked via broadcast addresses
.sh 3 "NSAP to SNPA translation"
- translation from NSAP to SNAP required for every CLNP PDU sent
- function provided by iso_nsap_to_snpa
iso_nsap_to_snpa(ifp, m, nsap, snpa)
struct ifnet *ifp; /* outgoing interface */
struct mbuf *m; /* pkt */
struct sockaddr_iso *nsap; /* destination address */
char *snpa; /* RESULT: snpa address */
{
if (nsap.afi == AFI_SNPAADDR) {
copy snpa addr from nsap into snpa
return SUCCESS
} else {
scan RIB for (RIB.nsap == nsap)
if (found) {
copy RIB.snpa into snpa
return SUCCESS
}
scan RIB for (RIB.type == IS) && (RIB.ifp = ifp)
if (found) {
copy RIB.snpa into snpa
return SUCCESS
}
if (ifp allows multicast) {
/* invoke query configuration function */
copy ifp.ifaddr.ifa_all_es into snpa
return SUCCESS
}
return FAILURE
}
}
- NSAP to SNPA table resides in kernel so CLNP has quick access
- entries added/timed-out of table via user level ES-IS daemon
.sh 3 "Query Configuration Functon"
- invoked when iso_nsap_to_snpa
- requires snpa, but
- does not find a match for dest nsap, and
- does not find a match for Any IS.
- clnp packet is sent to address "all ES" as specified in ifnet structure
(for now, this is just the broadcast address)
.sh 3 "Configuration Response Function"
- invoked by clnp_input(), after determining that the packet received is
destined for one of its NSAPs
- checks if sn_dst == "all ES" (for now, this is all hex ffs)
- if true, a copy of packet is made, and passed up to esis_input()

77
share/doc/iso/wisc/figs/CONS_primitives.nr Normal file
View File

@ -0,0 +1,77 @@
.(b
.TS
tab(+) center expand box;
c c
a | a .
service primitive & arguments+provided by
=
N_CONNECT.request+cons_openvc(... faddr, ...)
called address+argument faddr
calling address+not implemented
receipt confirmation+not implemented
expedited data+not implemented
quality of service+not implemented
NS-user data+not implemented
_
N_CONNECT.indication+not implemented
_
N_CONNECT.response+cons_netcmd( CONN_REFUSE )
+ or cons_netcmd( CONN_CONFIRM )
+ however, net connection has already
+ been accepted. If REFUSE, it will
+ be cleared with E_CO_HLI_REJT
+ (higher layer rejects connection)
responding address+not implemented
receipt confirmation+not implemented
expedited data+not implemented
quality of service+not implemented
NS-user data+not implemented
_
N_CONNECT.confirm+not implemented
=
N_DATA.request+cons_output(... m, ...)
+and cosns_output(... m, ...)
confirmation+not implemented
data+mbuf chain m
_
N_DATA.indication+pr_input( m, ... )
+or software interrupt
confirmation+not implemented
data+mbuf chain
_
N_DATA_ACKNOWLEDGE.request+not implemented
_
N_DATA_ACKNOWLEDGE.indication+not implemented
_
N_EXPEDITED_DATA.request+not implemented
_
N_EXPEDITED_DATA.indication+not implemented
=
N_RESET.request+not implemented
N_RESET.indication+socket->so_error = reason
+or pr_ctlinput( PRC_ROUTEDEAD )
originator+not implemented
reason+from X.25 packet or ecn driver
N_RESET.response+not implemented
N_RESET.confirm+not implemented
=
N_DISCONNECT.request+cons_netcmd( CONN_CLOSE )
reason+uses E_CO_HLI_DISCN (normal
+disconnect from higher layer)
responding address+not implemented
NS_user data+not implemented
_
N_DISCONNECT.indication+socket->so_error = reason
+or pr_ctlinput( PRC_ROUTEDEAD )
originator+not implemented
reason+from X.25 packet or ecn driver
responding address+not implemented
NS_user data+not implemented
.TE
.(c
\fBFigure \n+(FG\fR: Transport Service Primitives
.)c
.)b
.(f
\** data on disconnect is not supported at this time.
.)f

18
share/doc/iso/wisc/figs/Makefile Normal file
View File

@ -0,0 +1,18 @@
#
#
.SUFFIXES: .nr .grn
PRINTER = ba
ALL = \
func_units.nr unix_ipc.nr osi_addr.nr trans_flow.nr clnp_output.nr\
clnp_input.nr mbufsnd.nr mbufrcv.nr\
ecn_vc.nr ecn_network.nr ecn_queue.nr tppt.nr
all: $(ALL)
clean:
rm $(ALL)
.grn.nr:
grn -P$(PRINTER) $*.grn > $*.nr

69
share/doc/iso/wisc/figs/NS_primitives.nr Normal file
View File

@ -0,0 +1,69 @@
.(b
.TS
tab(+) center box;
c c
a | a .
service primitive & arguments+kernel procedure call & arguments
=
N_CONNECT.request+\fIcons_openvc(copcb,dstaddr,so)\fR
called address+argument \fIdstaddr\fR
calling address, expedited data selection+not implemented
receipt confirmation selection+not implemented
quality of service, NS-user data+not implemented
_
N_CONNECT.indication+not implemented
_
N_CONNECT.response+not implemented
_
N_CONNECT.confirm+return from \fIcons_openvc()\fR
responding address, quality of service+not implemented
receipt confirmation selection+not implemented
expedited data selection, NS-user data+not implemented
=
N_DATA.request+\fIcons_output(isop,m,len,isdgm)\fR, and
+\fIcosns_output(ifp,m,dstaddr)\fR
NS-user data+argument m (mbuf chain)
confirmation request+not implemented
_
N_DATA.indication+software interrupt (CLNP), procedure
+call to \fItp_input()\fR
NS-user data+mbuf chain on \fIclnlintrq\fR or
+argument to \fItp_input()\fR
confirmation request+not implemented
=
N_DATA_ACKNOWLEDGE.request+not implemented
_
N_DATA_ACKNOWLEDGE.indication+not implemented
=
N_EXPEDITED_DATA.request+not implemented
_
N_EXPEDITED_DATA.indication+not implemented
=
N_RESET.request+not implemented
_
N_RESET.response+not implemented
_
N_RESET.indication+higher layer \fIpr_ctlinput(
+PRC_ROUTEDEAD, faddr, copcb)\fR
originator+argument \fIfaddr\fR
reason+implemented with so->so_errno for sockets
+that are attached to CONS PCBs
_
N_RESET.confirm+not implemented
=
N_DISCONNECT.request+\fIcons_netcmd(CONN_CLOSE,
+isop, channel, isdgm)\fR
reason, NS-user data, responding address+not implemented
_
N_DISCONNECT.indication+higher layer \fIpr_ctlinput(
+PRC_ROUTEDEAD, faddr, copcb)\fR
originator+argument \fIfaddr\fR
reason+implemented with so->so_errno for sockets
+that are attached to CONS PCBs
NS-user data, responding address+not implemented
.TE
.(c
\fBFigure \n+(FG\fR: Network Service Primitives
.\")
.)c
.)b

60
share/doc/iso/wisc/figs/TS_primitives.nr Normal file
View File

@ -0,0 +1,60 @@
.(b
.TS
center expand box;
c c
a | a .
service primitive & arguments Unix system calls & arguments
=
T_CONNECT.request \fIsocket(), connect(), setsockopt()\fR
called address \fIconnect()\fR argument
calling address \fIconnect()\fR argument
quality of service not implemented
buffer management \fIsetsockopt()\fR argument
security not implemented
data \fIsetsockopt(), getsockopt()\fR
_
T_CONNECT.indication return from \fIaccept(); getsockopt()\fR
called address \fIaccept()\fR argument
calling address \fIaccept()\fR argument
quality of service not implemented
security not implemented
data \fIsetsockopt(), getsockopt()\fR
_
T_CONNECT.response no applicable system calls
_
T_CONNECT.confirm return from \fIconnect()\fR
quality of service \fIgetsockopt()\fR argument
data \fIsetsocktopt, getsockopt()\fR
=
T_DATA.request \fIrecvv(), sendv()\fR
_
T_DATA.indication return from \fIrecvv()\fR, \fIsendv()\fR, or \fIselect()\fR;
or signal SIGIO
ioctl(FIONREAD) tells how much has been
queued to read
=
T_EXPEDITED_DATA.request \fIsendv()\fR with MSG_OOB flag
_
T_EXPEDITED_DATA.indication SIGURG, \fIgetsockopt()\fR with TPFLAG_XPD,
return from \fIselect()\fR with exceptional
conditions mask
=
T_DISCONNECT.request \fIclose()\fR
data \fIsetsockopt()\fR
_
T_DISCONNECT.indication SIGURG,
error return on other primitives
reason errno
data \fIgetsockopt()\**\fR
=
T_STATUS.request \fIgetsockopt()\fR, \fItpstat\fR utility program
_
T_STATUS.indication \fIgetsockopt()\fR, \fIselect()\fR, \fItpstat\fR
.TE
.(c
\fBFigure \n+(FG\fR: Transport Service Primitives
.)c
.)b
.(f
\** data on disconnect is not supported at this time.
.)f

22
share/doc/iso/wisc/figs/addrfmt.nr Normal file
View File

@ -0,0 +1,22 @@
.TS
center,expand,box,tab(+);
c s|c
c|c|c.
T{
.na
IDP: initial domain part
T}+T{
.na
DSP: domain spedific part
T}
_+_+
T{
.na
AFI: authority and format identifier
T}+T{
.na
IDI: initial domain identifier
T}+
.TE
.ce
\fB Figure \n+(FG\fR: Format of OSI addresses

18
share/doc/iso/wisc/figs/clnp_input.grn Normal file
View File

@ -0,0 +1,18 @@
.(z
.GS C
width 6.0
high 7.0
1 8
2 10
3 12
4 14
sc 0.4
narrow 1
medium 3
thick 7
pointscale off
file clnp_input.gsrc
.GE
.ce
\fB Figure \n+(FG:\fR Flow of control for processing CLNP NPDUs
.)z

338
share/doc/iso/wisc/figs/clnp_input.gsrc Normal file
View File

@ -0,0 +1,338 @@
gremlinfile
0 424.00 24.00
3
424.00 696.00
424.00 704.00
-1.00 -1.00
5 0
0
3
312.00 416.00
560.00 416.00
-1.00 -1.00
5 0
0
3
128.00 696.00
125.00 701.00
128.00 699.00
131.00 701.00
128.00 696.00
-1.00 -1.00
5 0
0
3
128.00 264.00
560.00 264.00
560.00 704.00
128.00 704.00
128.00 696.00
-1.00 -1.00
5 0
0
3
424.00 648.00
427.00 643.00
424.00 645.00
421.00 643.00
424.00 648.00
-1.00 -1.00
4 0
0
3
232.00 672.00
288.00 672.00
288.00 632.00
424.00 632.00
-1.00 -1.00
4 0
0
3
232.00 608.00
424.00 608.00
-1.00 -1.00
4 0
0
3
232.00 544.00
424.00 544.00
-1.00 -1.00
4 0
0
3
232.00 480.00
424.00 480.00
-1.00 -1.00
4 0
0
3
232.00 352.00
424.00 352.00
424.00 648.00
-1.00 -1.00
4 0
0
3
351.00 689.00
351.00 656.00
528.00 656.00
528.00 689.00
351.00 689.00
-1.00 -1.00
5 0
0
0
360.00 664.00
360.00 679.00
360.00 679.00
360.00 679.00
-1.00 -1.00
1 2
14 Discard Packet
3
136.00 320.00
141.00 323.00
139.00 320.00
141.00 317.00
136.00 320.00
-1.00 -1.00
5 0
0
3
136.00 384.00
240.00 384.00
240.00 320.00
136.00 320.00
-1.00 -1.00
5 0
0
0
56.00 280.00
56.00 295.00
56.00 295.00
56.00 295.00
-1.00 -1.00
1 2
12 Process NPDU
3
48.00 304.00
48.00 271.00
225.00 271.00
225.00 304.00
48.00 304.00
-1.00 -1.00
5 0
0
0
56.00 600.00
56.00 615.00
56.00 615.00
56.00 615.00
-1.00 -1.00
1 2
18 Consistency Checks
3
47.00 498.00
47.00 465.00
224.00 465.00
224.00 498.00
47.00 498.00
-1.00 -1.00
5 0
0
0
56.00 344.00
56.00 359.00
56.00 359.00
56.00 359.00
-1.00 -1.00
1 2
20 Reassemble Fragments
3
168.00 432.00
168.00 400.00
-1.00 -1.00
5 0
0
3
48.00 432.00
48.00 400.00
304.00 400.00
304.00 432.00
48.00 432.00
-1.00 -1.00
5 0
0
0
200.00 408.00
200.00 423.00
200.00 423.00
200.00 423.00
-1.00 -1.00
1 2
12 Forward NPDU
0
56.00 408.00
56.00 423.00
56.00 423.00
56.00 423.00
-1.00 -1.00
1 2
9 Keep NPDU
0
56.00 472.00
56.00 487.00
56.00 487.00
56.00 487.00
-1.00 -1.00
1 2
15 Process Options
0
56.00 536.00
56.00 551.00
56.00 551.00
56.00 551.00
-1.00 -1.00
1 2
19 Extract Information
0
56.00 664.00
56.00 679.00
56.00 679.00
56.00 679.00
-1.00 -1.00
1 2
14 Dequeue Packet
3
131.00 311.00
128.00 316.00
131.00 314.00
134.00 316.00
131.00 311.00
-1.00 -1.00
5 0
0
3
131.00 329.00
131.00 310.00
-1.00 -1.00
5 0
0
3
130.00 332.00
130.00 332.00
-1.00 -1.00
5 0
0
3
130.00 373.00
127.00 378.00
130.00 376.00
133.00 378.00
130.00 373.00
-1.00 -1.00
5 0
0
3
130.00 394.00
130.00 373.00
-1.00 -1.00
5 0
0
3
130.00 460.00
130.00 439.00
-1.00 -1.00
5 0
0
3
130.00 439.00
127.00 444.00
130.00 442.00
133.00 444.00
130.00 439.00
-1.00 -1.00
5 0
0
3
130.00 501.00
127.00 506.00
130.00 504.00
133.00 506.00
130.00 501.00
-1.00 -1.00
5 0
0
3
130.00 522.00
130.00 501.00
-1.00 -1.00
5 0
0
3
128.00 588.00
128.00 567.00
-1.00 -1.00
5 0
0
3
128.00 567.00
125.00 572.00
128.00 570.00
131.00 572.00
128.00 567.00
-1.00 -1.00
5 0
0
3
128.00 631.00
125.00 636.00
128.00 634.00
131.00 636.00
128.00 631.00
-1.00 -1.00
5 0
0
3
128.00 652.00
128.00 631.00
-1.00 -1.00
5 0
0
3
48.00 368.00
48.00 335.00
225.00 335.00
225.00 368.00
48.00 368.00
-1.00 -1.00
5 0
0
3
47.00 562.00
47.00 529.00
224.00 529.00
224.00 562.00
47.00 562.00
-1.00 -1.00
5 0
0
3
47.00 626.00
47.00 593.00
224.00 593.00
224.00 626.00
47.00 626.00
-1.00 -1.00
5 0
0
3
47.00 689.00
47.00 656.00
224.00 656.00
224.00 689.00
47.00 689.00
-1.00 -1.00
5 0
0
-1

188
share/doc/iso/wisc/figs/clnp_input.nr Normal file
View File

@ -0,0 +1,188 @@
.(z
.br
.nr g1 3456u
.nr g2 2964u
.GS C
.nr g3 \n(.f
.nr g4 \n(.s
\0
.sp -1
\D't 1u'
.sp -1
.sp 101u
\D'l 0u 223u'\D'l 1193u 0u'\D'l 0u -223u'\D'l -1193u 0u'
.sp -1
.sp 425u
\D'l 0u 222u'\D'l 1193u 0u'\D'l 0u -222u'\D'l -1193u 0u'
.sp -1
.sp 431u
\D'l 0u 222u'\D'l 1193u 0u'\D'l 0u -222u'\D'l -1193u 0u'
.sp -1
.sp 1306u
\h'7u'\D'l 0u 222u'\D'l 1192u 0u'\D'l 0u -222u'\D'l -1192u 0u'
.sp -1
.sp -1912u
\h'546u'\D'l 0u 141u'
.sp -1
.sp 141u
\h'546u'\D'l -20u -34u'\D'l 20u 14u'\D'l 20u -14u'\D'l -20u 34u'
.sp -1
.sp 431u
\h'546u'\D'l -20u -33u'\D'l 20u 13u'\D'l 20u -13u'\D'l -20u 33u'
.sp -1
.sp -141u
\h'546u'\D'l 0u 141u'
.sp -1
.sp 444u
\h'559u'\D'l 0u 141u'
.sp -1
.sp 141u
\h'559u'\D'l -20u -34u'\D'l 20u 14u'\D'l 21u -14u'\D'l -21u 34u'
.sp -1
.sp 418u
\h'559u'\D'l -20u -34u'\D'l 20u 13u'\D'l 21u -13u'\D'l -21u 34u'
.sp -1
.sp -142u
\h'559u'\D'l 0u 142u'
.sp -1
.sp 445u
\h'559u'\D'l 0u 141u'
.sp -1
.sp 141u
\h'559u'\D'l -20u -33u'\D'l 20u 13u'\D'l 21u -13u'\D'l -21u 33u'
.sp -1
.sp 276u
\h'559u'\D'l 0u 0u'
.sp -1
.sp 21u
\h'566u'\D'l 0u 128u'
.sp -1
.sp 121u
\h'566u'\D'l -20u -34u'\D'l 20u 14u'\D'l 20u -14u'\D'l -20u 34u'
.sp -1
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Dequeue Packet
.sp -2377u
\h'61u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Extract Information
.sp -1515u
\h'61u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Process Options
.sp -1085u
\h'61u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Keep NPDU
.sp -654u
\h'61u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Forward NPDU
.sp -654u
\h'1031u'\&\*(g9
.sp |\n(g8u
.sp -815u
\h'7u'\D'l 0u 215u'\D'l 1725u 0u'\D'l 0u -215u'\D'l -1725u 0u'
.sp -1
\h'815u'\D'l 0u 215u'
.sp -1
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Reassemble Fragments
.sp 593u
\h'61u'\&\*(g9
.sp |\n(g8u
.sp -445u
\D'l 0u 222u'\D'l 1193u 0u'\D'l 0u -222u'\D'l -1193u 0u'
.sp -1
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Consistency Checks
.sp -686u
\h'61u'\&\*(g9
.sp |\n(g8u
.sp 1307u
\h'7u'\D'l 0u 222u'\D'l 1192u 0u'\D'l 0u -222u'\D'l -1192u 0u'
.sp -1
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Process NPDU
.sp 162u
\h'61u'\&\*(g9
.sp |\n(g8u
.sp -539u
\h'600u'\D'l 700u 0u'\D'l 0u 431u'\D'l -700u 0u'
.sp -1
.sp 431u
\h'600u'\D'l 33u -20u'\D'l -13u 20u'\D'l 13u 20u'\D'l -33u -20u'
.sp -1
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Discard Packet
.sp -2316u
\h'2109u'\&\*(g9
.sp |\n(g8u
.sp -2485u
\h'2048u'\D'l 0u 223u'\D'l 1193u 0u'\D'l 0u -223u'\D'l -1193u 0u'
.sp -1
\D's 16u'
.sp -1
.sp 2270u
\h'1246u'\D'l 1294u 0u'\D'l 0u -1993u'
.sp -1
.sp -863u
\h'1246u'\D'l 1294u 0u'
.sp -1
.sp -430u
\h'1246u'\D'l 1294u 0u'
.sp -1
.sp -431u
\h'1246u'\D'l 1294u 0u'
.sp -1
.sp -431u
\h'1246u'\D'l 378u 0u'\D'l 0u 269u'\D'l 916u 0u'
.sp -1
.sp 162u
\h'2540u'\D'l 20u 33u'\D'l -20u -13u'\D'l -20u 13u'\D'l 20u -33u'
.sp -1
\D's -1u'
.sp -1
.sp 2586u
\h'546u'\D'l 2910u 0u'\D'l 0u -2964u'\D'l -2910u 0u'\D'l 0u 54u'
.sp -1
.sp -2910u
\h'546u'\D'l -20u -34u'\D'l 20u 14u'\D'l 20u -14u'\D'l -20u 34u'
.sp -1
.sp 1886u
\h'1785u'\D'l 1671u 0u'
.sp -1
.sp -1886u
\h'2540u'\D'l 0u -54u'
.sp -1
.sp 2910u
\D't 3u'\D's -1u'
.br
.ft \n(g3
.ps \n(g4
.GE
.ce
\fB Figure \n+(FG:\fR Flow of control for processing CLNP NPDUs
.)z

18
share/doc/iso/wisc/figs/clnp_output.grn Normal file
View File

@ -0,0 +1,18 @@
.(z
.GS C
width 6.0
high 7.0
1 8
2 10
3 12
4 14
sc 0.4
narrow 1
medium 3
thick 7
pointscale off
file clnp_output.gsrc
.GE
.ce
\fB Figure \n+(FG:\fR Flow of control for emitting CLNP NPDUs
.)z

376
share/doc/iso/wisc/figs/clnp_output.gsrc Normal file
View File

@ -0,0 +1,376 @@
gremlinfile
0 528.00 32.00
3
528.00 688.00
531.00 683.00
528.00 685.00
525.00 683.00
528.00 688.00
-1.00 -1.00
5 0
0
3
176.00 160.00
176.00 144.00
528.00 144.00
528.00 688.00
-1.00 -1.00
5 0
0
0
272.00 672.00
272.00 685.00
272.00 685.00
272.00 685.00
-1.00 -1.00
2 2
6 EINVAL
3
240.00 672.00
528.00 672.00
-1.00 -1.00
4 0
0
3
128.00 652.00
128.00 631.00
-1.00 -1.00
5 0
0
3
128.00 631.00
125.00 636.00
128.00 634.00
131.00 636.00
128.00 631.00
-1.00 -1.00
5 0
0
0
64.00 672.00
64.00 687.00
64.00 687.00
64.00 687.00
-1.00 -1.00
1 2
15 Examine Options
3
47.00 689.00
47.00 656.00
224.00 656.00
224.00 689.00
47.00 689.00
-1.00 -1.00
5 0
0
0
64.00 608.00
64.00 623.00
64.00 623.00
64.00 623.00
-1.00 -1.00
1 2
15 Check Addresses
0
64.00 546.00
64.00 561.00
64.00 561.00
64.00 561.00
-1.00 -1.00
1 2
20 Allocate Header mbuf
0
64.00 481.00
64.00 496.00
64.00 496.00
64.00 496.00
-1.00 -1.00
1 2
17 Create Fixed Part
0
64.00 417.00
64.00 432.00
64.00 432.00
64.00 432.00
-1.00 -1.00
1 2
12 Route Packet
0
64.00 352.00
64.00 367.00
64.00 367.00
64.00 367.00
-1.00 -1.00
1 2
19 Append Address Part
0
64.00 290.00
64.00 305.00
64.00 305.00
64.00 305.00
-1.00 -1.00
1 2
19 Append Options Part
0
64.00 225.00
64.00 240.00
64.00 240.00
64.00 240.00
-1.00 -1.00
1 2
13 Transmit NPDU
0
192.00 224.00
192.00 239.00
192.00 239.00
192.00 239.00
-1.00 -1.00
1 2
13 Fragment NPDU
3
47.00 625.00
47.00 592.00
224.00 592.00
224.00 625.00
47.00 625.00
-1.00 -1.00
5 0
0
3
47.00 562.00
47.00 529.00
224.00 529.00
224.00 562.00
47.00 562.00
-1.00 -1.00
5 0
0
3
47.00 498.00
47.00 465.00
224.00 465.00
224.00 498.00
47.00 498.00
-1.00 -1.00
5 0
0
3
48.00 433.00
48.00 400.00
225.00 400.00
225.00 433.00
48.00 433.00
-1.00 -1.00
5 0
0
3
47.00 368.00
47.00 335.00
224.00 335.00
224.00 368.00
47.00 368.00
-1.00 -1.00
5 0
0
3
48.00 304.00
48.00 271.00
225.00 271.00
225.00 304.00
48.00 304.00
-1.00 -1.00
5 0
0
3
49.00 240.00
49.00 209.00
306.00 209.00
306.00 240.00
49.00 240.00
-1.00 -1.00
5 0
0
3
167.00 239.00
167.00 209.00
-1.00 -1.00
1 0
0
3
128.00 588.00
128.00 567.00
-1.00 -1.00
5 0
0
3
128.00 567.00
125.00 572.00
128.00 570.00
131.00 572.00
128.00 567.00
-1.00 -1.00
5 0
0
3
128.00 503.00
125.00 508.00
128.00 506.00
131.00 508.00
128.00 503.00
-1.00 -1.00
5 0
0
3
128.00 524.00
128.00 503.00
-1.00 -1.00
5 0
0
3
130.00 458.00
130.00 437.00
-1.00 -1.00
5 0
0
3
130.00 437.00
127.00 442.00
130.00 440.00
133.00 442.00
130.00 437.00
-1.00 -1.00
5 0
0
3
130.00 375.00
127.00 380.00
130.00 378.00
133.00 380.00
130.00 375.00
-1.00 -1.00
5 0
0
3
130.00 396.00
130.00 375.00
-1.00 -1.00
5 0
0
3
130.00 330.00
130.00 309.00
-1.00 -1.00
5 0
0
3
130.00 309.00
127.00 314.00
130.00 312.00
133.00 314.00
130.00 309.00
-1.00 -1.00
5 0
0
3
130.00 268.00
130.00 268.00
-1.00 -1.00
5 0
0
3
131.00 265.00
131.00 246.00
-1.00 -1.00
5 0
0
3
131.00 247.00
128.00 252.00
131.00 250.00
134.00 252.00
131.00 247.00
-1.00 -1.00
5 0
0
3
146.00 320.00
242.00 320.00
242.00 255.00
146.00 255.00
-1.00 -1.00
5 0
0
3
146.00 255.00
151.00 258.00
149.00 255.00
151.00 252.00
146.00 255.00
-1.00 -1.00
5 0
0
0
272.00 608.00
272.00 621.00
272.00 621.00
272.00 621.00
-1.00 -1.00
2 2
12 ENAMETOOLONG
0
273.00 545.00
273.00 558.00
273.00 558.00
273.00 558.00
-1.00 -1.00
2 2
7 ENOBUFS
0
272.00 417.00
272.00 430.00
272.00 430.00
272.00 430.00
-1.00 -1.00
2 2
25 ENETUNREACH, EHOSTUNREACH
0
272.00 289.00
272.00 302.00
272.00 302.00
272.00 302.00
-1.00 -1.00
2 2
7 ENOBUFS
3
241.00 601.00
529.00 601.00
-1.00 -1.00
4 0
0
3
240.00 536.00
530.00 536.00
-1.00 -1.00
4 0
0
3
241.00 413.00
527.00 413.00
-1.00 -1.00
4 0
0
3
233.00 288.00
529.00 288.00
-1.00 -1.00
4 0
0
0
152.00 175.00
152.00 190.00
152.00 190.00
152.00 190.00
-1.00 -1.00
1 2
7 SUCCESS
-1

233
share/doc/iso/wisc/figs/clnp_output.nr Normal file
View File

@ -0,0 +1,233 @@
.(z
.br
.nr g1 3456u
.nr g2 3891u
.GS C
.nr g3 \n(.f
.nr g4 \n(.s
\0
.sp -1
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "SUCCESS
.sp 3670u
\h'750u'\&\*(g9
.sp |\n(g8u
\D's 16u'\D't 1u'
.sp -1
.sp 2863u
\h'1328u'\D'l 2114u 0u'
.sp -1
.sp -893u
\h'1385u'\D'l 2043u 0u'
.sp -1
.sp -877u
\h'1378u'\D'l 2071u 0u'
.sp -1
.sp -464u
\h'1385u'\D'l 2057u 0u'
.sp -1
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "ENOBUFS
.sp 2227u
\h'1607u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "ENETUNREACH, EHOSTUNREACH
.sp 1313u
\h'1607u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "ENOBUFS
.sp 400u
\h'1614u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "ENAMETOOLONG
.sp -50u
\h'1607u'\&\*(g9
.sp |\n(g8u
\D's -1u'
.sp -1
.sp 2469u
\h'707u'\D'l 36u -21u'\D'l -15u 21u'\D'l 15u 22u'\D'l -36u -22u'
.sp -1
.sp -464u
\h'707u'\D'l 686u 0u'\D'l 0u 464u'\D'l -686u 0u'
.sp -1
.sp 522u
\h'600u'\D'l -22u -36u'\D'l 22u 14u'\D'l 21u -14u'\D'l -21u 36u'
.sp -1
.sp -129u
\h'600u'\D'l 0u 136u'
.sp -1
.sp -21u
\h'593u'\D'l 0u 0u'
.sp -1
.sp -293u
\h'593u'\D'l -22u -36u'\D'l 22u 14u'\D'l 21u -14u'\D'l -21u 36u'
.sp -1
.sp -150u
\h'593u'\D'l 0u 150u'
.sp -1
.sp -471u
\h'593u'\D'l 0u 150u'
.sp -1
.sp 150u
\h'593u'\D'l -22u -36u'\D'l 22u 14u'\D'l 21u -14u'\D'l -21u 36u'
.sp -1
.sp -443u
\h'593u'\D'l -22u -36u'\D'l 22u 14u'\D'l 21u -14u'\D'l -21u 36u'
.sp -1
.sp -150u
\h'593u'\D'l 0u 150u'
.sp -1
.sp -470u
\h'578u'\D'l 0u 149u'
.sp -1
.sp 149u
\h'578u'\D'l -21u -36u'\D'l 21u 14u'\D'l 22u -14u'\D'l -22u 36u'
.sp -1
.sp -456u
\h'578u'\D'l -21u -36u'\D'l 21u 14u'\D'l 22u -14u'\D'l -22u 36u'
.sp -1
.sp -150u
\h'578u'\D'l 0u 150u'
.sp -1
\D's 4u'
.sp -1
.sp 2491u
\h'857u'\D'l 0u 214u'
.sp -1
\D's -1u'
.sp -1
.sp -7u
\h'14u'\D'l 0u 221u'\D'l 1835u 0u'\D'l 0u -221u'\D'l -1835u 0u'
.sp -1
.sp -457u
\h'7u'\D'l 0u 235u'\D'l 1264u 0u'\D'l 0u -235u'\D'l -1264u 0u'
.sp -1
.sp -457u
\D'l 0u 235u'\D'l 1264u 0u'\D'l 0u -235u'\D'l -1264u 0u'
.sp -1
.sp -465u
\h'7u'\D'l 0u 236u'\D'l 1264u 0u'\D'l 0u -236u'\D'l -1264u 0u'
.sp -1
.sp -464u
\D'l 0u 236u'\D'l 1264u 0u'\D'l 0u -236u'\D'l -1264u 0u'
.sp -1
.sp -456u
\D'l 0u 236u'\D'l 1264u 0u'\D'l 0u -236u'\D'l -1264u 0u'
.sp -1
.sp -450u
\D'l 0u 236u'\D'l 1264u 0u'\D'l 0u -236u'\D'l -1264u 0u'
.sp -1
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Fragment NPDU
.sp 2863u
\h'1035u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Transmit NPDU
.sp 2856u
\h'121u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Append Options Part
.sp 2392u
\h'121u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Append Address Part
.sp 1949u
\h'121u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Route Packet
.sp 1485u
\h'121u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Create Fixed Part
.sp 1028u
\h'121u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Allocate Header mbuf
.sp 565u
\h'121u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Check Addresses
.sp 122u
\h'121u'\&\*(g9
.sp |\n(g8u
.sp -457u
\D'l 0u 236u'\D'l 1264u 0u'\D'l 0u -236u'\D'l -1264u 0u'
.sp -1
.ft R
.ps 10
.nr g8 \n(.d
.ds g9 "Examine Options
.sp 122u
\h'121u'\&\*(g9
.sp |\n(g8u
.sp 415u
\h'578u'\D'l -21u -36u'\D'l 21u 14u'\D'l 22u -14u'\D'l -22u 36u'
.sp -1
.sp -150u
\h'578u'\D'l 0u 150u'
.sp -1
\D's 16u'
.sp -1
.sp -143u
\h'1378u'\D'l 2057u 0u'
.sp -1
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "EINVAL
\h'1607u'\&\*(g9
.sp |\n(g8u
\D's -1u'
.sp -1
.sp 3655u
\h'921u'\D'l 0u 114u'\D'l 2514u 0u'\D'l 0u -3883u'
.sp -1
.sp -3769u
\h'3435u'\D'l 21u 35u'\D'l -21u -14u'\D'l -22u 14u'\D'l 22u -35u'
.sp -1
.sp 3883u
\D't 3u'\D's -1u'
.br
.ft \n(g3
.ps \n(g4
.GE
.ce
\fB Figure \n+(FG:\fR Flow of control for emitting CLNP NPDUs
.)z

19
share/doc/iso/wisc/figs/ecn_network.grn Normal file
View File

@ -0,0 +1,19 @@
.(z
.hl
.GS C
width 6.0
high 4.0
1 6
2 8
3 10
4 12
sc 0.5
narrow 1
medium 3
thick 7
pointscale off
file ecn_network.gsrc
.GE
.ce
\fBFigure \n+(FG:\fR The X.25 Network Interface
.)z

288
share/doc/iso/wisc/figs/ecn_network.gsrc Normal file
View File

@ -0,0 +1,288 @@
gremlinfile
0 370.00 354.00
0
370.00 346.00
370.00 361.00
370.00 361.00
370.00 361.00
-1.00 -1.00
1 2
10 (/dev/bus)
0
360.00 361.00
360.00 376.00
360.00 376.00
360.00 376.00
-1.00 -1.00
1 2
13 X.25 download
0
558.00 524.00
558.00 539.00
558.00 539.00
558.00 539.00
-1.00 -1.00
1 2
13 configuration
0
558.00 534.00
558.00 549.00
558.00 549.00
558.00 549.00
-1.00 -1.00
1 2
8 updated
0
358.00 459.00
358.00 474.00
358.00 474.00
358.00 474.00
-1.00 -1.00
1 2
12 (/dev/kmem1)
0
362.00 474.00
362.00 489.00
362.00 489.00
362.00 489.00
-1.00 -1.00
1 2
13 configuration
0
248.00 399.00
248.00 414.00
248.00 414.00
248.00 414.00
-1.00 -1.00
1 2
22 Data Area on the board
0
248.00 409.00
248.00 424.00
248.00 424.00
248.00 424.00
-1.00 -1.00
1 2
22 to and from the Common
0
245.00 507.00
245.00 522.00
245.00 522.00
245.00 522.00
-1.00 -1.00
1 2
10 ecnioctl()
0
245.00 516.00
245.00 531.00
245.00 531.00
245.00 531.00
-1.00 -1.00
1 2
12 ecnrestart()
0
245.00 524.00
245.00 539.00
245.00 539.00
245.00 539.00
-1.00 -1.00
1 2
13 ecnshutdown()
0
176.00 419.00
176.00 434.00
176.00 434.00
176.00 434.00
-1.00 -1.00
1 2
34 INTERFACES: the NCB command loaded
0
175.00 532.00
175.00 547.00
175.00 547.00
175.00 547.00
-1.00 -1.00
1 2
23 INTERFACES: ecnoutput()
0
42.00 415.00
42.00 430.00
42.00 430.00
42.00 430.00
-1.00 -1.00
1 2
15 COMMANDS: NCB_*
0
42.00 527.00
42.00 542.00
42.00 542.00
42.00 542.00
-1.00 -1.00
1 2
15 COMMANDS: ECN_*
3
546.00 511.00
553.00 494.00
560.00 511.00
-1.00 -1.00
5 0
0
3
287.00 364.00
270.00 357.00
287.00 348.00
-1.00 -1.00
5 0
0
3
287.00 477.00
271.00 469.00
287.00 461.00
-1.00 -1.00
5 0
0
3
151.00 397.00
159.00 382.00
167.00 398.00
-1.00 -1.00
5 0
0
3
151.00 431.00
159.00 445.00
167.00 431.00
-1.00 -1.00
5 0
0
3
153.00 510.00
160.00 494.00
168.00 510.00
-1.00 -1.00
5 0
0
3
152.00 540.00
160.00 558.00
167.00 540.00
-1.00 -1.00
5 0
0
3
272.00 469.00
492.00 469.00
-1.00 -1.00
5 0
0
3
271.00 357.00
552.00 357.00
552.00 446.00
-1.00 -1.00
5 0
0
3
553.00 557.00
553.00 494.00
-1.00 -1.00
5 0
0
3
159.00 445.00
159.00 381.00
-1.00 -1.00
5 0
0
3
160.00 557.00
160.00 494.00
-1.00 -1.00
5 0
0
0
517.00 458.00
517.00 472.00
517.00 472.00
517.00 472.00
-1.00 -1.00
1 3
8 %ecnload
0
514.00 570.00
514.00 584.00
514.00 584.00
514.00 584.00
-1.00 -1.00
1 3
8 %ecnconf
0
115.00 347.00
115.00 366.00
115.00 366.00
115.00 366.00
-1.00 -1.00
1 4
11 EICON Board
0
114.00 458.00
114.00 477.00
114.00 477.00
114.00 477.00
-1.00 -1.00
1 4
11 UNIX Driver
0
133.00 569.00
133.00 588.00
133.00 588.00
133.00 588.00
-1.00 -1.00
1 4
4 CONS
3
493.00 445.00
493.00 493.00
608.00 493.00
608.00 445.00
493.00 445.00
-1.00 -1.00
5 0
0
3
493.00 557.00
493.00 605.00
608.00 605.00
608.00 557.00
493.00 557.00
-1.00 -1.00
5 0
0
3
63.00 332.00
63.00 381.00
272.00 381.00
272.00 332.00
63.00 332.00
-1.00 -1.00
5 0
0
3
63.00 445.00
63.00 494.00
272.00 494.00
272.00 445.00
63.00 445.00
-1.00 -1.00
5 0
0
3
63.00 557.00
63.00 606.00
272.00 606.00
272.00 557.00
63.00 557.00
-1.00 -1.00
5 0
0
-1

0
share/doc/iso/wisc/figs/ecn_network.nr Normal file
View File

19
share/doc/iso/wisc/figs/ecn_queue.grn Normal file
View File

@ -0,0 +1,19 @@
.(z
.hl
.GS C
width 6.0
high 3.0
1 5
2 7
3 9
4 12
sc 0.5
narrow 1
medium 3
thick 7
pointscale off
file ecn_queue.gsrc
.GE
.ce
\fBFigure \n+(FG:\fR Queue Placement Strategy
.)z

371
share/doc/iso/wisc/figs/ecn_queue.gsrc Normal file
View File

@ -0,0 +1,371 @@
gremlinfile
0 98.00 422.00
3
98.00 278.00
562.00 278.00
-1.00 -1.00
4 0
0
3
425.00 557.00
577.00 557.00
-1.00 -1.00
4 0
0
3
341.00 528.00
425.00 528.00
-1.00 -1.00
5 0
0
0
457.00 536.00
457.00 549.00
457.00 549.00
457.00 549.00
-1.00 -1.00
2 3
10 ECN driver
0
321.00 419.00
321.00 432.00
321.00 432.00
321.00 432.00
-1.00 -1.00
2 2
20 Driver->CONS replies
0
356.00 584.00
356.00 599.00
356.00 599.00
356.00 599.00
-1.00 -1.00
1 2
8 x25intrq
0
457.00 253.00
457.00 266.00
457.00 266.00
457.00 266.00
-1.00 -1.00
2 3
16 EICON X.25 board
0
457.00 285.00
457.00 298.00
457.00 298.00
457.00 298.00
-1.00 -1.00
2 3
10 ECN driver
0
457.00 563.00
457.00 576.00
457.00 576.00
457.00 576.00
-1.00 -1.00
2 3
11 CONS module
3
217.00 557.00
340.00 557.00
-1.00 -1.00
4 0
0
3
90.00 556.00
131.00 556.00
-1.00 -1.00
4 0
0
3
375.00 222.00
381.00 209.00
389.00 222.00
-1.00 -1.00
5 0
0
3
168.00 222.00
174.00 209.00
182.00 222.00
-1.00 -1.00
5 0
0
3
165.00 615.00
171.00 602.00
179.00 615.00
-1.00 -1.00
5 0
0
3
166.00 421.00
172.00 408.00
180.00 421.00
-1.00 -1.00
5 0
0
3
173.00 392.00
189.00 371.00
-1.00 -1.00
1 0
0
3
173.00 348.00
172.00 392.00
273.00 360.00
-1.00 -1.00
1 0
0
3
306.00 361.00
382.00 414.00
-1.00 -1.00
1 0
0
3
266.00 228.00
273.00 243.00
280.00 228.00
-1.00 -1.00
5 0
0
0
201.00 197.00
201.00 210.00
201.00 210.00
201.00 210.00
-1.00 -1.00
2 2
23 Driver<->Board commands
3
273.00 246.00
273.00 214.00
-1.00 -1.00
1 0
0
0
223.00 295.00
223.00 308.00
223.00 308.00
223.00 308.00
-1.00 -1.00
2 2
15 posted commands
3
111.00 402.00
131.00 402.00
-1.00 -1.00
5 0
0
3
376.00 459.00
383.00 474.00
390.00 459.00
-1.00 -1.00
5 0
0
3
364.00 363.00
383.00 416.00
387.00 357.00
-1.00 -1.00
1 0
0
3
383.00 437.00
383.00 473.00
-1.00 -1.00
1 0
0
3
172.00 411.00
172.00 474.00
-1.00 -1.00
1 0
0
0
8.00 401.00
8.00 416.00
8.00 416.00
8.00 416.00
-1.00 -1.00
1 2
15 ecn_pending_req
0
109.00 653.00
109.00 666.00
109.00 666.00
109.00 666.00
-1.00 -1.00
2 2
20 CONS->Driver command
0
357.00 570.00
357.00 585.00
357.00 585.00
357.00 585.00
-1.00 -1.00
1 2
5 QUEUE
0
151.00 569.00
151.00 584.00
151.00 584.00
151.00 584.00
-1.00 -1.00
1 2
5 QUEUE
3
340.00 315.00
340.00 298.00
422.00 298.00
422.00 315.00
340.00 315.00
-1.00 -1.00
6 0
0
3
235.00 347.00
235.00 330.00
317.00 330.00
317.00 347.00
235.00 347.00
-1.00 -1.00
6 0
0
3
232.00 262.00
232.00 245.00
314.00 245.00
314.00 262.00
232.00 262.00
-1.00 -1.00
6 0
0
3
133.00 329.00
133.00 312.00
215.00 312.00
215.00 329.00
133.00 329.00
-1.00 -1.00
6 0
0
3
133.00 409.00
133.00 392.00
215.00 392.00
215.00 409.00
133.00 409.00
-1.00 -1.00
6 0
0
3
340.00 547.00
426.00 547.00
-1.00 -1.00
5 0
0
3
340.00 509.00
425.00 509.00
-1.00 -1.00
5 0
0
3
340.00 491.00
424.00 491.00
-1.00 -1.00
5 0
0
3
340.00 602.00
340.00 473.00
425.00 473.00
425.00 601.00
-1.00 -1.00
6 0
0
3
132.00 547.00
218.00 547.00
-1.00 -1.00
5 0
0
3
133.00 528.00
217.00 528.00
-1.00 -1.00
5 0
0
3
132.00 509.00
217.00 509.00
-1.00 -1.00
5 0
0
3
132.00 491.00
216.00 491.00
-1.00 -1.00
5 0
0
3
132.00 602.00
132.00 473.00
217.00 473.00
217.00 601.00
-1.00 -1.00
6 0
0
3
125.00 410.00
132.00 402.00
125.00 395.00
-1.00 -1.00
5 0
0
3
174.00 211.00
174.00 312.00
-1.00 -1.00
1 0
0
3
381.00 210.00
381.00 298.00
-1.00 -1.00
1 0
0
3
374.00 282.00
381.00 297.00
388.00 282.00
-1.00 -1.00
5 0
0
3
167.00 297.00
174.00 312.00
181.00 297.00
-1.00 -1.00
5 0
0
0
156.00 583.00
156.00 598.00
156.00 598.00
156.00 598.00
-1.00 -1.00
1 2
6 ecn_if
3
171.00 604.00
171.00 648.00
-1.00 -1.00
1 0
0
-1

262
share/doc/iso/wisc/figs/ecn_queue.nr Normal file
View File

@ -0,0 +1,262 @@
.(z
.hl
.br
.nr g1 2156u
.nr g2 1727u
.GS C
.nr g3 \n(.f
.nr g4 \n(.s
\0
.sp -1
\D's 4u'\D't 1u'
.sp -1
.sp 186u
\h'617u'\D'l 0u -167u'
.sp -1
.ft R
.ps 7
.nr g8 \n(.d
.ds g9 "ecn_if
.sp 80u
\h'561u'\&\*(g9
.sp |\n(g8u
\D's -1u'
.sp -1
.sp 1162u
\h'602u'\D'l 27u -56u'\D'l 26u 56u'
.sp -1
.sp 57u
\h'1387u'\D'l 26u -57u'\D'l 27u 57u'
.sp -1
\D's 4u'
.sp -1
.sp 273u
\h'1413u'\D'l 0u -333u'
.sp -1
.sp -4u
\h'629u'\D'l 0u -382u'
.sp -1
\D's -1u'
.sp -1
.sp -754u
\h'443u'\D'l 27u 31u'\D'l -27u 26u'
.sp -1
\D't 3u'
.sp -1
.sp -726u
\h'470u'\D'l 0u 487u'\D'l 322u 0u'\D'l 0u -484u'
.sp -1
\D't 1u'
.sp -1
.sp 419u
\h'470u'\D'l 318u 0u'
.sp -1
.sp -68u
\h'470u'\D'l 322u 0u'
.sp -1
.sp -71u
\h'473u'\D'l 319u 0u'
.sp -1
.sp -72u
\h'470u'\D'l 326u 0u'
.sp -1
\D't 3u'
.sp -1
.sp -208u
\h'1258u'\D'l 0u 487u'\D'l 322u 0u'\D'l 0u -484u'
.sp -1
\D't 1u'
.sp -1
.sp 419u
\h'1258u'\D'l 318u 0u'
.sp -1
.sp -68u
\h'1258u'\D'l 322u 0u'
.sp -1
.sp -143u
\h'1258u'\D'l 326u 0u'
.sp -1
\D't 3u'
.sp -1
.sp 522u
\h'473u'\D'l 0u 64u'\D'l 311u 0u'\D'l 0u -64u'\D'l -311u 0u'
.sp -1
.sp 303u
\h'473u'\D'l 0u 65u'\D'l 311u 0u'\D'l 0u -65u'\D'l -311u 0u'
.sp -1
.sp 254u
\h'849u'\D'l 0u 64u'\D'l 310u 0u'\D'l 0u -64u'\D'l -310u 0u'
.sp -1
.sp -322u
\h'860u'\D'l 0u 64u'\D'l 311u 0u'\D'l 0u -64u'\D'l -311u 0u'
.sp -1
.sp 121u
\h'1258u'\D'l 0u 65u'\D'l 311u 0u'\D'l 0u -65u'\D'l -311u 0u'
.sp -1
.ft R
.ps 7
.nr g8 \n(.d
.ds g9 "QUEUE
.sp -961u
\h'542u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 7
.nr g8 \n(.d
.ds g9 "QUEUE
.sp -965u
\h'1322u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 7
.nr g8 \n(.d
.ds g9 "CONS->Driver command
.sp -1280u
\h'383u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 7
.nr g8 \n(.d
.ds g9 "ecn_pending_req
.sp -326u
\&\*(g9
.sp |\n(g8u
\D's 4u'\D't 1u'
.sp -1
.sp -364u
\h'621u'\D'l 0u -238u'
.sp -1
.sp -98u
\h'1421u'\D'l 0u -137u'
.sp -1
.sp 280u
\h'1349u'\D'l 72u -201u'\D'l 15u 224u'
.sp -1
\D's -1u'
.sp -1
.sp -363u
\h'1394u'\D'l 27u -57u'\D'l 26u 57u'
.sp -1
.sp 216u
\h'390u'\D'l 76u 0u'
.sp -1
.ft I
.ps 7
.nr g8 \n(.d
.ds g9 "posted commands
.sp 405u
\h'815u'\&\*(g9
.sp |\n(g8u
\D's 4u'
.sp -1
.sp 591u
\h'1004u'\D'l 0u 121u'
.sp -1
.ft I
.ps 7
.nr g8 \n(.d
.ds g9 "Driver<->Board commands
.sp 185u
\h'731u'\&\*(g9
.sp |\n(g8u
\D's -1u'
.sp -1
.sp 68u
\h'977u'\D'l 27u -57u'\D'l 27u 57u'
.sp -1
\D's 4u'
.sp -1
.sp -504u
\h'1129u'\D'l 288u -201u'
.sp -1
.sp 49u
\h'625u'\D'l -4u -167u'\D'l 383u 122u'
.sp -1
.sp -167u
\h'625u'\D'l 61u 80u'
.sp -1
\D's -1u'
.sp -1
.sp -109u
\h'599u'\D'l 22u 49u'\D'l 31u -49u'
.sp -1
.sp -735u
\h'595u'\D'l 22u 50u'\D'l 31u -50u'
.sp -1
.sp 1489u
\h'606u'\D'l 23u 49u'\D'l 30u -49u'
.sp -1
\h'1391u'\D'l 22u 49u'\D'l 31u -49u'
.sp -1
\D's 16u'
.sp -1
.sp -1265u
\h'311u'\D'l 155u 0u'
.sp -1
.sp -4u
\h'792u'\D'l 466u 0u'
.sp -1
.ft I
.ps 9
.nr g8 \n(.d
.ds g9 "CONS module
.sp -23u
\h'1701u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 9
.nr g8 \n(.d
.ds g9 "ECN driver
.sp 1030u
\h'1701u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 9
.nr g8 \n(.d
.ds g9 "EICON X.25 board
.sp 1151u
\h'1701u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 7
.nr g8 \n(.d
.ds g9 "x25intrq
.sp -102u
\h'1319u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 7
.nr g8 \n(.d
.ds g9 "Driver->CONS replies
.sp 522u
\h'1186u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 9
.nr g8 \n(.d
.ds g9 "ECN driver
.sp 80u
\h'1701u'\&\*(g9
.sp |\n(g8u
\D's -1u'
.sp -1
.sp 110u
\h'1262u'\D'l 318u 0u'
.sp -1
\D's 16u'
.sp -1
.sp -110u
\h'1580u'\D'l 576u 0u'
.sp -1
.sp 1056u
\h'341u'\D'l 1758u 0u'
.sp -1
.sp 307u
\D't 3u'\D's -1u'
.br
.ft \n(g3
.ps \n(g4
.GE
.ce
\fBFigure \n+(FG:\fR Queue Placement Strategy
.)z

19
share/doc/iso/wisc/figs/ecn_vc.grn Normal file
View File

@ -0,0 +1,19 @@
.(z
.hl
.GS C
width 6.0
high 4.0
1 8
2 10
3 12
4 14
sc 0.5
narrow 1
medium 3
thick 7
pointscale off
file ecn_vc.gsrc
.GE
.ce
\fBFigure \n+(FG:\fR Virtual Circuit State Diagram
.)z

273
share/doc/iso/wisc/figs/ecn_vc.gsrc Normal file
View File

@ -0,0 +1,273 @@
gremlinfile
0 184.00 269.00
0
184.00 431.00
184.00 441.00
184.00 441.00
184.00 441.00
-1.00 -1.00
2 1
23 SEND/RECEIVE completion
0
110.00 358.00
110.00 368.00
110.00 368.00
110.00 368.00
-1.00 -1.00
2 1
10 completion
0
99.00 368.00
99.00 378.00
99.00 378.00
99.00 378.00
-1.00 -1.00
2 1
11 CLEAR/ABORT
0
366.00 360.00
366.00 370.00
366.00 370.00
366.00 370.00
-1.00 -1.00
2 1
6 issued
0
359.00 373.00
359.00 383.00
359.00 383.00
359.00 383.00
-1.00 -1.00
2 1
11 CLEAR/ABORT
0
210.00 445.00
210.00 455.00
210.00 455.00
210.00 455.00
-1.00 -1.00
2 1
9 0x0a from
0
206.00 495.00
206.00 505.00
206.00 505.00
206.00 505.00
-1.00 -1.00
2 1
22 CALL/LISTEN completion
0
264.00 523.00
264.00 533.00
264.00 533.00
264.00 533.00
-1.00 -1.00
2 1
10 completion
0
240.00 533.00
240.00 543.00
240.00 543.00
240.00 543.00
-1.00 -1.00
2 1
13 RECEIVE/RESET
0
379.00 575.00
379.00 585.00
379.00 585.00
379.00 585.00
-1.00 -1.00
2 1
10 completion
0
345.00 589.00
345.00 599.00
345.00 599.00
345.00 599.00
-1.00 -1.00
2 1
22 0x18 from SEND/RECEIVE
0
394.00 602.00
394.00 612.00
394.00 612.00
394.00 612.00
-1.00 -1.00
2 1
6 - or -
0
367.00 613.00
367.00 623.00
367.00 623.00
367.00 623.00
-1.00 -1.00
2 1
12 RESET issued
3
319.00 359.00
311.00 340.00
329.00 349.00
-1.00 -1.00
5 0
0
3
361.00 520.00
367.00 503.00
351.00 508.00
-1.00 -1.00
5 0
0
3
143.00 391.00
138.00 409.00
154.00 401.00
-1.00 -1.00
5 0
0
3
328.00 582.00
323.00 600.00
339.00 592.00
-1.00 -1.00
5 0
0
3
163.00 420.00
152.00 427.00
163.00 435.00
-1.00 -1.00
5 0
0
3
350.00 485.00
361.00 492.00
350.00 500.00
-1.00 -1.00
5 0
0
3
312.00 341.00
375.00 407.00
-1.00 -1.00
4 0
0
3
135.00 410.00
202.00 343.00
-1.00 -1.00
4 0
0
3
320.00 601.00
408.00 529.00
-1.00 -1.00
4 0
0
3
293.00 563.00
368.00 503.00
-1.00 -1.00
4 0
0
3
150.00 428.00
358.00 428.00
-1.00 -1.00
4 0
0
3
148.00 492.00
363.00 492.00
-1.00 -1.00
4 0
0
0
226.00 309.00
226.00 319.00
226.00 319.00
226.00 319.00
-1.00 -1.00
1 1
8 VC_CLEAR
0
372.00 455.00
372.00 465.00
372.00 465.00
372.00 465.00
-1.00 -1.00
1 1
12 VC_DATA_XFER
0
25.00 458.00
25.00 468.00
25.00 468.00
25.00 468.00
-1.00 -1.00
1 1
16 VC_NO_CONNECTION
0
218.00 293.00
218.00 303.00
218.00 303.00
218.00 303.00
-1.00 -1.00
1 1
11 IN_PROGRESS
0
222.00 618.00
222.00 628.00
222.00 628.00
222.00 628.00
-1.00 -1.00
1 1
11 IN_PROGRESS
0
228.00 634.00
228.00 644.00
228.00 644.00
228.00 644.00
-1.00 -1.00
1 1
8 VC_RESET
4
423.00 459.00
429.00 390.00
423.00 528.26
423.00 389.74
353.74 459.00
492.26 459.00
-1.00 -1.00
5 0
0
4
89.00 459.00
83.00 390.00
89.00 528.26
89.00 389.74
158.26 459.00
19.74 459.00
-1.00 -1.00
5 0
0
4
256.00 299.00
250.00 230.00
256.00 368.26
256.00 229.74
325.26 299.00
186.74 299.00
-1.00 -1.00
5 0
0
4
256.00 621.00
250.00 690.00
256.00 551.74
256.00 690.26
325.26 621.00
186.74 621.00
-1.00 -1.00
5 0
0
-1

205
share/doc/iso/wisc/figs/ecn_vc.nr Normal file
View File

@ -0,0 +1,205 @@
.(z
.hl
.br
.nr g1 2364u
.nr g2 2303u
.GS C
.nr g3 \n(.f
.nr g4 \n(.s
\0
.sp -1
\D't 1u'
.sp -1
.sp 346u
\h'836u'\D'c 693u'
.sp -1
.sp 1610u
\h'836u'\D'c 693u'
.sp -1
.sp -800u
\D'c 693u'
.sp -1
\h'1671u'\D'c 693u'
.sp -1
.ft R
.ps 8
.nr g8 \n(.d
.ds g9 "VC_RESET
.sp -875u
\h'1042u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 8
.nr g8 \n(.d
.ds g9 "IN_PROGRESS
.sp -795u
\h'1012u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 8
.nr g8 \n(.d
.ds g9 "IN_PROGRESS
.sp 830u
\h'992u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 8
.nr g8 \n(.d
.ds g9 "VC_NO_CONNECTION
.sp 5u
\h'27u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 8
.nr g8 \n(.d
.ds g9 "VC_DATA_XFER
.sp 20u
\h'1763u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 8
.nr g8 \n(.d
.ds g9 "VC_CLEAR
.sp 750u
\h'1032u'\&\*(g9
.sp |\n(g8u
\D's 16u'
.sp -1
.sp -165u
\h'642u'\D'l 1076u 0u'
.sp -1
.sp 320u
\h'652u'\D'l 1041u 0u'
.sp -1
.sp -675u
\h'1367u'\D'l 376u 300u'
.sp -1
.sp -190u
\h'1502u'\D'l 441u 360u'
.sp -1
.sp 955u
\h'577u'\D'l 335u 335u'
.sp -1
.sp 345u
\h'1462u'\D'l 316u -330u'
.sp -1
\D's -1u'
.sp -1
.sp -720u
\h'1653u'\D'l 55u -35u'\D'l -55u -40u'
.sp -1
.sp 325u
\h'717u'\D'l -55u -35u'\D'l 55u -40u'
.sp -1
.sp -810u
\h'1542u'\D'l -25u -90u'\D'l 81u 40u'
.sp -1
.sp 955u
\h'617u'\D'l -25u -90u'\D'l 80u 40u'
.sp -1
.sp -645u
\h'1708u'\D'l 30u 85u'\D'l -80u -25u'
.sp -1
.sp 805u
\h'1497u'\D'l -40u 95u'\D'l 91u -45u'
.sp -1
.ft I
.ps 8
.nr g8 \n(.d
.ds g9 "RESET issued
.sp -1270u
\h'1738u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 8
.nr g8 \n(.d
.ds g9 "- or -
.sp -1215u
\h'1873u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 8
.nr g8 \n(.d
.ds g9 "0x18 from SEND/RECEIVE
.sp -1150u
\h'1628u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 8
.nr g8 \n(.d
.ds g9 "completion
.sp -1080u
\h'1798u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 8
.nr g8 \n(.d
.ds g9 "RECEIVE/RESET
.sp -870u
\h'1102u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 8
.nr g8 \n(.d
.ds g9 "completion
.sp -820u
\h'1222u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 8
.nr g8 \n(.d
.ds g9 "CALL/LISTEN completion
.sp -680u
\h'932u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 8
.nr g8 \n(.d
.ds g9 "0x0a from
.sp -430u
\h'952u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 8
.nr g8 \n(.d
.ds g9 "CLEAR/ABORT
.sp -70u
\h'1698u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 8
.nr g8 \n(.d
.ds g9 "issued
.sp -5u
\h'1733u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 8
.nr g8 \n(.d
.ds g9 "CLEAR/ABORT
.sp -45u
\h'397u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 8
.nr g8 \n(.d
.ds g9 "completion
.sp 5u
\h'452u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 8
.nr g8 \n(.d
.ds g9 "SEND/RECEIVE completion
.sp -360u
\h'822u'\&\*(g9
.sp |\n(g8u
.sp 647u
\D't 3u'\D's -1u'
.br
.ft \n(g3
.ps \n(g4
.GE
.ce
\fBFigure \n+(FG:\fR Virtual Circuit State Diagram
.)z

18
share/doc/iso/wisc/figs/func_units.grn Normal file
View File

@ -0,0 +1,18 @@
.(z L
.GS C
width 6.0
high 7.0
1 8
2 10
3 12
4 14
sc 0.3
narrow 1
medium 3
thick 7
pointscale off
file func_units.gsrc
.GE
.ce
\fBFigure \n+(FG:\fR The major functional units of Unix 4.2A
.)z

603
share/doc/iso/wisc/figs/func_units.gsrc Normal file
View File

@ -0,0 +1,603 @@
gremlinfile
0 80.00 208.00
0
80.00 580.00
80.00 596.00
80.00 596.00
80.00 596.00
-1.00 -1.00
2 3
6 kernel
0
80.00 628.00
80.00 644.00
80.00 644.00
80.00 644.00
-1.00 -1.00
2 3
4 user
3
144.00 212.00
141.00 217.00
144.00 215.00
147.00 217.00
144.00 212.00
-1.00 -1.00
6 0
0
3
184.00 340.00
189.66 338.59
186.12 337.88
185.41 334.34
184.00 340.00
-1.00 -1.00
6 0
0
3
264.00 284.00
258.34 285.41
261.88 286.12
262.59 289.66
264.00 284.00
-1.00 -1.00
6 0
0
3
320.00 324.00
317.00 329.00
320.00 327.00
323.00 329.00
320.00 324.00
-1.00 -1.00
6 0
0
3
312.00 356.00
315.00 351.00
312.00 353.00
309.00 351.00
312.00 356.00
-1.00 -1.00
6 0
0
3
536.00 548.00
540.43 544.21
536.95 545.15
534.74 542.31
536.00 548.00
-1.00 -1.00
6 0
0
3
576.00 388.00
573.00 393.00
576.00 391.00
579.00 393.00
576.00 388.00
-1.00 -1.00
6 0
0
3
544.00 380.00
538.34 381.41
541.88 382.12
542.59 385.66
544.00 380.00
-1.00 -1.00
6 0
0
3
544.00 380.00
541.00 385.00
544.00 383.00
547.00 385.00
544.00 380.00
-1.00 -1.00
6 0
0
3
560.00 292.00
563.00 287.00
560.00 289.00
557.00 287.00
560.00 292.00
-1.00 -1.00
6 0
0
3
488.00 156.00
487.55 161.81
489.34 158.68
492.92 159.13
488.00 156.00
-1.00 -1.00
6 0
0
3
456.00 164.00
453.00 169.00
456.00 167.00
459.00 169.00
456.00 164.00
-1.00 -1.00
6 0
0
3
384.00 308.00
385.41 313.66
386.12 310.12
389.66 309.41
384.00 308.00
-1.00 -1.00
6 0
0
3
360.00 420.00
365.00 423.00
363.00 420.00
365.00 417.00
360.00 420.00
-1.00 -1.00
6 0
0
3
344.00 444.00
345.41 449.66
346.12 446.12
349.66 445.41
344.00 444.00
-1.00 -1.00
6 0
0
3
456.00 556.00
456.45 550.19
454.66 553.32
451.08 552.87
456.00 556.00
-1.00 -1.00
6 0
0
3
272.00 436.00
266.34 437.41
269.88 438.12
270.59 441.66
272.00 436.00
-1.00 -1.00
6 0
0
3
184.00 404.00
185.41 409.66
186.12 406.12
189.66 405.41
184.00 404.00
-1.00 -1.00
6 0
0
3
432.00 652.00
427.00 649.00
429.00 652.00
427.00 655.00
432.00 652.00
-1.00 -1.00
6 0
0
3
352.00 676.00
357.81 676.45
354.68 674.66
355.13 671.08
352.00 676.00
-1.00 -1.00
6 0
0
3
200.00 500.00
205.66 498.59
202.12 497.88
201.41 494.34
200.00 500.00
-1.00 -1.00
6 0
0
3
208.00 548.00
213.00 551.00
211.00 548.00
213.00 545.00
208.00 548.00
-1.00 -1.00
6 0
0
3
192.00 572.00
193.41 577.66
194.12 574.12
197.66 573.41
192.00 572.00
-1.00 -1.00
6 0
0
3
272.00 660.00
272.45 654.19
270.66 657.32
267.08 656.87
272.00 660.00
-1.00 -1.00
6 0
0
3
456.00 556.00
344.00 444.00
-1.00 -1.00
6 0
0
3
544.00 380.00
520.00 412.00
-1.00 -1.00
6 0
0
3
576.00 388.00
536.00 548.00
-1.00 -1.00
6 0
0
3
560.00 292.00
488.00 156.00
-1.00 -1.00
6 0
0
3
424.00 612.00
568.00 612.00
-1.00 -1.00
2 0
0
0
424.00 68.00
424.00 84.00
424.00 84.00
424.00 84.00
-1.00 -1.00
3 3
7 drivers
0
424.00 92.00
424.00 108.00
424.00 108.00
424.00 108.00
-1.00 -1.00
3 3
9 interface
3
480.00 404.00
456.00 164.00
-1.00 -1.00
6 0
0
3
464.00 412.00
384.00 308.00
-1.00 -1.00
6 0
0
3
448.00 436.00
360.00 420.00
-1.00 -1.00
6 0
0
3
312.00 356.00
320.00 324.00
-1.00 -1.00
6 0
0
3
200.00 500.00
272.00 436.00
-1.00 -1.00
6 0
0
3
184.00 340.00
264.00 284.00
-1.00 -1.00
6 0
0
3
144.00 324.00
144.00 212.00
-1.00 -1.00
6 0
0
3
440.00 564.00
176.00 404.00
-1.00 -1.00
6 0
0
3
424.00 588.00
208.00 548.00
-1.00 -1.00
6 0
0
3
352.00 676.00
432.00 652.00
-1.00 -1.00
6 0
0
3
272.00 660.00
192.00 572.00
-1.00 -1.00
6 0
0
0
120.00 132.00
120.00 148.00
120.00 148.00
120.00 148.00
-1.00 -1.00
3 3
7 drivers
0
120.00 156.00
120.00 172.00
120.00 172.00
120.00 172.00
-1.00 -1.00
3 3
6 device
0
120.00 180.00
120.00 196.00
120.00 196.00
120.00 196.00
-1.00 -1.00
3 3
7 blocked
0
424.00 116.00
424.00 132.00
424.00 132.00
424.00 132.00
-1.00 -1.00
3 3
8 network
0
560.00 332.00
560.00 348.00
560.00 348.00
560.00 348.00
-1.00 -1.00
3 3
3 IPC
0
304.00 212.00
304.00 228.00
304.00 228.00
304.00 228.00
-1.00 -1.00
3 3
7 support
0
304.00 236.00
304.00 252.00
304.00 252.00
304.00 252.00
-1.00 -1.00
3 3
6 memory
0
304.00 260.00
304.00 276.00
304.00 276.00
304.00 276.00
-1.00 -1.00
3 3
7 virtual
0
128.00 356.00
128.00 372.00
128.00 372.00
128.00 372.00
-1.00 -1.00
3 3
6 system
0
128.00 380.00
128.00 396.00
128.00 396.00
128.00 396.00
-1.00 -1.00
3 3
4 file
0
480.00 452.00
480.00 468.00
480.00 468.00
480.00 468.00
-1.00 -1.00
3 3
5 clock
0
288.00 380.00
288.00 396.00
288.00 396.00
288.00 396.00
-1.00 -1.00
3 3
7 support
0
288.00 404.00
288.00 420.00
288.00 420.00
288.00 420.00
-1.00 -1.00
3 3
7 process
0
448.00 572.00
448.00 588.00
448.00 588.00
448.00 588.00
-1.00 -1.00
3 3
12 system calls
0
456.00 628.00
456.00 644.00
456.00 644.00
456.00 644.00
-1.00 -1.00
3 3
9 C library
0
288.00 692.00
288.00 708.00
288.00 708.00
288.00 708.00
-1.00 -1.00
3 3
4 user
0
272.00 676.00
272.00 692.00
272.00 692.00
272.00 692.00
-1.00 -1.00
3 3
7 program
0
144.00 516.00
144.00 532.00
144.00 532.00
144.00 532.00
-1.00 -1.00
3 3
3 tty
3
568.00 612.00
640.00 612.00
-1.00 -1.00
6 0
0
3
424.00 612.00
64.00 612.00
-1.00 -1.00
6 0
0
4
496.00 612.00
496.00 684.00
496.00 540.00
496.00 684.00
568.00 612.00
424.00 612.00
-1.00 -1.00
6 0
0
4
456.00 100.00
456.00 164.00
456.00 36.00
456.00 164.00
520.00 100.00
392.00 100.00
-1.00 -1.00
6 0
0
4
336.00 244.00
336.00 324.00
336.00 164.00
336.00 324.00
416.00 244.00
256.00 244.00
-1.00 -1.00
6 0
0
4
144.00 164.00
144.00 212.00
144.00 116.00
144.00 212.00
192.00 164.00
96.00 164.00
-1.00 -1.00
6 0
0
4
144.00 372.00
144.00 420.00
144.00 324.00
144.00 420.00
192.00 372.00
96.00 372.00
-1.00 -1.00
6 0
0
4
576.00 340.00
576.00 388.00
576.00 292.00
576.00 388.00
624.00 340.00
528.00 340.00
-1.00 -1.00
6 0
0
4
496.00 452.00
496.00 500.00
496.00 404.00
496.00 500.00
544.00 452.00
448.00 452.00
-1.00 -1.00
6 0
0
4
312.00 404.00
312.00 452.00
312.00 356.00
312.00 452.00
360.00 404.00
264.00 404.00
-1.00 -1.00
6 0
0
4
160.00 532.00
160.00 580.00
160.00 484.00
160.00 580.00
208.00 532.00
112.00 532.00
-1.00 -1.00
6 0
0
4
304.00 692.00
304.00 740.00
304.00 644.00
304.00 740.00
352.00 692.00
256.00 692.00
-1.00 -1.00
6 0
0
-1

0
share/doc/iso/wisc/figs/func_units.nr Normal file
View File

77
share/doc/iso/wisc/figs/link_to_CONS_primitives.NR.DONT_REMOVE Normal file
View File

@ -0,0 +1,77 @@
.(b
.TS
tab(+) center expand box;
c c
a | a .
service primitive & arguments+provided by
=
N_CONNECT.request+cons_openvc(... faddr, ...)
called address+argument faddr
calling address+not implemented
receipt confirmation+not implemented
expedited data+not implemented
quality of service+not implemented
NS-user data+not implemented
_
N_CONNECT.indication+not implemented
_
N_CONNECT.response+cons_netcmd( CONN_REFUSE )
+ or cons_netcmd( CONN_CONFIRM )
+ however, net connection has already
+ been accepted. If REFUSE, it will
+ be cleared with E_CO_HLI_REJT
+ (higher layer rejects connection)
responding address+not implemented
receipt confirmation+not implemented
expedited data+not implemented
quality of service+not implemented
NS-user data+not implemented
_
N_CONNECT.confirm+not implemented
=
N_DATA.request+cons_output(... m, ...)
+and cosns_output(... m, ...)
confirmation+not implemented
data+mbuf chain m
_
N_DATA.indication+pr_input( m, ... )
+or software interrupt
confirmation+not implemented
data+mbuf chain
_
N_DATA_ACKNOWLEDGE.request+not implemented
_
N_DATA_ACKNOWLEDGE.indication+not implemented
_
N_EXPEDITED_DATA.request+not implemented
_
N_EXPEDITED_DATA.indication+not implemented
=
N_RESET.request+not implemented
N_RESET.indication+socket->so_error = reason
+or pr_ctlinput( PRC_ROUTEDEAD )
originator+not implemented
reason+from X.25 packet or ecn driver
N_RESET.response+not implemented
N_RESET.confirm+not implemented
=
N_DISCONNECT.request+cons_netcmd( CONN_CLOSE )
reason+uses E_CO_HLI_DISCN (normal
+disconnect from higher layer)
responding address+not implemented
NS_user data+not implemented
_
N_DISCONNECT.indication+socket->so_error = reason
+or pr_ctlinput( PRC_ROUTEDEAD )
originator+not implemented
reason+from X.25 packet or ecn driver
responding address+not implemented
NS_user data+not implemented
.TE
.(c
\fBFigure \n+(FG\fR: Transport Service Primitives
.)c
.)b
.(f
\** data on disconnect is not supported at this time.
.)f

60
share/doc/iso/wisc/figs/link_to_TS_primitives.NR.DONT_REMOVE Normal file
View File

@ -0,0 +1,60 @@
.(b
.TS
center expand box;
c c
a | a .
service primitive & arguments Unix system calls & arguments
=
T_CONNECT.request \fIsocket(), connect(), setsockopt()\fR
called address \fIconnect()\fR argument
calling address \fIconnect()\fR argument
quality of service not implemented
buffer management \fIsetsockopt()\fR argument
security not implemented
data \fIsetsockopt(), getsockopt()\fR
_
T_CONNECT.indication return from \fIaccept(); getsockopt()\fR
called address \fIaccept()\fR argument
calling address \fIaccept()\fR argument
quality of service not implemented
security not implemented
data \fIsetsockopt(), getsockopt()\fR
_
T_CONNECT.response no applicable system calls
_
T_CONNECT.confirm return from \fIconnect()\fR
quality of service \fIgetsockopt()\fR argument
data \fIsetsocktopt, getsockopt()\fR
=
T_DATA.request \fIrecvv(), sendv()\fR
_
T_DATA.indication return from \fIrecvv()\fR, \fIsendv()\fR, or \fIselect()\fR;
or signal SIGIO
ioctl(FIONREAD) tells how much has been
queued to read
=
T_EXPEDITED_DATA.request \fIsendv()\fR with MSG_OOB flag
_
T_EXPEDITED_DATA.indication SIGURG, \fIgetsockopt()\fR with TPFLAG_XPD,
return from \fIselect()\fR with exceptional
conditions mask
=
T_DISCONNECT.request \fIclose()\fR
data \fIsetsockopt()\fR
_
T_DISCONNECT.indication SIGURG,
error return on other primitives
reason errno
data \fIgetsockopt()\**\fR
=
T_STATUS.request \fIgetsockopt()\fR, \fItpstat\fR utility program
_
T_STATUS.indication \fIgetsockopt()\fR, \fIselect()\fR, \fItpstat\fR
.TE
.(c
\fBFigure \n+(FG\fR: Transport Service Primitives
.)c
.)b
.(f
\** data on disconnect is not supported at this time.
.)f

13
share/doc/iso/wisc/figs/mbufrcv.grn Normal file
View File

@ -0,0 +1,13 @@
.(z
.GS C
width 5.0
high 6.0
narrow 1
medium 3
thick 7
pointscale on
file mbufrcv.gsrc
.GE
.ce
\fB Figure \n+(FG\fR: \fImbuf\fR chains on socket receive buffer
.)z

1006
share/doc/iso/wisc/figs/mbufrcv.gsrc Normal file
View File

File diff suppressed because it is too large Load Diff

504
share/doc/iso/wisc/figs/mbufrcv.nr Normal file
View File

@ -0,0 +1,504 @@
.(z
.br
.nr g1 2880u
.nr g2 3250u
.GS C
.nr g3 \n(.f
.nr g4 \n(.s
\0
.sp -1
\D't 1u'
.sp -1
.sp 557u
\h'186u'\D'l -29u 18u'\D'l 12u -18u'\D'l -12u -17u'\D'l 29u 17u'
.sp -1
\D'l 186u 0u'
.sp -1
.sp -464u
\D'l 0u 464u'
.sp -1
\h'93u'\D'l -93u 0u'
.sp -1
.sp -93u
\h'93u'\D'l 0u 186u'\D'l 651u 0u'\D'l 0u -186u'\D'l -651u 0u'
.sp -1
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "so->so_rcv.sb_mb
.sp 93u
\h'186u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "last TSDU
.sp 371u
\h'1673u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "second TSDU
.sp 371u
\h'929u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "first TSDU
.sp 371u
\h'186u'\&\*(g9
.sp |\n(g8u
\D's 4u'
.sp -1
.sp 2879u
\h'1998u'\D'l 0u 93u'
.sp -1
\h'1951u'\D'l 0u 93u'
.sp -1
\h'1905u'\D'l 0u 93u'
.sp -1
\h'1812u'\D'l 0u 93u'
.sp -1
\h'1858u'\D'l 0u 93u'
.sp -1
\h'1765u'\D'l 0u 93u'
.sp -1
\h'1719u'\D'l 0u 93u'
.sp -1
.sp -1115u
\h'1998u'\D'l 0u 279u'
.sp -1
\h'1951u'\D'l 0u 279u'
.sp -1
\h'1905u'\D'l 0u 279u'
.sp -1
\h'1858u'\D'l 0u 279u'
.sp -1
\h'1812u'\D'l 0u 279u'
.sp -1
\h'1719u'\D'l 0u 279u'
.sp -1
\h'1765u'\D'l 0u 279u'
.sp -1
.sp -882u
\h'1998u'\D'l 0u 140u'
.sp -1
\h'1951u'\D'l 0u 140u'
.sp -1
\h'1905u'\D'l 0u 140u'
.sp -1
\h'1858u'\D'l 0u 140u'
.sp -1
\h'1812u'\D'l 0u 140u'
.sp -1
\h'1719u'\D'l 0u 140u'
.sp -1
\h'1765u'\D'l 0u 140u'
.sp -1
.sp 882u
\h'511u'\D'l 0u 139u'
.sp -1
\h'465u'\D'l 0u 139u'
.sp -1
\h'418u'\D'l 0u 139u'
.sp -1
\h'372u'\D'l 0u 139u'
.sp -1
\h'325u'\D'l 0u 139u'
.sp -1
\h'233u'\D'l 0u 139u'
.sp -1
\h'279u'\D'l 0u 139u'
.sp -1
.sp -1021u
\h'511u'\D'l 0u 279u'
.sp -1
\h'465u'\D'l 0u 279u'
.sp -1
\h'418u'\D'l 0u 279u'
.sp -1
\h'372u'\D'l 0u 279u'
.sp -1
\h'325u'\D'l 0u 279u'
.sp -1
\h'233u'\D'l 0u 279u'
.sp -1
\h'279u'\D'l 0u 279u'
.sp -1
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "MT_EOT
.sp 6u
\h'2404u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "MT_EOT
.sp -6u
\h'1016u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "MT_EOT
.sp 1015u
\h'244u'\&\*(g9
.sp |\n(g8u
\D's -1u'
.sp -1
.sp -279u
\h'186u'\D'l 0u 743u'\D'l 372u 0u'\D'l 0u -743u'\D'l -372u 0u'
.sp -1
.sp 186u
\h'186u'\D'l 372u 0u'
.sp -1
.sp 372u
\h'186u'\D'l 0u 0u'\D'l 372u 0u'\D'l 0u 0u'\D'l -372u 0u'
.sp -1
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "m_next
.sp 93u
\h'279u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "m_act
.sp -465u
\h'279u'\&\*(g9
.sp |\n(g8u
.sp -279u
\h'186u'\D'l 0u 0u'\D'l 372u 0u'\D'l 0u 0u'\D'l -372u 0u'
.sp -1
.sp 742u
\h'186u'\D'l 0u 744u'\D'l 372u 0u'\D'l 0u -744u'\D'l -372u 0u'
.sp -1
.sp 186u
\h'186u'\D'l 372u 0u'
.sp -1
.sp 372u
\h'186u'\D'l 0u 0u'\D'l 372u 0u'\D'l 0u 0u'\D'l -372u 0u'
.sp -1
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "m_next
.sp 93u
\h'279u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "m_act
.sp -465u
\h'279u'\&\*(g9
.sp |\n(g8u
.sp -279u
\h'186u'\D'l 0u 0u'\D'l 372u 0u'\D'l 0u 0u'\D'l -372u 0u'
.sp -1
.sp -1021u
\h'929u'\D'l 0u 0u'\D'l 372u 0u'\D'l 0u 0u'\D'l -372u 0u'
.sp -1
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "m_act
.sp -186u
\h'1022u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "m_next
.sp 372u
\h'1022u'\&\*(g9
.sp |\n(g8u
.sp 279u
\h'929u'\D'l 0u 0u'\D'l 372u 0u'\D'l 0u 0u'\D'l -372u 0u'
.sp -1
.sp -372u
\h'929u'\D'l 372u 0u'
.sp -1
.sp -186u
\h'929u'\D'l 0u 743u'\D'l 372u 0u'\D'l 0u -743u'\D'l -372u 0u'
.sp -1
\h'1673u'\D'l 0u 743u'\D'l 371u 0u'\D'l 0u -743u'\D'l -371u 0u'
.sp -1
.sp 186u
\h'1673u'\D'l 371u 0u'
.sp -1
.sp 372u
\h'1673u'\D'l 0u 0u'\D'l 371u 0u'\D'l 0u 0u'\D'l -371u 0u'
.sp -1
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "m_next
.sp 93u
\h'1765u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "m_act
.sp -465u
\h'1765u'\&\*(g9
.sp |\n(g8u
.sp -279u
\h'1673u'\D'l 0u 0u'\D'l 371u 0u'\D'l 0u 0u'\D'l -371u 0u'
.sp -1
.sp 1021u
\h'1673u'\D'l 0u 0u'\D'l 371u 0u'\D'l 0u 0u'\D'l -371u 0u'
.sp -1
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "m_act
.sp -186u
\h'1765u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "m_next
.sp 372u
\h'1765u'\&\*(g9
.sp |\n(g8u
.sp 279u
\h'1673u'\D'l 0u 0u'\D'l 371u 0u'\D'l 0u 0u'\D'l -371u 0u'
.sp -1
.sp -372u
\h'1673u'\D'l 371u 0u'
.sp -1
.sp -186u
\h'1673u'\D'l 0u 744u'\D'l 371u 0u'\D'l 0u -744u'\D'l -371u 0u'
.sp -1
.sp 1022u
\h'1673u'\D'l 0u 743u'\D'l 371u 0u'\D'l 0u -743u'\D'l -371u 0u'
.sp -1
.sp 186u
\h'1673u'\D'l 371u 0u'
.sp -1
.sp 372u
\h'1673u'\D'l 0u 0u'\D'l 371u 0u'\D'l 0u 0u'\D'l -371u 0u'
.sp -1
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "m_next
.sp 93u
\h'1765u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "m_act
.sp -465u
\h'1765u'\&\*(g9
.sp |\n(g8u
.sp -279u
\h'1673u'\D'l 0u 0u'\D'l 371u 0u'\D'l 0u 0u'\D'l -371u 0u'
.sp -1
.sp -2043u
\h'2323u'\D'l 0u 0u'\D'l 372u 0u'\D'l 0u 0u'\D'l -372u 0u'
.sp -1
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "m_act
.sp -186u
\h'2416u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "m_next
.sp 372u
\h'2416u'\&\*(g9
.sp |\n(g8u
.sp 279u
\h'2323u'\D'l 0u 0u'\D'l 372u 0u'\D'l 0u 0u'\D'l -372u 0u'
.sp -1
.sp -372u
\h'2323u'\D'l 372u 0u'
.sp -1
.sp -186u
\h'2323u'\D'l 0u 743u'\D'l 372u 0u'\D'l 0u -743u'\D'l -372u 0u'
.sp -1
.sp 93u
\h'558u'\D'l 371u 0u'
.sp -1
\h'1301u'\D'l 372u 0u'
.sp -1
\h'929u'\D'l -29u 18u'\D'l 12u -18u'\D'l -12u -17u'\D'l 29u 17u'
.sp -1
\h'1673u'\D'l -29u 18u'\D'l 11u -18u'\D'l -11u -17u'\D'l 29u 17u'
.sp -1
\h'2044u'\D'l 279u 0u'
.sp -1
\h'2323u'\D'l -29u 18u'\D'l 11u -18u'\D'l -11u -17u'\D'l 29u 17u'
.sp -1
.sp 558u
\h'558u'\D'l 186u 0u'
.sp -1
\h'2044u'\D'l 186u 0u'
.sp -1
\h'744u'\D'l 0u 277u'
.sp -1
.sp 277u
\h'744u'\D'l -372u 0u'
.sp -1
\h'372u'\D'l 0u 93u'
.sp -1
.sp 93u
\h'372u'\D'l -17u -29u'\D'l 17u 12u'\D'l 17u -12u'\D'l -17u 29u'
.sp -1
.sp -370u
\h'2230u'\D'l 0u 277u'
.sp -1
.sp 277u
\h'2230u'\D'l -372u 0u'
.sp -1
\h'1858u'\D'l 0u 93u'
.sp -1
.sp 93u
\h'1858u'\D'l -17u -29u'\D'l 17u 12u'\D'l 18u -12u'\D'l -18u 29u'
.sp -1
.sp 651u
\h'2044u'\D'l 186u 0u'
.sp -1
\h'2230u'\D'l 0u 278u'
.sp -1
.sp 278u
\h'2230u'\D'l -372u 0u'
.sp -1
\h'1858u'\D'l 0u 93u'
.sp -1
.sp 93u
\h'1858u'\D'l -17u -29u'\D'l 17u 12u'\D'l 18u -12u'\D'l -18u 29u'
.sp -1
.sp -1950u
\h'2695u'\D'l 92u 0u'
.sp -1
.sp -93u
\h'2787u'\D'l 0u 186u'
.sp -1
\h'2880u'\D'l 0u 186u'
.sp -1
.sp 558u
\h'1487u'\D'l 0u 185u'
.sp -1
\h'1580u'\D'l 0u 185u'
.sp -1
.sp 2136u
\h'2044u'\D'l 186u 0u'
.sp -1
.sp -93u
\h'2230u'\D'l 0u 185u'
.sp -1
\h'2323u'\D'l 0u 185u'
.sp -1
.sp -1858u
\h'1487u'\D'l 93u -185u'
.sp -1
.sp -557u
\h'2787u'\D'l 93u -186u'
.sp -1
.sp 2600u
\h'2230u'\D'l 93u -185u'
.sp -1
.sp -1114u
\h'558u'\D'l 186u 0u'
.sp -1
.sp -93u
\h'744u'\D'l 0u 186u'
.sp -1
\h'836u'\D'l 0u 186u'
.sp -1
.sp 186u
\h'744u'\D'l 92u -186u'
.sp -1
.sp -1114u
\h'2695u'\D'l 92u 0u'
.sp -1
.sp -93u
\h'2787u'\D'l 0u 185u'\D'l 93u -185u'\D'l 0u 185u'
.sp -1
.sp 93u
\h'1301u'\D'l 186u 0u'
.sp -1
.sp 556u
\h'744u'\D'l 92u -186u'
.sp -1
.sp -186u
\h'836u'\D'l 0u 186u'
.sp -1
\h'744u'\D'l 0u 186u'
.sp -1
.sp 93u
\h'558u'\D'l 186u 0u'
.sp -1
\h'2044u'\D'l 186u 0u'
.sp -1
.sp -93u
\h'2230u'\D'l 0u 186u'
.sp -1
\h'2323u'\D'l 0u 186u'
.sp -1
.sp 186u
\h'2230u'\D'l 93u -186u'
.sp -1
.sp 1022u
\h'2230u'\D'l 93u -186u'
.sp -1
.sp -186u
\h'2323u'\D'l 0u 186u'
.sp -1
\h'2230u'\D'l 0u 186u'
.sp -1
.sp 93u
\h'2044u'\D'l 186u 0u'
.sp -1
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "MT_DATA
.sp -1857u
\h'233u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "MT_DATA
.sp -1857u
\h'1719u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "MT_DATA
.sp -836u
\h'1719u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 5
.nr g8 \n(.d
.ds g9 "MT_DATA
.sp 186u
\h'1719u'\&\*(g9
.sp |\n(g8u
.sp 650u
\D't 3u'\D's -1u'
.br
.ft \n(g3
.ps \n(g4
.GE
.ce
\fB Figure \n+(FG\fR: \fImbuf\fR chains on socket receive buffer
.)z

13
share/doc/iso/wisc/figs/mbufsnd.grn Normal file
View File

@ -0,0 +1,13 @@
.(z
.GS C
width 5.0
high 6.0
narrow 1
medium 3
thick 7
pointscale on
file mbufsnd.gsrc
.GE
.ce
\fB Figure \n+(FG\fR: \fImbuf\fR chains on socket send buffer
.)z

534
share/doc/iso/wisc/figs/mbufsnd.gsrc Normal file
View File

@ -0,0 +1,534 @@
gremlinfile
0 124.00 410.00
0
124.00 310.00
124.00 320.00
124.00 320.00
124.00 320.00
-1.00 -1.00
1 1
12 == user data
3
71.00 343.00
71.00 295.00
-1.00 -1.00
1 0
0
3
79.00 343.00
79.00 295.00
-1.00 -1.00
1 0
0
3
87.00 343.00
87.00 295.00
-1.00 -1.00
1 0
0
3
95.00 343.00
95.00 295.00
-1.00 -1.00
1 0
0
3
103.00 343.00
103.00 295.00
-1.00 -1.00
1 0
0
3
111.00 343.00
111.00 295.00
-1.00 -1.00
1 0
0
3
119.00 343.00
119.00 295.00
-1.00 -1.00
1 0
0
3
160.00 688.00
256.00 688.00
160.00 688.00
256.00 688.00
-1.00 -1.00
5 0
0
3
320.00 512.00
352.00 512.00
-1.00 -1.00
5 0
0
3
352.00 528.00
352.00 496.00
368.00 528.00
368.00 496.00
-1.00 -1.00
5 0
0
0
264.00 656.00
264.00 666.00
264.00 666.00
264.00 666.00
-1.00 -1.00
1 1
7 MT_DATA
3
256.00 480.00
320.00 480.00
-1.00 -1.00
5 0
0
0
272.00 480.00
272.00 490.00
272.00 490.00
272.00 490.00
-1.00 -1.00
1 1
6 MT_XPD
3
312.00 304.00
312.00 256.00
-1.00 -1.00
1 0
0
3
304.00 304.00
304.00 256.00
-1.00 -1.00
1 0
0
3
296.00 304.00
296.00 256.00
-1.00 -1.00
1 0
0
3
288.00 304.00
288.00 256.00
-1.00 -1.00
1 0
0
3
280.00 304.00
280.00 256.00
-1.00 -1.00
1 0
0
3
264.00 304.00
264.00 256.00
-1.00 -1.00
1 0
0
3
272.00 304.00
272.00 256.00
-1.00 -1.00
1 0
0
3
256.00 304.00
256.00 304.00
320.00 304.00
320.00 304.00
256.00 304.00
-1.00 -1.00
5 0
0
3
256.00 256.00
256.00 256.00
320.00 256.00
320.00 256.00
256.00 256.00
-1.00 -1.00
5 0
0
3
288.00 352.00
285.00 357.00
288.00 355.00
291.00 357.00
288.00 352.00
-1.00 -1.00
5 0
0
3
320.00 416.00
352.00 416.00
-1.00 -1.00
5 0
0
3
352.00 416.00
352.00 368.00
-1.00 -1.00
5 0
0
3
256.00 352.00
256.00 224.00
320.00 224.00
320.00 352.00
256.00 352.00
-1.00 -1.00
5 0
0
3
352.00 368.00
288.00 368.00
-1.00 -1.00
5 0
0
3
288.00 368.00
288.00 352.00
-1.00 -1.00
5 0
0
3
352.00 704.00
352.00 672.00
368.00 704.00
368.00 672.00
-1.00 -1.00
5 0
0
3
320.00 688.00
352.00 688.00
-1.00 -1.00
5 0
0
0
64.00 688.00
64.00 698.00
64.00 698.00
64.00 698.00
-1.00 -1.00
1 1
16 so->so_snd.sb_mb
3
256.00 688.00
251.00 685.00
253.00 688.00
251.00 691.00
256.00 688.00
-1.00 -1.00
5 0
0
3
48.00 704.00
48.00 672.00
160.00 672.00
160.00 704.00
48.00 704.00
-1.00 -1.00
5 0
0
3
312.00 656.00
312.00 608.00
-1.00 -1.00
1 0
0
3
304.00 656.00
304.00 608.00
-1.00 -1.00
1 0
0
3
296.00 656.00
296.00 608.00
-1.00 -1.00
1 0
0
3
288.00 656.00
288.00 608.00
-1.00 -1.00
1 0
0
3
280.00 656.00
280.00 608.00
-1.00 -1.00
1 0
0
3
264.00 656.00
264.00 608.00
-1.00 -1.00
1 0
0
3
272.00 656.00
272.00 608.00
-1.00 -1.00
1 0
0
0
271.00 305.00
271.00 315.00
271.00 315.00
271.00 315.00
-1.00 -1.00
1 1
6 MT_EOT
3
256.00 704.00
256.00 576.00
320.00 576.00
320.00 704.00
256.00 704.00
-1.00 -1.00
5 0
0
3
256.00 672.00
320.00 672.00
-1.00 -1.00
5 0
0
3
256.00 608.00
256.00 608.00
320.00 608.00
320.00 608.00
256.00 608.00
-1.00 -1.00
5 0
0
0
272.00 592.00
272.00 602.00
272.00 602.00
272.00 602.00
-1.00 -1.00
1 1
6 m_next
0
272.00 688.00
272.00 698.00
272.00 698.00
272.00 698.00
-1.00 -1.00
1 1
5 m_act
3
256.00 656.00
256.00 656.00
320.00 656.00
320.00 656.00
256.00 656.00
-1.00 -1.00
5 0
0
3
256.00 528.00
256.00 400.00
320.00 400.00
320.00 528.00
256.00 528.00
-1.00 -1.00
5 0
0
3
256.00 496.00
320.00 496.00
-1.00 -1.00
5 0
0
3
256.00 432.00
256.00 432.00
320.00 432.00
320.00 432.00
256.00 432.00
-1.00 -1.00
5 0
0
0
272.00 416.00
272.00 426.00
272.00 426.00
272.00 426.00
-1.00 -1.00
1 1
6 m_next
0
272.00 512.00
272.00 522.00
272.00 522.00
272.00 522.00
-1.00 -1.00
1 1
5 m_act
3
256.00 304.00
256.00 304.00
320.00 304.00
320.00 304.00
256.00 304.00
-1.00 -1.00
5 0
0
0
272.00 336.00
272.00 346.00
272.00 346.00
272.00 346.00
-1.00 -1.00
1 1
5 m_act
0
272.00 240.00
272.00 250.00
272.00 250.00
272.00 250.00
-1.00 -1.00
1 1
6 m_next
3
256.00 256.00
256.00 256.00
320.00 256.00
320.00 256.00
256.00 256.00
-1.00 -1.00
5 0
0
3
256.00 320.00
320.00 320.00
-1.00 -1.00
5 0
0
3
256.00 352.00
256.00 224.00
320.00 224.00
320.00 352.00
256.00 352.00
-1.00 -1.00
5 0
0
3
320.00 592.00
352.00 592.00
-1.00 -1.00
5 0
0
3
352.00 592.00
352.00 544.00
-1.00 -1.00
5 0
0
3
352.00 544.00
288.00 544.00
-1.00 -1.00
5 0
0
3
288.00 544.00
288.00 528.00
-1.00 -1.00
5 0
0
3
288.00 528.00
285.00 533.00
288.00 531.00
291.00 533.00
288.00 528.00
-1.00 -1.00
5 0
0
3
320.00 240.00
352.00 240.00
-1.00 -1.00
5 0
0
3
352.00 256.00
352.00 224.00
-1.00 -1.00
5 0
0
3
368.00 256.00
368.00 224.00
-1.00 -1.00
5 0
0
3
352.00 224.00
368.00 256.00
-1.00 -1.00
5 0
0
3
288.00 472.00
288.00 464.00
-1.00 -1.00
5 0
0
0
72.00 480.00
72.00 490.00
72.00 490.00
72.00 490.00
-1.00 -1.00
1 1
13 tpcb->tp_Xuna
0
72.00 464.00
72.00 474.00
72.00 474.00
72.00 474.00
-1.00 -1.00
1 1
18 sequence number of
0
72.00 448.00
72.00 458.00
72.00 458.00
72.00 458.00
-1.00 -1.00
1 1
8 XPD TPDU
3
288.00 464.00
208.00 456.00
-1.00 -1.00
5 0
0
3
288.00 472.00
208.00 480.00
208.00 480.00
-1.00 -1.00
5 0
0
3
208.00 488.00
184.00 472.00
208.00 448.00
-1.00 -1.00
5 0
0
-1

284
share/doc/iso/wisc/figs/mbufsnd.nr Normal file
View File

@ -0,0 +1,284 @@
.(z
.br
.nr g1 2304u
.nr g2 3455u
.GS C
.nr g3 \n(.f
.nr g4 \n(.s
\0
.sp -1
\D't 1u'
.sp -1
.sp 1554u
\h'1152u'\D'l -173u 115u'\D'l 173u 173u'
.sp -1
.sp 115u
\h'1728u'\D'l -576u -57u'\D'l 0u 0u'
.sp -1
.sp 58u
\h'1728u'\D'l -576u 57u'
.sp -1
.ft R
.ps 6
.nr g8 \n(.d
.ds g9 "XPD TPDU
.sp 115u
\h'173u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 6
.nr g8 \n(.d
.ds g9 "sequence number of
\h'173u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 6
.nr g8 \n(.d
.ds g9 "tpcb->tp_Xuna
.sp -115u
\h'173u'\&\*(g9
.sp |\n(g8u
.sp -58u
\h'1728u'\D'l 0u 58u'
.sp -1
.sp 1786u
\h'2189u'\D'l 115u -231u'
.sp -1
.sp -231u
\h'2304u'\D'l 0u 231u'
.sp -1
\h'2189u'\D'l 0u 231u'
.sp -1
.sp 116u
\h'1959u'\D'l 230u 0u'
.sp -1
.sp -2073u
\h'1728u'\D'l -21u -36u'\D'l 21u 14u'\D'l 22u -14u'\D'l -22u 36u'
.sp -1
.sp -115u
\h'1728u'\D'l 0u 115u'
.sp -1
\h'2189u'\D'l -461u 0u'
.sp -1
.sp -346u
\h'2189u'\D'l 0u 346u'
.sp -1
\h'1959u'\D'l 230u 0u'
.sp -1
.sp 1727u
\h'1498u'\D'l 0u 922u'\D'l 461u 0u'\D'l 0u -922u'\D'l -461u 0u'
.sp -1
.sp 231u
\h'1498u'\D'l 461u 0u'
.sp -1
.sp 460u
\h'1498u'\D'l 0u 0u'\D'l 461u 0u'\D'l 0u 0u'\D'l -461u 0u'
.sp -1
.ft R
.ps 6
.nr g8 \n(.d
.ds g9 "m_next
.sp 116u
\h'1613u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 6
.nr g8 \n(.d
.ds g9 "m_act
.sp -576u
\h'1613u'\&\*(g9
.sp |\n(g8u
.sp -345u
\h'1498u'\D'l 0u 0u'\D'l 461u 0u'\D'l 0u 0u'\D'l -461u 0u'
.sp -1
.ft R
.ps 6
.nr g8 \n(.d
.ds g9 "m_act
.sp -1497u
\h'1613u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 6
.nr g8 \n(.d
.ds g9 "m_next
.sp -807u
\h'1613u'\&\*(g9
.sp |\n(g8u
.sp -922u
\h'1498u'\D'l 0u 0u'\D'l 461u 0u'\D'l 0u 0u'\D'l -461u 0u'
.sp -1
.sp -461u
\h'1498u'\D'l 461u 0u'
.sp -1
.sp -229u
\h'1498u'\D'l 0u 921u'\D'l 461u 0u'\D'l 0u -921u'\D'l -461u 0u'
.sp -1
.sp -922u
\h'1498u'\D'l 0u 0u'\D'l 461u 0u'\D'l 0u 0u'\D'l -461u 0u'
.sp -1
.ft R
.ps 6
.nr g8 \n(.d
.ds g9 "m_act
.sp -230u
\h'1613u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 6
.nr g8 \n(.d
.ds g9 "m_next
.sp 461u
\h'1613u'\&\*(g9
.sp |\n(g8u
.sp 346u
\h'1498u'\D'l 0u 0u'\D'l 461u 0u'\D'l 0u 0u'\D'l -461u 0u'
.sp -1
.sp -461u
\h'1498u'\D'l 461u 0u'
.sp -1
.sp -230u
\h'1498u'\D'l 0u 922u'\D'l 461u 0u'\D'l 0u -922u'\D'l -461u 0u'
.sp -1
.ft R
.ps 6
.nr g8 \n(.d
.ds g9 "MT_EOT
.sp 2872u
\h'1606u'\&\*(g9
.sp |\n(g8u
\D's 4u'
.sp -1
.sp 345u
\h'1613u'\D'l 0u 346u'
.sp -1
\h'1555u'\D'l 0u 346u'
.sp -1
\h'1670u'\D'l 0u 346u'
.sp -1
\h'1728u'\D'l 0u 346u'
.sp -1
\h'1786u'\D'l 0u 346u'
.sp -1
\h'1843u'\D'l 0u 346u'
.sp -1
\h'1901u'\D'l 0u 346u'
.sp -1
\D's -1u'
.sp -1
.sp -345u
\D'l 0u 230u'\D'l 807u 0u'\D'l 0u -230u'\D'l -807u 0u'
.sp -1
.sp 115u
\h'1498u'\D'l -36u 22u'\D'l 14u -22u'\D'l -14u -21u'\D'l 36u 21u'
.sp -1
.ft R
.ps 6
.nr g8 \n(.d
.ds g9 "so->so_snd.sb_mb
\h'115u'\&\*(g9
.sp |\n(g8u
\h'1959u'\D'l 230u 0u'
.sp -1
.sp -115u
\h'2189u'\D'l 0u 230u'\D'l 115u -230u'\D'l 0u 230u'
.sp -1
.sp 2418u
\h'1728u'\D'l 0u 115u'
.sp -1
\h'2189u'\D'l -461u 0u'
.sp -1
.sp 115u
\h'1498u'\D'l 0u 922u'\D'l 461u 0u'\D'l 0u -922u'\D'l -461u 0u'
.sp -1
.sp -461u
\h'2189u'\D'l 0u 346u'
.sp -1
\h'1959u'\D'l 230u 0u'
.sp -1
.sp 461u
\h'1728u'\D'l -21u -36u'\D'l 21u 15u'\D'l 22u -15u'\D'l -22u 36u'
.sp -1
.sp 691u
\h'1498u'\D'l 0u 0u'\D'l 461u 0u'\D'l 0u 0u'\D'l -461u 0u'
.sp -1
.sp -345u
\h'1498u'\D'l 0u 0u'\D'l 461u 0u'\D'l 0u 0u'\D'l -461u 0u'
.sp -1
\D's 4u'
.sp -1
\h'1613u'\D'l 0u 345u'
.sp -1
\h'1555u'\D'l 0u 345u'
.sp -1
\h'1670u'\D'l 0u 345u'
.sp -1
\h'1728u'\D'l 0u 345u'
.sp -1
\h'1786u'\D'l 0u 345u'
.sp -1
\h'1843u'\D'l 0u 345u'
.sp -1
\h'1901u'\D'l 0u 345u'
.sp -1
.ft R
.ps 6
.nr g8 \n(.d
.ds g9 "MT_XPD
.sp -1267u
\h'1613u'\&\*(g9
.sp |\n(g8u
\D's -1u'
.sp -1
.sp -1267u
\h'1498u'\D'l 461u 0u'
.sp -1
.ft R
.ps 6
.nr g8 \n(.d
.ds g9 "MT_DATA
.sp -1267u
\h'1555u'\&\*(g9
.sp |\n(g8u
.sp -345u
\h'2189u'\D'l 0u 229u'\D'l 115u -229u'\D'l 0u 229u'
.sp -1
.sp 115u
\h'1959u'\D'l 230u 0u'
.sp -1
.sp -1267u
\h'807u'\D'l 691u 0u'\D'l -691u 0u'\D'l 691u 0u'
.sp -1
\D's 4u'
.sp -1
.sp 2483u
\h'511u'\D'l 0u 346u'
.sp -1
\h'454u'\D'l 0u 346u'
.sp -1
\h'396u'\D'l 0u 346u'
.sp -1
\h'338u'\D'l 0u 346u'
.sp -1
\h'281u'\D'l 0u 346u'
.sp -1
\h'223u'\D'l 0u 346u'
.sp -1
\h'166u'\D'l 0u 346u'
.sp -1
.ft R
.ps 6
.nr g8 \n(.d
.ds g9 "== user data
.sp 238u
\h'547u'\&\*(g9
.sp |\n(g8u
.sp 857u
\D't 3u'\D's -1u'
.br
.ft \n(g3
.ps \n(g4
.GE
.ce
\fB Figure \n+(FG\fR: \fImbuf\fR chains on socket send buffer
.)z

18
share/doc/iso/wisc/figs/osi_addr.grn Normal file
View File

@ -0,0 +1,18 @@
.(z
.GS C
width 6.0
high 7.0
1 8
2 10
3 12
4 14
sc 0.4
narrow 1
medium 3
thick 7
pointscale off
file osi_addr.gsrc
.GE
.ce
\fB Figure \n+(FG\fR: Format of OSI addresses
.)z

62
share/doc/iso/wisc/figs/osi_addr.gsrc Normal file
View File

@ -0,0 +1,62 @@
gremlinfile
0 87.01 78.31
3
87.01 641.69
87.01 567.61
349.25 567.61
349.25 641.69
87.01 641.69
-1.00 -1.00
5 0
0
0
138.15 617.43
138.15 636.43
138.15 636.43
138.15 636.43
-1.00 -1.00
1 4
3 IDP
3
212.23 641.69
212.23 567.61
-1.00 -1.00
5 0
0
3
87.01 609.57
212.23 609.57
-1.00 -1.00
5 0
0
0
98.81 585.31
98.81 604.31
98.81 604.31
98.81 604.31
-1.00 -1.00
1 4
3 AFI
3
149.29 610.22
149.29 567.61
-1.00 -1.00
5 0
0
0
170.27 586.62
170.27 605.62
170.27 605.62
170.27 605.62
-1.00 -1.00
1 4
3 IDI
0
271.23 598.42
271.23 617.42
271.23 617.42
271.23 617.42
-1.00 -1.00
1 4
3 DSP
-1

59
share/doc/iso/wisc/figs/osi_addr.nr Normal file
View File

@ -0,0 +1,59 @@
.(z
.br
.nr g1 3456u
.nr g2 1722u
.GS C
.nr g3 \n(.f
.nr g4 \n(.s
\0
.sp -1
.ft R
.ps 14
.nr g8 \n(.d
.ds g9 "DSP
.sp 570u
\h'2428u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 14
.nr g8 \n(.d
.ds g9 "IDI
.sp 726u
\h'1097u'\&\*(g9
.sp |\n(g8u
\D't 1u'
.sp -1
.sp 415u
\h'821u'\D'l 0u 561u'
.sp -1
.ft R
.ps 14
.nr g8 \n(.d
.ds g9 "AFI
.sp 328u
\h'156u'\&\*(g9
.sp |\n(g8u
.sp 8u
\D'l 1650u 0u'
.sp -1
.sp -423u
\h'1650u'\D'l 0u 976u'
.sp -1
.ft R
.ps 14
.nr g8 \n(.d
.ds g9 "IDP
.sp 320u
\h'674u'\&\*(g9
.sp |\n(g8u
\D'l 0u 976u'\D'l 3456u 0u'\D'l 0u -976u'\D'l -3456u 0u'
.sp -1
.sp 1722u
\D't 3u'\D's -1u'
.br
.ft \n(g3
.ps \n(g4
.GE
.ce
\fB Figure \n+(FG\fR: Format of OSI addresses
.)z

18
share/doc/iso/wisc/figs/tppt.grn Normal file
View File

@ -0,0 +1,18 @@
.(z
.GS C
width 6.0
high 7.0
1 8
2 10
3 12
4 14
sc 0.4
narrow 1
medium 3
thick 7
pointscale off
file tppt.gsrc
.GE
.ce
\fB Figure \n+(FG\fR: Output of tppt(8)
.)z

411
share/doc/iso/wisc/figs/tppt.gsrc Normal file
View File

@ -0,0 +1,411 @@
gremlinfile
0 352.00 352.00
0
352.00 368.00
352.00 381.00
352.00 381.00
352.00 381.00
-1.00 -1.00
2 2
17 this is a CR TPDU
3
256.00 384.00
256.00 400.00
368.00 400.00
368.00 384.00
256.00 384.00
-1.00 -1.00
5 0
0
0
112.00 288.00
112.00 302.00
112.00 302.00
112.00 302.00
-1.00 -1.00
1 3
59 +12: 0x02 0x00 0x07 0xc0 20: 0x01 0x08 0x00 0x00
0
112.00 304.00
112.00 318.00
112.00 318.00
112.00 318.00
-1.00 -1.00
1 3
59 + 8: 0x06 0x74 0x70 0x70 12: 0x69 0x6e 0xc7 0xc2
0
112.00 320.00
112.00 334.00
112.00 334.00
112.00 334.00
-1.00 -1.00
1 3
59 + 0: 0x15 0xe0 0x00 0x00 4: 0x00 0x03 0x00 0xc1
0
160.00 208.00
160.00 221.00
160.00 221.00
160.00 221.00
-1.00 -1.00
2 2
17 class and options
3
112.00 208.00
144.00 208.00
-1.00 -1.00
6 0
0
3
336.00 320.00
368.00 320.00
-1.00 -1.00
6 0
0
3
80.00 352.00
75.00 349.00
77.00 352.00
75.00 355.00
80.00 352.00
-1.00 -1.00
5 0
0
3
96.00 288.00
91.00 285.00
93.00 288.00
91.00 291.00
96.00 288.00
-1.00 -1.00
5 0
0
3
96.00 288.00
48.00 288.00
48.00 240.00
96.00 240.00
-1.00 -1.00
5 0
0
0
336.00 432.00
336.00 445.00
336.00 445.00
336.00 445.00
-1.00 -1.00
2 2
22 indicates a TPDU event
0
48.00 448.00
48.00 461.00
48.00 461.00
48.00 461.00
-1.00 -1.00
2 2
18 TPDU was received;
0
128.00 448.00
128.00 461.00
128.00 461.00
128.00 461.00
-1.00 -1.00
2 2
28 its total length is 22 bytes
0
48.00 432.00
48.00 445.00
48.00 445.00
48.00 445.00
-1.00 -1.00
2 2
26 and its header is 22 bytes
0
48.00 416.00
48.00 429.00
48.00 429.00
48.00 429.00
-1.00 -1.00
2 2
15 (21 in the LI +
0
112.00 416.00
112.00 429.00
112.00 429.00
112.00 429.00
-1.00 -1.00
2 2
13 1 for the LI)
3
112.00 240.00
144.00 240.00
-1.00 -1.00
1 0
0
0
160.00 240.00
160.00 253.00
160.00 253.00
160.00 253.00
-1.00 -1.00
2 2
2 LI
3
208.00 320.00
336.00 320.00
-1.00 -1.00
2 0
0
3
112.00 224.00
144.00 224.00
-1.00 -1.00
2 0
0
0
160.00 224.00
160.00 237.00
160.00 237.00
160.00 237.00
-1.00 -1.00
2 2
16 dst-ref, src-ref
3
304.00 240.00
336.00 240.00
-1.00 -1.00
3 0
0
0
352.00 240.00
352.00 253.00
352.00 253.00
352.00 253.00
-1.00 -1.00
2 2
26 calling transport selector
3
144.00 288.00
224.00 288.00
-1.00 -1.00
4 0
0
3
304.00 224.00
336.00 224.00
-1.00 -1.00
4 0
0
0
352.00 224.00
352.00 237.00
352.00 237.00
352.00 237.00
-1.00 -1.00
2 2
25 called transport selector
3
240.00 288.00
336.00 288.00
-1.00 -1.00
5 0
0
3
304.00 208.00
336.00 208.00
-1.00 -1.00
5 0
0
0
352.00 208.00
352.00 221.00
352.00 221.00
352.00 221.00
-1.00 -1.00
2 2
9 TPDU size
3
144.00 320.00
192.00 320.00
-1.00 -1.00
1 0
0
0
176.00 240.00
176.00 253.00
176.00 253.00
176.00 253.00
-1.00 -1.00
2 2
11 , TPDU type
3
400.00 432.00
400.00 400.00
-1.00 -1.00
5 0
0
3
400.00 400.00
397.00 405.00
400.00 403.00
403.00 405.00
400.00 400.00
-1.00 -1.00
5 0
0
3
368.00 400.00
368.00 384.00
432.00 384.00
432.00 400.00
368.00 400.00
-1.00 -1.00
5 0
0
0
384.00 384.00
384.00 398.00
384.00 398.00
384.00 398.00
-1.00 -1.00
1 3
4 tpdu
3
80.00 352.00
48.00 352.00
48.00 400.00
-1.00 -1.00
5 0
0
3
96.00 336.00
96.00 272.00
416.00 272.00
416.00 336.00
96.00 336.00
-1.00 -1.00
5 0
0
3
80.00 368.00
80.00 336.00
224.00 336.00
224.00 368.00
80.00 368.00
-1.00 -1.00
5 0
0
0
96.00 352.00
96.00 366.00
96.00 366.00
96.00 366.00
-1.00 -1.00
1 3
19 INPUT total len 22
0
96.00 336.00
96.00 350.00
96.00 350.00
96.00 350.00
-1.00 -1.00
1 3
13 HDRLEN: 21+1
3
224.00 352.00
224.00 336.00
320.00 336.00
320.00 352.00
224.00 352.00
-1.00 -1.00
5 0
0
0
240.00 336.00
240.00 350.00
240.00 350.00
240.00 350.00
-1.00 -1.00
1 3
12 CR_TPDU_type
0
336.00 336.00
336.00 350.00
336.00 350.00
336.00 350.00
-1.00 -1.00
1 3
23 cdt 0(0x0) dref 0x0
3
288.00 352.00
285.00 357.00
288.00 355.00
291.00 357.00
288.00 352.00
-1.00 -1.00
5 0
0
3
288.00 352.00
288.00 368.00
352.00 368.00
-1.00 -1.00
5 0
0
0
80.00 144.00
80.00 158.00
80.00 158.00
80.00 158.00
-1.00 -1.00
1 3
24 1a: Ref 22 arg 14(0xe)
0
256.00 384.00
256.00 398.00
256.00 398.00
256.00 398.00
-1.00 -1.00
1 3
22 @ 91990 : 0000.435125
3
288.00 400.00
285.00 405.00
288.00 403.00
291.00 405.00
288.00 400.00
-1.00 -1.00
5 0
0
3
288.00 400.00
288.00 416.00
-1.00 -1.00
5 0
0
0
240.00 416.00
240.00 429.00
240.00 429.00
240.00 429.00
-1.00 -1.00
2 2
30 event # : time since 1st event
3
368.00 320.00
384.00 320.00
-1.00 -1.00
3 0
0
3
144.00 304.00
336.00 304.00
-1.00 -1.00
3 0
0
3
336.00 304.00
384.00 304.00
-1.00 -1.00
4 0
0
-1

335
share/doc/iso/wisc/figs/tppt.gsrc.save Normal file
View File

@ -0,0 +1,335 @@
gremlinfile
0 240.00 464.00
0
240.00 256.00
240.00 269.00
240.00 269.00
240.00 269.00
-1.00 -1.00
2 2
11 , TPDU type
3
208.00 320.00
256.00 320.00
-1.00 -1.00
1 0
0
0
224.00 192.00
224.00 205.00
224.00 205.00
224.00 205.00
-1.00 -1.00
2 2
9 TPDU size
3
176.00 192.00
208.00 192.00
-1.00 -1.00
5 0
0
3
304.00 288.00
400.00 288.00
-1.00 -1.00
5 0
0
0
224.00 208.00
224.00 221.00
224.00 221.00
224.00 221.00
-1.00 -1.00
2 2
25 called transport selector
3
176.00 208.00
208.00 208.00
-1.00 -1.00
4 0
0
3
208.00 288.00
288.00 288.00
-1.00 -1.00
4 0
0
3
432.00 304.00
464.00 304.00
-1.00 -1.00
4 0
0
3
160.00 336.00
160.00 272.00
480.00 272.00
480.00 336.00
160.00 336.00
-1.00 -1.00
5 0
0
0
224.00 224.00
224.00 237.00
224.00 237.00
224.00 237.00
-1.00 -1.00
2 2
26 calling transport selector
3
176.00 224.00
208.00 224.00
-1.00 -1.00
3 0
0
3
208.00 304.00
432.00 304.00
-1.00 -1.00
3 0
0
3
432.00 320.00
464.00 320.00
-1.00 -1.00
3 0
0
0
224.00 240.00
224.00 253.00
224.00 253.00
224.00 253.00
-1.00 -1.00
2 2
16 dst-ref, src-ref
3
176.00 240.00
208.00 240.00
-1.00 -1.00
2 0
0
3
272.00 320.00
400.00 320.00
-1.00 -1.00
2 0
0
0
224.00 256.00
224.00 269.00
224.00 269.00
224.00 269.00
-1.00 -1.00
2 2
2 LI
3
176.00 256.00
208.00 256.00
-1.00 -1.00
1 0
0
0
48.00 416.00
48.00 429.00
48.00 429.00
48.00 429.00
-1.00 -1.00
2 2
13 1 for the LI)
0
48.00 432.00
48.00 445.00
48.00 445.00
48.00 445.00
-1.00 -1.00
2 2
15 (21 in the LI +
0
48.00 448.00
48.00 461.00
48.00 461.00
48.00 461.00
-1.00 -1.00
2 2
26 and its header is 22 bytes
0
48.00 464.00
48.00 477.00
48.00 477.00
48.00 477.00
-1.00 -1.00
2 2
28 its total length is 22 bytes
0
48.00 480.00
48.00 493.00
48.00 493.00
48.00 493.00
-1.00 -1.00
2 2
18 TPDU was received;
0
176.00 416.00
176.00 429.00
176.00 429.00
176.00 429.00
-1.00 -1.00
2 2
17 TPDU is a CR TPDU
0
368.00 432.00
368.00 445.00
368.00 445.00
368.00 445.00
-1.00 -1.00
2 2
22 indicates a TPDU event
3
160.00 304.00
112.00 304.00
112.00 256.00
160.00 256.00
-1.00 -1.00
5 0
0
3
160.00 304.00
155.00 301.00
157.00 304.00
155.00 307.00
160.00 304.00
-1.00 -1.00
5 0
0
3
256.00 352.00
256.00 416.00
-1.00 -1.00
5 0
0
3
256.00 352.00
253.00 357.00
256.00 355.00
259.00 357.00
256.00 352.00
-1.00 -1.00
5 0
0
3
80.00 352.00
48.00 352.00
48.00 400.00
-1.00 -1.00
5 0
0
3
80.00 352.00
75.00 349.00
77.00 352.00
75.00 355.00
80.00 352.00
-1.00 -1.00
5 0
0
3
416.00 384.00
416.00 416.00
-1.00 -1.00
5 0
0
3
416.00 384.00
413.00 389.00
416.00 387.00
419.00 389.00
416.00 384.00
-1.00 -1.00
5 0
0
3
192.00 352.00
192.00 336.00
288.00 336.00
288.00 352.00
192.00 352.00
-1.00 -1.00
5 0
0
3
80.00 352.00
80.00 336.00
192.00 336.00
192.00 352.00
80.00 352.00
-1.00 -1.00
5 0
0
3
80.00 368.00
80.00 352.00
208.00 352.00
208.00 368.00
80.00 368.00
-1.00 -1.00
5 0
0
3
400.00 384.00
400.00 368.00
448.00 368.00
448.00 384.00
400.00 384.00
-1.00 -1.00
5 0
0
0
96.00 288.00
96.00 303.00
96.00 303.00
96.00 303.00
-1.00 -1.00
1 2
66 +16: 0x02 0x00 0x07 0xc0 20: 0x01 0x08 0x00 0x00
0
96.00 304.00
96.00 319.00
96.00 319.00
96.00 319.00
-1.00 -1.00
1 2
66 + 8: 0x06 0x74 0x70 0x70 12: 0x69 0x6e 0x67 0xc2
0
96.00 320.00
96.00 335.00
96.00 335.00
96.00 335.00
-1.00 -1.00
1 2
66 + 0: 0x15 0xe0 0x00 0x00 4: 0x00 0x03 0x00 0xc1
0
96.00 336.00
96.00 351.00
96.00 351.00
96.00 351.00
-1.00 -1.00
1 2
56 HDRLEN: 21+1 CR_TPDU_type cdt 0(0x0) dref 0x0
0
96.00 352.00
96.00 367.00
96.00 367.00
96.00 367.00
-1.00 -1.00
1 2
18 INPUT total len 22
0
96.00 368.00
96.00 383.00
96.00 383.00
96.00 383.00
-1.00 -1.00
1 2
60 1a: Ref 22 arg 14(0xe), @ 91990 : 0000.435125 tpdu
-1

296
share/doc/iso/wisc/figs/tppt.nr Normal file
View File

@ -0,0 +1,296 @@
.(z
.br
.nr g1 3456u
.nr g2 2736u
.GS C
.nr g3 \n(.f
.nr g4 \n(.s
\0
.sp -1
\D's 16u'\D't 1u'
.sp -1
.sp 1296u
\h'2592u'\D'l 432u 0u'
.sp -1
\D's -1u'\D't 7u'
.sp -1
\h'864u'\D'l 1728u 0u'
.sp -1
.sp -144u
\h'2880u'\D'l 144u 0u'
.sp -1
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "event # : time since 1st event
.sp -864u
\h'1728u'\&\*(g9
.sp |\n(g8u
\D't 1u'
.sp -1
.sp -720u
\h'2160u'\D'l 0u -144u'
.sp -1
\h'2160u'\D'l -27u -45u'\D'l 27u 18u'\D'l 27u -18u'\D'l -27u 45u'
.sp -1
.ft R
.ps 12
.nr g8 \n(.d
.ds g9 "@ 91990 : 0000.435125
.sp 144u
\h'1872u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 12
.nr g8 \n(.d
.ds g9 "1a: Ref 22 arg 14(0xe)
.sp 2304u
\h'288u'\&\*(g9
.sp |\n(g8u
.sp 432u
\h'2160u'\D'l 0u -144u'\D'l 576u 0u'
.sp -1
\h'2160u'\D'l -27u -45u'\D'l 27u 18u'\D'l 27u -18u'\D'l -27u 45u'
.sp -1
.ft R
.ps 12
.nr g8 \n(.d
.ds g9 "cdt 0(0x0) dref 0x0
.sp 144u
\h'2592u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 12
.nr g8 \n(.d
.ds g9 "CR_TPDU_type
.sp 144u
\h'1728u'\&\*(g9
.sp |\n(g8u
\h'1584u'\D'l 0u 144u'\D'l 864u 0u'\D'l 0u -144u'\D'l -864u 0u'
.sp -1
.ft R
.ps 12
.nr g8 \n(.d
.ds g9 "HDRLEN: 21+1
.sp 144u
\h'432u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 12
.nr g8 \n(.d
.ds g9 "INPUT total len 22
\h'432u'\&\*(g9
.sp |\n(g8u
.sp -144u
\h'288u'\D'l 0u 288u'\D'l 1296u 0u'\D'l 0u -288u'\D'l -1296u 0u'
.sp -1
.sp 288u
\h'432u'\D'l 0u 576u'\D'l 2880u 0u'\D'l 0u -576u'\D'l -2880u 0u'
.sp -1
.sp -144u
\h'288u'\D'l -288u 0u'\D'l 0u -432u'
.sp -1
.ft R
.ps 12
.nr g8 \n(.d
.ds g9 "tpdu
.sp -288u
\h'3024u'\&\*(g9
.sp |\n(g8u
.sp -432u
\h'2880u'\D'l 0u 144u'\D'l 576u 0u'\D'l 0u -144u'\D'l -576u 0u'
.sp -1
\h'3168u'\D'l -27u -45u'\D'l 27u 18u'\D'l 27u -18u'\D'l -27u 45u'
.sp -1
.sp -288u
\h'3168u'\D'l 0u 288u'
.sp -1
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 ", TPDU type
.sp 1728u
\h'1152u'\&\*(g9
.sp |\n(g8u
\D's 4u'
.sp -1
.sp 1008u
\h'864u'\D'l 432u 0u'
.sp -1
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "TPDU size
.sp 1008u
\h'2736u'\&\*(g9
.sp |\n(g8u
\D's -1u'
.sp -1
.sp 1008u
\h'2304u'\D'l 288u 0u'
.sp -1
.sp -720u
\h'1728u'\D'l 864u 0u'
.sp -1
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "called transport selector
.sp 576u
\h'2736u'\&\*(g9
.sp |\n(g8u
\D's 16u'
.sp -1
.sp 576u
\h'2304u'\D'l 288u 0u'
.sp -1
.sp -576u
\h'864u'\D'l 720u 0u'
.sp -1
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "calling transport selector
.sp 432u
\h'2736u'\&\*(g9
.sp |\n(g8u
\D's -1u'\D't 7u'
.sp -1
.sp 432u
\h'2304u'\D'l 288u 0u'
.sp -1
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "dst-ref, src-ref
.sp 144u
\h'1008u'\&\*(g9
.sp |\n(g8u
\D's 20u'\D't 1u'
.sp -1
.sp 144u
\h'576u'\D'l 288u 0u'
.sp -1
.sp -864u
\h'1440u'\D'l 1152u 0u'
.sp -1
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "LI
.sp 720u
\h'1008u'\&\*(g9
.sp |\n(g8u
\D's 4u'
.sp -1
.sp 720u
\h'576u'\D'l 288u 0u'
.sp -1
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "1 for the LI)
.sp -1584u
\h'576u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "(21 in the LI +
.sp -1584u
\&\*(g9
.sp |\n(g8u
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "and its header is 22 bytes
.sp -1728u
\&\*(g9
.sp |\n(g8u
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "its total length is 22 bytes
.sp -1872u
\h'720u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "TPDU was received;
.sp -1872u
\&\*(g9
.sp |\n(g8u
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "indicates a TPDU event
.sp -1728u
\h'2592u'\&\*(g9
.sp |\n(g8u
\D's -1u'
.sp -1
.sp -432u
\h'432u'\D'l -432u 0u'\D'l 0u 432u'\D'l 432u 0u'
.sp -1
\h'432u'\D'l -45u 27u'\D'l 18u -27u'\D'l -18u -27u'\D'l 45u 27u'
.sp -1
.sp -576u
\h'288u'\D'l -45u 27u'\D'l 18u -27u'\D'l -18u -27u'\D'l 45u 27u'
.sp -1
\D't 3u'
.sp -1
.sp 288u
\h'2592u'\D'l 288u 0u'
.sp -1
.sp 1008u
\h'576u'\D'l 288u 0u'
.sp -1
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "class and options
\h'1008u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 12
.nr g8 \n(.d
.ds g9 "+ 0: 0x15 0xe0 0x00 0x00 4: 0x00 0x03 0x00 0xc1
.sp -1008u
\h'576u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 12
.nr g8 \n(.d
.ds g9 "+ 8: 0x06 0x74 0x70 0x70 12: 0x69 0x6e 0xc7 0xc2
.sp -864u
\h'576u'\&\*(g9
.sp |\n(g8u
.ft R
.ps 12
.nr g8 \n(.d
.ds g9 "+12: 0x02 0x00 0x07 0xc0 20: 0x01 0x08 0x00 0x00
.sp -720u
\h'576u'\&\*(g9
.sp |\n(g8u
\D't 1u'
.sp -1
.sp -1584u
\h'1872u'\D'l 0u -144u'\D'l 1008u 0u'\D'l 0u 144u'\D'l -1008u 0u'
.sp -1
.ft I
.ps 10
.nr g8 \n(.d
.ds g9 "this is a CR TPDU
.sp 144u
\h'2736u'\&\*(g9
.sp |\n(g8u
.sp 2160u
\D't 3u'\D's -1u'
.br
.ft \n(g3
.ps \n(g4
.GE
.ce
\fB Figure \n+(FG\fR: Output of tppt(8)
.)z

20
share/doc/iso/wisc/figs/trans_flow.grn Normal file
View File

@ -0,0 +1,20 @@
.(z
.GS C
width 6.0
high 7.0
1 8
2 10
3 12
4 14
sc 0.4
narrow 1
medium 3
thick 7
pointscale off
file trans_flow.gsrc
.GE
.ce
\fB Figure \n+(FG\fR: Control flow (solid) and data flow (broken)
.ce
among the parts of the transport implementation.
.)z

567
share/doc/iso/wisc/figs/trans_flow.gsrc Normal file
View File

@ -0,0 +1,567 @@
gremlinfile
0 448.00 587.00
3
448.00 201.00
450.69 206.18
450.55 202.57
453.83 201.07
448.00 201.00
-1.00 -1.00
6 0
0
3
549.00 260.00
447.00 201.00
-1.00 -1.00
6 0
0
3
582.00 238.00
585.82 233.60
582.52 235.05
579.91 232.55
582.00 238.00
-1.00 -1.00
6 0
0
3
585.00 148.00
583.00 239.00
-1.00 -1.00
6 0
0
3
423.00 376.00
428.82 375.64
425.47 374.30
425.42 370.70
423.00 376.00
-1.00 -1.00
6 0
0
3
542.00 322.00
422.00 375.00
-1.00 -1.00
6 0
0
3
393.00 246.00
389.63 250.76
392.77 248.99
395.61 251.22
393.00 246.00
-1.00 -1.00
6 0
0
3
390.00 364.00
392.00 244.00
-1.00 -1.00
6 0
0
3
476.00 655.00
481.66 653.59
478.12 652.88
477.41 649.34
476.00 655.00
-1.00 -1.00
6 0
0
3
540.00 577.00
476.00 656.00
-1.00 -1.00
6 0
0
3
138.00 209.00
139.96 203.51
137.41 206.06
134.08 204.69
138.00 209.00
-1.00 -1.00
6 0
0
3
137.00 209.00
124.00 149.00
-1.00 -1.00
6 0
0
3
378.00 242.00
375.00 247.00
378.00 245.00
381.00 247.00
378.00 242.00
-1.00 -1.00
1 0
0
3
376.00 364.00
378.00 239.00
-1.00 -1.00
1 0
0
3
441.00 215.00
443.50 220.27
443.50 216.66
446.82 215.28
441.00 215.00
-1.00 -1.00
1 0
0
3
541.00 269.00
438.00 214.00
-1.00 -1.00
1 0
0
3
600.00 240.00
603.25 235.16
600.15 237.00
597.25 234.86
600.00 240.00
-1.00 -1.00
1 0
0
3
599.00 242.00
605.00 148.00
-1.00 -1.00
1 0
0
3
497.00 138.00
491.22 137.21
494.24 139.18
493.59 142.73
497.00 138.00
-1.00 -1.00
1 0
0
3
441.00 165.00
495.00 138.00
-1.00 -1.00
1 0
0
3
423.00 231.00
423.07 236.83
424.57 233.55
428.18 233.69
423.00 231.00
-1.00 -1.00
1 0
0
3
563.00 479.00
421.00 231.00
-1.00 -1.00
1 0
0
3
433.00 394.00
438.82 394.29
435.65 392.59
436.00 389.00
433.00 394.00
-1.00 -1.00
1 0
0
3
554.00 335.00
434.00 391.00
-1.00 -1.00
1 0
0
3
176.00 317.00
178.50 322.27
178.50 318.66
181.82 317.28
176.00 317.00
-1.00 -1.00
1 0
0
3
325.00 413.00
175.00 315.00
-1.00 -1.00
1 0
0
3
343.00 378.00
340.62 372.67
340.54 376.28
337.18 377.59
343.00 378.00
-1.00 -1.00
1 0
0
3
199.00 285.00
342.00 377.00
-1.00 -1.00
1 0
0
3
344.00 226.00
338.60 228.20
342.20 228.40
343.40 231.80
344.00 226.00
-1.00 -1.00
1 0
0
3
197.00 458.00
342.00 226.00
-1.00 -1.00
1 0
0
3
523.00 513.00
520.80 507.60
520.60 511.20
517.20 512.40
523.00 513.00
-1.00 -1.00
1 0
0
3
424.00 461.00
522.00 512.00
-1.00 -1.00
1 0
0
3
553.00 583.00
547.45 584.79
551.02 585.26
551.97 588.74
553.00 583.00
-1.00 -1.00
1 0
0
3
491.00 657.00
553.00 583.00
-1.00 -1.00
1 0
0
3
235.00 559.00
235.65 564.79
236.82 561.38
240.42 561.15
235.00 559.00
-1.00 -1.00
1 0
0
3
304.00 656.00
233.00 556.00
-1.00 -1.00
1 0
0
4
383.00 420.00
354.00 467.00
383.00 364.77
383.00 475.23
438.23 420.00
327.77 420.00
-1.00 -1.00
5 0
0
4
189.00 515.00
160.00 562.00
189.00 459.77
189.00 570.23
244.23 515.00
133.77 515.00
-1.00 -1.00
5 0
0
4
577.00 532.00
548.00 579.00
577.00 476.77
577.00 587.23
632.23 532.00
521.77 532.00
-1.00 -1.00
5 0
0
4
592.00 296.00
563.00 343.00
592.00 240.77
592.00 351.23
647.23 296.00
536.77 296.00
-1.00 -1.00
5 0
0
4
388.00 185.00
359.00 232.00
388.00 129.77
388.00 240.23
443.23 185.00
332.77 185.00
-1.00 -1.00
5 0
0
4
145.00 265.00
116.00 312.00
145.00 209.77
145.00 320.23
200.23 265.00
89.77 265.00
-1.00 -1.00
5 0
0
3
282.00 708.00
282.00 658.00
500.00 658.00
500.00 708.00
282.00 708.00
-1.00 -1.00
5 0
0
3
384.00 660.00
384.00 484.00
-1.00 -1.00
6 0
0
3
384.00 484.00
381.00 489.00
384.00 487.00
387.00 489.00
384.00 484.00
-1.00 -1.00
6 0
0
3
552.00 484.00
408.00 236.00
-1.00 -1.00
6 0
0
3
408.00 236.00
408.28 241.82
409.66 238.50
413.27 238.50
408.00 236.00
-1.00 -1.00
6 0
0
3
432.00 452.00
528.00 500.00
-1.00 -1.00
6 0
0
3
528.00 500.00
525.50 494.73
525.50 498.34
522.18 499.72
528.00 500.00
-1.00 -1.00
6 0
0
3
240.00 484.00
328.00 444.00
-1.00 -1.00
6 0
0
3
240.00 484.00
245.69 485.26
242.85 483.05
243.79 479.57
240.00 484.00
-1.00 -1.00
6 0
0
0
320.00 668.00
320.00 681.00
320.00 681.00
320.00 681.00
-1.00 -1.00
3 2
11 SOCKET CODE
0
512.00 116.00
512.00 129.00
512.00 129.00
512.00 129.00
-1.00 -1.00
3 2
13 NETWORK LEVEL
3
496.00 148.00
496.00 100.00
704.00 100.00
704.00 148.00
496.00 148.00
-1.00 -1.00
6 0
0
0
64.00 116.00
64.00 129.00
64.00 129.00
64.00 129.00
-1.00 -1.00
3 2
5 CLOCK
3
48.00 148.00
48.00 100.00
160.00 100.00
160.00 148.00
48.00 148.00
-1.00 -1.00
6 0
0
0
160.00 500.00
160.00 513.00
160.00 513.00
160.00 513.00
-1.00 -1.00
3 2
4 SEND
0
544.00 524.00
544.00 537.00
544.00 537.00
544.00 537.00
-1.00 -1.00
3 2
4 RECV
0
352.00 421.00
352.00 434.00
352.00 434.00
352.00 434.00
-1.00 -1.00
3 2
6 DRIVER
0
105.00 264.00
105.00 277.00
105.00 277.00
105.00 277.00
-1.00 -1.00
3 2
6 TIMERS
0
560.00 276.00
560.00 289.00
560.00 289.00
560.00 289.00
-1.00 -1.00
3 2
5 INPUT
0
349.00 181.00
349.00 194.00
349.00 194.00
349.00 194.00
-1.00 -1.00
3 2
6 OUTPUT
3
192.00 292.00
336.00 388.00
-1.00 -1.00
6 0
0
3
336.00 388.00
334.59 382.34
333.88 385.88
330.34 386.59
336.00 388.00
-1.00 -1.00
6 0
0
3
328.00 404.00
184.00 308.00
-1.00 -1.00
6 0
0
3
184.00 308.00
187.13 312.92
186.68 309.34
189.81 307.55
184.00 308.00
-1.00 -1.00
6 0
0
3
208.00 460.00
352.00 236.00
-1.00 -1.00
6 0
0
3
352.00 236.00
347.08 239.13
350.66 238.68
352.45 241.81
352.00 236.00
-1.00 -1.00
6 0
0
3
432.00 148.00
496.00 116.00
-1.00 -1.00
6 0
0
3
496.00 116.00
491.00 113.00
493.00 116.00
491.00 119.00
496.00 116.00
-1.00 -1.00
6 0
0
3
224.00 564.00
288.00 660.00
-1.00 -1.00
6 0
0
3
288.00 660.00
288.45 654.19
286.66 657.32
283.08 656.87
288.00 660.00
-1.00 -1.00
6 0
0
-1

274
share/doc/iso/wisc/figs/trans_flow.nr Normal file
View File

@ -0,0 +1,274 @@
.(z
.br
.nr g1 3456u
.nr g2 3202u
.GS C
.nr g3 \n(.f
.nr g4 \n(.s
\0
.sp -1
.sp 253u
\h'1265u'\D'l 2u 30u'\D'l -9u -16u'\D'l -19u 2u'\D'l 26u -16u'
.sp -1
.sp 505u
\h'928u'\D'l 337u -505u'
.sp -1
.sp 2359u
\h'2361u'\D'l -27u 16u'\D'l 11u -16u'\D'l -11u -15u'\D'l 27u 15u'
.sp -1
.sp -168u
\h'2023u'\D'l 338u 168u'
.sp -1
.sp -464u
\h'1602u'\D'l -26u -16u'\D'l 19u 2u'\D'l 9u -16u'\D'l -2u 30u'
.sp -1
.sp -1180u
\h'843u'\D'l 759u 1180u'
.sp -1
.sp 801u
\h'717u'\D'l 16u -26u'\D'l -2u 19u'\D'l 16u 9u'\D'l -30u -2u'
.sp -1
.sp -506u
\h'1475u'\D'l -758u 506u'
.sp -1
.sp 84u
\h'1518u'\D'l -8u 30u'\D'l -4u -18u'\D'l -18u -4u'\D'l 30u -8u'
.sp -1
.sp 506u
\h'759u'\D'l 759u -506u'
.sp -1
.ft B
.ps 10
.nr g8 \n(.d
.ds g9 "OUTPUT
.sp 585u
\h'1586u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 10
.nr g8 \n(.d
.ds g9 "INPUT
.sp 85u
\h'2698u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 10
.nr g8 \n(.d
.ds g9 "TIMERS
.sp 148u
\h'301u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 10
.nr g8 \n(.d
.ds g9 "DRIVER
.sp -679u
\h'1602u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 10
.nr g8 \n(.d
.ds g9 "RECV
.sp -1221u
\h'2613u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 10
.nr g8 \n(.d
.ds g9 "SEND
.sp -1096u
\h'590u'\&\*(g9
.sp |\n(g8u
.sp 759u
\D'l 0u 253u'\D'l 590u 0u'\D'l 0u -253u'\D'l -590u 0u'
.sp -1
.ft B
.ps 10
.nr g8 \n(.d
.ds g9 "CLOCK
.sp 168u
\h'85u'\&\*(g9
.sp |\n(g8u
\h'2361u'\D'l 0u 253u'\D'l 1095u 0u'\D'l 0u -253u'\D'l -1095u 0u'
.sp -1
.ft B
.ps 10
.nr g8 \n(.d
.ds g9 "NETWORK LEVEL
.sp 168u
\h'2445u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 10
.nr g8 \n(.d
.ds g9 "SOCKET CODE
.sp -2739u
\h'1433u'\&\*(g9
.sp |\n(g8u
.sp -1770u
\h'1012u'\D'l 30u -7u'\D'l -15u 12u'\D'l 5u 18u'\D'l -20u -23u'
.sp -1
\h'1012u'\D'l 463u 210u'
.sp -1
.sp -85u
\h'2529u'\D'l -13u 28u'\D'l 0u -19u'\D'l -18u -7u'\D'l 31u -2u'
.sp -1
.sp 253u
\h'2023u'\D'l 506u -253u'
.sp -1
.sp 1138u
\h'1897u'\D'l 1u -30u'\D'l 8u 17u'\D'l 19u 0u'\D'l -28u 13u'
.sp -1
.sp -1306u
\h'2656u'\D'l -759u 1306u'
.sp -1
\h'1771u'\D'l -16u -27u'\D'l 16u 11u'\D'l 15u -11u'\D'l -15u 27u'
.sp -1
.sp -926u
\h'1771u'\D'l 0u 926u'
.sp -1
\D't 1u'
.sp -1
.sp -253u
\h'1233u'\D'l 0u 263u'\D'l 1149u 0u'\D'l 0u -263u'\D'l -1149u 0u'
.sp -1
.sp 2332u
\h'220u'\D'c 581u'
.sp -1
.sp 422u
\h'1501u'\D'c 581u'
.sp -1
.sp -585u
\h'2575u'\D'c 581u'
.sp -1
.sp -1242u
\h'2496u'\D'c 581u'
.sp -1
.sp 89u
\h'452u'\D'c 581u'
.sp -1
.sp 500u
\h'1474u'\D'c 581u'
.sp -1
\D's 4u'
.sp -1
.sp -1242u
\h'1349u'\D'l -374u 526u'
.sp -1
.sp 511u
\h'986u'\D'l 3u -31u'\D'l 6u 18u'\D'l 19u 1u'\D'l -28u 12u'
.sp -1
.sp -517u
\h'2334u'\D'l 327u 390u'
.sp -1
.sp 390u
\h'2661u'\D'l -29u -9u'\D'l 18u -3u'\D'l 5u -18u'\D'l 6u 30u'
.sp -1
.sp 642u
\h'1981u'\D'l 517u -268u'
.sp -1
.sp -273u
\h'2503u'\D'l -12u 27u'\D'l -1u -18u'\D'l -18u -6u'\D'l 31u -3u'
.sp -1
.sp 289u
\h'785u'\D'l 764u 1222u'
.sp -1
.sp 1222u
\h'1560u'\D'l -29u -12u'\D'l 19u -1u'\D'l 7u -18u'\D'l 3u 31u'
.sp -1
.sp -311u
\h'796u'\D'l 753u -485u'
.sp -1
.sp -490u
\h'1555u'\D'l -13u 28u'\D'l 0u -19u'\D'l -18u -7u'\D'l 31u -2u'
.sp -1
.sp -184u
\h'1460u'\D'l -791u 516u'
.sp -1
.sp 506u
\h'675u'\D'l 13u -28u'\D'l 0u 19u'\D'l 17u 7u'\D'l -30u 2u'
.sp -1
.sp -95u
\h'2666u'\D'l -632u -295u'
.sp -1
.sp -311u
\h'2029u'\D'l 30u -2u'\D'l -16u 9u'\D'l 1u 19u'\D'l -15u -26u'
.sp -1
.sp -448u
\h'2714u'\D'l -749u 1307u'
.sp -1
.sp 1307u
\h'1976u'\D'l 0u -31u'\D'l 8u 17u'\D'l 19u -1u'\D'l -27u 15u'
.sp -1
.sp 347u
\h'2071u'\D'l 284u 143u'
.sp -1
.sp 143u
\h'2366u'\D'l -31u 4u'\D'l 16u -11u'\D'l -3u -18u'\D'l 18u 25u'
.sp -1
.sp -548u
\h'2903u'\D'l 32u 495u'
.sp -1
.sp 10u
\h'2908u'\D'l 18u 26u'\D'l -17u -10u'\D'l -15u 11u'\D'l 14u -27u'
.sp -1
.sp -153u
\h'2598u'\D'l -543u 290u'
.sp -1
.sp 285u
\h'2071u'\D'l 13u -28u'\D'l 0u 19u'\D'l 17u 7u'\D'l -30u 2u'
.sp -1
.sp -785u
\h'1728u'\D'l 11u 658u'
.sp -1
.sp 643u
\h'1739u'\D'l -16u -27u'\D'l 16u 11u'\D'l 16u -11u'\D'l -16u 27u'
.sp -1
\D's -1u'\D't 3u'
.sp -1
.sp 174u
\h'469u'\D'l -68u 316u'
.sp -1
\h'475u'\D'l 10u 28u'\D'l -14u -13u'\D'l -17u 7u'\D'l 21u -22u'
.sp -1
.sp -1938u
\h'2592u'\D'l -337u -416u'
.sp -1
.sp -411u
\h'2255u'\D'l 30u 7u'\D'l -19u 4u'\D'l -3u 19u'\D'l -8u -30u'
.sp -1
.sp 1532u
\h'1802u'\D'l 11u 632u'
.sp -1
.sp 622u
\h'1818u'\D'l -18u -25u'\D'l 17u 9u'\D'l 15u -12u'\D'l -14u 28u'
.sp -1
.sp -401u
\h'2603u'\D'l -632u -279u'
.sp -1
.sp -284u
\h'1976u'\D'l 31u 2u'\D'l -18u 7u'\D'l 0u 19u'\D'l -13u -28u'
.sp -1
.sp 1201u
\h'2829u'\D'l -10u -480u'
.sp -1
.sp -474u
\h'2814u'\D'l 20u 23u'\D'l -18u -8u'\D'l -13u 13u'\D'l 11u -28u'
.sp -1
.sp -116u
\h'2640u'\D'l -538u 311u'
.sp -1
.sp 311u
\h'2108u'\D'l 14u -28u'\D'l -1u 19u'\D'l 17u 8u'\D'l -30u 1u'
.sp -1
.sp 532u
\D't 3u'\D's -1u'
.br
.ft \n(g3
.ps \n(g4
.GE
.ce
\fB Figure \n+(FG\fR: Control flow (solid) and data flow (broken)
.ce
among the parts of the transport implementation.
.)z

18
share/doc/iso/wisc/figs/unix_ipc.grn Normal file
View File

@ -0,0 +1,18 @@
.(z L
.GS C
width 6.0
high 7.0
1 8
2 10
3 12
4 14
sc 0.3
narrow 1
medium 3
thick 7
pointscale off
file unix_ipc.gsrc
.GE
.ce
\fBFigure \n+(FG\fR: IPC in 4.2 Unix
.)z

1041
share/doc/iso/wisc/figs/unix_ipc.gsrc Normal file
View File

File diff suppressed because it is too large Load Diff

499
share/doc/iso/wisc/figs/unix_ipc.nr Normal file
View File

@ -0,0 +1,499 @@
.(z L
.br
.nr g1 3155u
.nr g2 4031u
.GS C
.nr g3 \n(.f
.nr g4 \n(.s
\0
.sp -1
\D's 4u'\D't 1u'
.sp -1
.sp 2366u
\h'2454u'\D'l -17u 27u'\D'l 2u -20u'\D'l -17u -10u'\D'l 32u 3u'
.sp -1
.sp 789u
\h'1534u'\D'l -3u -32u'\D'l 10u 17u'\D'l 20u -2u'\D'l -27u 17u'
.sp -1
.sp -789u
\h'2454u'\D'g -175u 88u -176u 87u -87u 88u -351u 350u -87u 88u -44u 88u'
.sp -1
.sp -175u
\h'657u'\D'l -16u -28u'\D'l 16u 11u'\D'l 17u -11u'\D'l -17u 28u'
.sp -1
.sp -263u
\h'1139u'\D'g -350u 0u -88u 87u -44u 88u 0u 88u'
.sp -1
.sp 438u
\h'1621u'\D'l 28u -17u'\D'l -11u 17u'\D'l 11u 16u'\D'l -28u -16u'
.sp -1
.sp -88u
\h'2454u'\D'l -27u 17u'\D'l 11u -17u'\D'l -11u -16u'\D'l 27u 16u'
.sp -1
.sp -263u
\h'2717u'\D'l -16u -27u'\D'l 16u 11u'\D'l 16u -11u'\D'l -16u 27u'
.sp -1
.sp -350u
\h'2717u'\D'l 16u 27u'\D'l -16u -11u'\D'l -16u 11u'\D'l 16u -27u'
.sp -1
.sp 438u
\h'2498u'\D'l -32u 2u'\D'l 17u -9u'\D'l -2u -20u'\D'l 17u 27u'
.sp -1
.sp -263u
\h'2016u'\D'l 32u -2u'\D'l -18u 9u'\D'l 3u 20u'\D'l -17u -27u'
.sp -1
.sp 833u
\h'2454u'\D'l 8u -31u'\D'l 4u 19u'\D'l 19u 4u'\D'l -31u 8u'
.sp -1
.sp -176u
\h'2586u'\D'l -8u 31u'\D'l -4u -19u'\D'l -19u -4u'\D'l 31u -8u'
.sp -1
.sp 44u
\h'2805u'\D'l 16u 28u'\D'l -16u -11u'\D'l -17u 11u'\D'l 17u -28u'
.sp -1
.sp 351u
\h'2016u'\D'l -28u 16u'\D'l 11u -16u'\D'l -11u -17u'\D'l 28u 17u'
.sp -1
.sp -132u
\h'1621u'\D'l 32u -2u'\D'l -17u 10u'\D'l 3u 19u'\D'l -18u -27u'
.sp -1
.sp 570u
\h'1665u'\D'l 17u -27u'\D'l -2u 20u'\D'l 17u 10u'\D'l -32u -3u'
.sp -1
.sp -219u
\h'2060u'\D'l -8u 31u'\D'l -4u -19u'\D'l -19u -4u'\D'l 31u -8u'
.sp -1
.sp 614u
\h'2542u'\D'l -8u 31u'\D'l -4u -20u'\D'l -19u -4u'\D'l 31u -7u'
.sp -1
.sp -439u
\h'2542u'\D'l -31u -7u'\D'l 19u -4u'\D'l 4u -20u'\D'l 8u 31u'
.sp -1
.sp -131u
\h'2410u'\D'l 31u 8u'\D'l -19u 3u'\D'l -4u 20u'\D'l -8u -31u'
.sp -1
\h'2191u'\D'l 17u 27u'\D'l -17u -11u'\D'l -16u 11u'\D'l 16u -27u'
.sp -1
.sp 438u
\h'657u'\D'l 17u 27u'\D'l -17u -10u'\D'l -16u 10u'\D'l 16u -27u'
.sp -1
.sp -88u
\h'1139u'\D'l -27u 17u'\D'l 11u -17u'\D'l -11u -16u'\D'l 27u 16u'
.sp -1
.sp 88u
\h'657u'\D'l 0u 88u'
.sp -1
.sp -2016u
\h'1183u'\D'l -32u 3u'\D'l 17u -10u'\D'l -2u -20u'\D'l 17u 27u'
.sp -1
.sp -262u
\h'1665u'\D'l -16u -27u'\D'l 16u 11u'\D'l 17u -11u'\D'l -17u 27u'
.sp -1
.sp -88u
\h'1665u'\D'l 17u 28u'\D'l -17u -11u'\D'l -16u 11u'\D'l 16u -28u'
.sp -1
\h'2498u'\D'l -32u 3u'\D'l 17u -10u'\D'l -2u -19u'\D'l 17u 26u'
.sp -1
.sp -262u
\h'1972u'\D'l 32u -3u'\D'l -17u 10u'\D'l 2u 19u'\D'l -17u -26u'
.sp -1
.sp -526u
\h'2366u'\D'l -7u 31u'\D'l -4u -20u'\D'l -20u -4u'\D'l 31u -7u'
.sp -1
.sp 175u
\h'1928u'\D'l 17u -27u'\D'l -2u 20u'\D'l 17u 9u'\D'l -32u -2u'
.sp -1
.sp -44u
\h'1271u'\D'l -31u -8u'\D'l 19u -4u'\D'l 4u -19u'\D'l 8u 31u'
.sp -1
.sp -131u
\h'1052u'\D'l 31u 7u'\D'l -20u 4u'\D'l -4u 20u'\D'l -7u -31u'
.sp -1
.sp 788u
\h'1665u'\D'l 0u 88u'
.sp -1
.sp 438u
\h'2717u'\D'l 0u 350u'
.sp -1
.sp 876u
\h'2805u'\D'l 0u 570u'
.sp -1
.sp -701u
\h'2016u'\D'l 482u 263u'
.sp -1
.sp 438u
\h'2454u'\D'l -833u 88u'
.sp -1
.sp 219u
\h'2586u'\D'l -132u 176u'
.sp -1
.sp 658u
\h'2410u'\D'l 88u 87u'
.sp -1
.sp -395u
\h'1621u'\D'l 395u 132u'
.sp -1
.sp 570u
\h'1665u'\D'l 395u -219u'
.sp -1
.sp 175u
\h'1928u'\D'l 0u -1490u'
.sp -1
\h'1665u'\D'l 263u 0u'
.sp -1
.sp -876u
\h'1665u'\D'l 263u 0u'
.sp -1
\h'1008u'\D'l 131u 0u'
.sp -1
.sp 876u
\h'1008u'\D'l 131u 0u'
.sp -1
.sp 351u
\h'2191u'\D'l 0u -701u'
.sp -1
.sp -88u
\h'657u'\D'l 0u -175u'
.sp -1
.sp -2366u
\h'482u'\D'g -395u 701u 0u 526u 0u 438u 0u 614u 88u 87u 438u 0u 1841u 0u 88u -43u'
.sp -1
\h'920u'\D'l 263u 175u'
.sp -1
.sp -437u
\h'1972u'\D'l 526u 262u'
.sp -1
.sp -526u
\h'2366u'\D'l -438u 175u'
.sp -1
\h'1052u'\D'l 219u 131u'
.sp -1
.sp 3505u
\h'263u'\D'l 263u 0u'
.sp -1
\D's -1u'\D't 3u'
.sp -1
\h'1490u'\D'l 263u 0u'
.sp -1
.ft I
.ps 12
.nr g8 \n(.d
.ds g9 "data flow
.sp 87u
\h'613u'\&\*(g9
.sp |\n(g8u
.ft I
.ps 12
.nr g8 \n(.d
.ds g9 "control flow
.sp 87u
\h'1840u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "DoD IP
.sp -1052u
\h'2103u'\&\*(g9
.sp |\n(g8u
.sp -789u
\h'2629u'\D'l -31u -8u'\D'l 20u -4u'\D'l 4u -19u'\D'l 7u 31u'
.sp -1
.sp -88u
\h'2498u'\D'l 31u 8u'\D'l -19u 4u'\D'l -4u 19u'\D'l -8u -31u'
.sp -1
.sp 175u
\h'1621u'\D'l 18u -26u'\D'l -3u 19u'\D'l 17u 10u'\D'l -32u -3u'
.sp -1
.sp -219u
\h'2016u'\D'l -8u 31u'\D'l -4u -19u'\D'l -19u -4u'\D'l 31u -8u'
.sp -1
.sp -219u
\h'2016u'\D'l -28u 17u'\D'l 11u -17u'\D'l -11u -16u'\D'l 28u 16u'
.sp -1
.sp -131u
\h'1621u'\D'l 32u -3u'\D'l -17u 10u'\D'l 3u 20u'\D'l -18u -27u'
.sp -1
.sp -526u
\h'1840u'\D'l 17u 27u'\D'l -17u -11u'\D'l -16u 11u'\D'l 16u -27u'
.sp -1
.sp 1271u
\h'1139u'\D'l -27u 16u'\D'l 11u -16u'\D'l -11u -17u'\D'l 27u 17u'
.sp -1
.sp -877u
\h'1139u'\D'l -27u 17u'\D'l 11u -17u'\D'l -11u -16u'\D'l 27u 16u'
.sp -1
.sp -350u
\h'526u'\D'l -17u -28u'\D'l 17u 11u'\D'l 16u -11u'\D'l -16u 28u'
.sp -1
.sp -876u
\h'1490u'\D'l -17u -27u'\D'l 17u 11u'\D'l 16u -11u'\D'l -16u 27u'
.sp -1
.sp -88u
\h'1490u'\D'l 16u 28u'\D'l -16u -11u'\D'l -17u 11u'\D'l 17u -28u'
.sp -1
.sp 88u
\h'2454u'\D'l -27u 17u'\D'l 11u -17u'\D'l -11u -16u'\D'l 27u 16u'
.sp -1
.sp -263u
\h'1928u'\D'l 32u -2u'\D'l -17u 9u'\D'l 2u 20u'\D'l -17u -27u'
.sp -1
.sp -482u
\h'2454u'\D'l -27u 17u'\D'l 11u -17u'\D'l -11u -16u'\D'l 27u 16u'
.sp -1
.sp 132u
\h'1928u'\D'l 28u -17u'\D'l -11u 17u'\D'l 11u 16u'\D'l -28u -16u'
.sp -1
.sp -44u
\h'1227u'\D'l -31u -8u'\D'l 19u -4u'\D'l 4u -19u'\D'l 8u 31u'
.sp -1
.sp -132u
\h'964u'\D'l 32u -2u'\D'l -17u 10u'\D'l 2u 19u'\D'l -17u -27u'
.sp -1
.sp 2716u
\h'1621u'\D'l 395u -219u'
.sp -1
.sp -569u
\h'1621u'\D'l 395u 131u'
.sp -1
.sp -307u
\h'1840u'\D'g 0u -175u 0u -44u'
.sp -1
.sp 789u
\h'2629u'\D'l -131u -88u'
.sp -1
.sp 263u
\h'1840u'\D'l 0u -1052u'
.sp -1
\h'1665u'\D'l 175u 0u'
.sp -1
.sp -877u
\h'1665u'\D'l 175u 0u'
.sp -1
.sp 877u
\h'1008u'\D'l 131u 0u'
.sp -1
.sp -877u
\h'1008u'\D'l 131u 0u'
.sp -1
.sp -701u
\h'1139u'\D'g -350u 0u -176u 88u -87u 175u 0u 88u'
.sp -1
.sp -613u
\h'1490u'\D'l 0u 88u'
.sp -1
.sp -175u
\h'1928u'\D'l 526u 263u'
.sp -1
.sp -482u
\h'2454u'\D'l -526u 132u'
.sp -1
.sp -44u
\h'964u'\D'l 263u 132u'
.sp -1
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "proto n
.sp 2936u
\h'1271u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "proto 1
.sp 2015u
\h'1271u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "mbufs
.sp 1752u
\h'2586u'\&\*(g9
.sp |\n(g8u
.sp 2892u
\h'1139u'\D'c 525u'
.sp -1
.sp -877u
\h'1139u'\D'c 525u'
.sp -1
.sp 351u
\h'2016u'\D'c 525u'
.sp -1
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "switch
.sp 219u
\h'438u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "protocol
.sp -88u
\h'438u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "transport
.sp -351u
\h'438u'\&\*(g9
.sp |\n(g8u
.sp -701u
\h'263u'\D'l 0u 1402u'\D'l 701u 0u'\D'l 0u -1402u'\D'l -701u 0u'
.sp -1
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "sockets
.sp -351u
\h'1402u'\&\*(g9
.sp |\n(g8u
.sp -439u
\h'1139u'\D'c 876u'
.sp -1
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "tables
.sp -263u
\h'2586u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "routing
.sp -394u
\h'2586u'\&\*(g9
.sp |\n(g8u
.sp -350u
\h'2454u'\D'c 525u'
.sp -1
.sp -1051u
\h'2366u'\D'c 701u'
.sp -1
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "management
.sp 131u
\h'2454u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "network
\h'2498u'\&\*(g9
.sp |\n(g8u
\D's 4u'\D't 1u'
.sp -1
.sp 438u
\h'1183u'\D'l 789u 0u'
.sp -1
.ft I
.ps 12
.nr g8 \n(.d
.ds g9 "kernel
.sp 176u
\&\*(g9
.sp |\n(g8u
.ft I
.ps 12
.nr g8 \n(.d
.ds g9 "user
.sp -87u
\&\*(g9
.sp |\n(g8u
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "drivers
.sp 2892u
\h'2629u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "interface
.sp 2760u
\h'2629u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "network
.sp 2629u
\h'2629u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "clock
.sp 438u
\h'613u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "system calls
.sp 219u
\h'1358u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "C library
.sp -87u
\h'1402u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "user
.sp -482u
\h'657u'\&\*(g9
.sp |\n(g8u
.ft B
.ps 12
.nr g8 \n(.d
.ds g9 "program
.sp -350u
\h'613u'\&\*(g9
.sp |\n(g8u
\D's -1u'\D't 3u'
.sp -1
.sp 44u
\h'1183u'\D'c 788u'
.sp -1
.sp 2629u
\h'2454u'\D'c 701u'
.sp -1
.sp -1184u
\h'2454u'\D'c 525u'
.sp -1
.sp -1051u
\h'438u'\D'c 525u'
.sp -1
.sp -876u
\h'526u'\D'c 525u'
.sp -1
.sp 438u
\h'1183u'\D'l -1183u 0u'
.sp -1
\h'1972u'\D'l 1183u 0u'
.sp -1
.sp 1270u
\h'1928u'\D'l 17u 28u'\D'l -17u -11u'\D'l -16u 11u'\D'l 16u -28u'
.sp -1
.sp 1972u
\D't 3u'\D's -1u'
.br
.ft \n(g3
.ps \n(g4
.GE
.ce
\fBFigure \n+(FG\fR: IPC in 4.2 Unix
.)z

76
share/doc/iso/wisc/intro.nr Normal file
View File

@ -0,0 +1,76 @@
.NC "Introduction"
.sh 1 "Introduction"
.pp
This document describes the design and implementation of the ISO
transport and network layers written for the ACIS Operating System,
the IBM ACIS port of Berkeley 4.3 Unix\**
.(f
\** Unix is a registered trademark of AT&T.
.)f
for the IBM RT PC,
hereafter called AOS.
Collectively, this work is called the Wisconsin ARGO kernel.
The ARGO kernel supports the
the connection-oriented ISO transport service (COTS), the
ISO connectionless network service (CLNS)
and a
connection-oriented network service (CONS).
The COTS is provided by the ISO transport protocol TP,
ISO 8073 Revised.
The CLNS is provided by the connectionless network protocol,
ISO 8473.
The CONS is provided by the X.25 protocols.
The ARGO implementation of the CONS is not a complete
ISO CONS, but contains enough of the CONS to support
the COTS and the CLNS (in the latter case, the CONS can be
viewed as a subnetwork service).
.pp
The purposes of this document are
.ip "1) "
to describe the transport service and the software interface
between the user and provider of this service,
.ip "2) "
to describe the network service and the software interface it
provides,
.ip "3) "
to describe the design of the software which provides
these services, and
.ip "4) "
to provide a guide for readers who are perusing or maintaining
the ARGO kernel source code.
.pp
It is assumed that the reader is familiar with the \fBC\fR
programming language,
with Unix conventions, and with the ISO specifications listed in Appendix A.
.sh 1 "Organization"
.pp
This document is composed of several chapters.
Chapter One contains this introduction. Chapter Two presents a
definition of terms and phrases used throughout the document.
Chapter Three describes the transport service interface, which is
the interface between the transport protocol implementation software and the transport user software.
Chapter Four describes the network service interface, and the interface
above and below the network layer.
Chapter Five explains the format of an OSI address.
Chapter Six describes the
the architecture of the interprocess communication support in the
kernel, which to a large degree mandates
the design of a protocol implementation for a 4.3 Unix kernel.
Chapter Seven describes the design of this transport
protocol implementation,
including descriptions of implementation options.
Chapter Eight describes the design of the network layer implementation.
Chapter Nine describes the way errors are handled in the system.
Chapter Ten summarizes the methods used for
testing and debugging the ARGO kernel.
Appendix A is a list of the applicable ISO standards.
.\" The manual pages relevant to the transport and network layers
.\" are included as Appendix B.
.pp
Several conventions are followed in this document.
All procedure names and system call names are followed
by a pair of parentheses, for example,
\fIread()\fR.
References to manual pages consist of the name of the
manual page, followed by the section in which
the man page is found: \fIread(2)\fR.

372
share/doc/iso/wisc/ipc.nr Normal file
View File

@ -0,0 +1,372 @@
.NC "The Design of Unix IPC"
.sh 1 "General"
.pp
The ARGO implementation of
TP and CLNP was designed to fit into the AOS
kernel
as easily as possible.
All the standard protocol hooks are used.
To understand the design, it is useful to have
read
Leffler, Joy, and Fabry:
\*(lq4.2 BSD Networking Implementation Notes\*(rq July 1983.
This section describes the
design of the IPC support in the AOS kernel.
.sh 1 "Functional Unit Overview"
.pp
The
AOS
kernel
is a monolithic program of considerable size and complexity.
The code can be separated into parts of distinct function,
but there are no kernel processes per se.
The kernel code is either executed on behalf of a user
process, in which case the kernel was entered by a system call,
or it is executed on behalf of a hardware or software interrupt.
The following sections describe briefly the major functional units
of the kernel.
.\" FIGURE
.so figs/func_units.nr
.CF
shows the arrangement of these kernel units and
their interactions.
.sh 2 "The file system."
.pp
.sh 2 "Virtual memory support."
.pp
This includes protection, swapping, paging, and
text sharing.
.sh 2 "Blocked device drivers (disks, tapes)."
.pp
All these drivers share some minor functional units,
such as buffer management and bus support
for the various types of busses on the machine.
.sh 2 "Interprocess communication (IPC)."
.pp
This includes
support for various protocols,
buffer management, and a standard interface for inter-protocol
communication.
.sh 2 "Network interface drivers."
.pp
These drivers are closely tied to the IPC support.
They use the IPC's buffer management unit rather
than the buffers used by the blocked device drivers.
The interface between these drivers and the rest of the kernel
differs from the interface used by the blocked devices.
.sh 2 "Tty driver"
.pp
This is terminal support, including the user interface
and the device drivers.
.sh 2 "System call interface."
.pp
This handles signals, traps, and system calls.
.sh 2 "Clock."
.pp
The clock is used in various forms by many
other units.
.sh 2 "User process support (the rest)."
.pp
This includes support for accounting, process creation,
control, scheduling, and destruction.
.pp
.sh 2 "IPC"
.pp
The major functional unit that supports IPC
can be divided into the following smaller functional
units.
.sh 3 "Buffer management."
.pp
All protocols share a pool of buffers called \fImbufs\fR:
.(b
\fC
.TS
tab(+);
l s s s.
struct mbuf {
.T&
l l l l.
+struct mbuf+*m_next;+/* next buffer in chain */
+u_long+m_off;+/* offset of data */
+short+m_len;+/* amount of data */
+short+m_type;+/* mbuf type (0 == free) */
+u_char+m_dat[MLEN];+/* data storage */
+struct mbuf+*m_act;+/* link in 2-d structure */
};
.TE
\fR
.)b
.pp
There are two forms of mbufs - small ones and large ones.
Small ones are 128 octets in
AOS
and 256 octets
in the ARGO release. Small mbufs are copied by byte-to-byte
copies.
The data in these mbufs are kept in the character
array field \fIm_dat\fR in the mbuf structure
itself.
For this type of mbuf, the field \fIm_off\fR is positive,
and is the offset to the beginning of the data from
the beginning of the mbuf structure itself.
Large mbufs, called \fIclusters\fR, are page-sized
and page-aligned.
They may be \*(lqcopied\*(rq by multiply mapping the pages they occupy.
They consist of a page of memory plus a small mbuf structure
whose fields are used
to link clusters into chains, but whose \fIm_dat\fR array is
not used.
The \fIm_off\fR field of the structure
is the offset (positive or negative) from the
beginning of the mbuf structure to the beginning
of the data page part of the cluster.
In the case of clusters, the offset is always out of the
bounds of the \fIm_dat\fR array and so it is alway possible
to tell from the \fIm_off\fR field whether an mbuf structure
is part of a cluster or is a small mbuf.
All mbufs permanently reside in memory.
The mbuf management unit manages its own page table.
The mbuf manager keeps limited statistics on the quantities and
types of buffers in use.
Mbufs are used for many purposes, and most of these purposes
have a type associated with them.
Some of the types that buffers may take are
MT_FREE (not allocated), MT_DATA,
MT_HEADER, MT_SOCKET (socket structure),
MT_PCB (protocol control block),
MT_RTABLE (routing tables),
and
MT_SOOPTS (arguments passed to \fIgetsockopt()\fR and
\fIsetsockopt()\fR.
Data are passed among functional units by means
of queues, the contents of which are
either chains of mbufs or groups of chains of mbufs.
Mbufs are linked into chains with the \fIm_next\fR field.
Chains of mbufs are linked into groups with the \fIm_act\fR
field.
The \fIm_act\fR field allows a protocol to retain packet
boundaries in a queue of mbufs.
.sh 3 "Routing."
.pp
Routing decisions in the kernel are made by the procedure \fIrtalloc()\fR.
This procedure will scan the kernel routing tables (stored in mbufs)
looking for a route. A route is represented by
.(b
\fC
.TS
tab(+);
l s s s.
struct rtentry {
.T&
l l l l.
+u_long+rt_hash;+/* to speed lookups */
+struct sockaddr+rt_dst;+/* key */
+struct sockaddr+rt_gateway;+/* value */
+short+rt_flags;+/* up/down?, host/net */
+short+rt_refcnt;+/* # held references */
+u_long+rt_use;+/* raw # packets forwarded */
+struct ifnet+*rt_ifp;+/* interface to use */
}
.TE
\fR
.)b
When looking for a route, \fIrtalloc()\fR will first hash the entire destination
address, and scan the routing tables looking for a complete route. If a route
is not found, then \fIrtalloc()\fR will rescan the table looking for a route
which matches the \fInetwork\fR portion of the address. If a route is still
not found, then a default route is used (if present).
.pp
If a route is found, the entity which called \fIrtalloc()\fR can use information
from the \fIrtentry\fR structure to dispatch the datagram. Specifically, the
datagram is queued on the interface identified by the interface
pointer \fIrt_ifp\fR.
.sh 3 "Socket code."
.pp
This is the protocol-independent part of the IPC support.
Each communication endpoint (which may or may not be associated
with a connection) is represented by the following structure:
.(b
\fC
.TS
tab(+);
l s s s.
struct socket {
.T&
l l l l.
+short+so_type;+/* type, e.g. SOCK_DGRAM */
+short+so_options;+/* from socket call */
+short+so_linger;+/* time to linger @ close */
+short+so_state;+/* internal state flags */
+caddr_t+so_pcb;+/* network layer pcb */
+struct protosw+*so_proto;+/* protocol handle */
+struct socket+*so_head;+/* ptr to accept socket */
+struct socket+*so_q0;+/* queue of partial connX */
+short+so_q0len;+/* # partials on so_q0 */
+struct socket+*so_q;+/* queue of incoming connX */
+short+so_qlen;+/* # connections on so_q */
+short+so_qlimit;+/* max # queued connX */
+struct sockbuf+{
++short+sb_cc;+/* actual chars in buffer */
++short+sb_hiwat;+/* max actual char count */
++short+sb_mbcnt;+/* chars of mbufs used */
++short+sb_mbmax;+/* max chars of mbufs to use */
++short+sb_lowat;+/* low water mark (not used yet) */
++short+sb_timeo;+/* timeout (not used ) */
++struct mbuf+*sb_mb;+/* the mbuf chain */
++struct proc+*sb_sel;+/* process selecting */
++short+sb_flags;+/* flags, see below */
+} so_rcv, so_snd;
+short+so_timeo;+/* connection timeout */
+u_short+so_error;+/* error affecting connX */
+short+so_oobmark;+/* oob mark (TCP only) */
+short+so_pgrp;+/* pgrp for signals */
}
.TE
\fR
.)b
.pp
The socket code maintains a pair of queues for each socket,
\fIso_rcv\fR and \fIso_snd\fR.
Each queue is associated with a count of the number of characters
in the queue, the maximum number of characters allowed to be put
in the queue, some status information (\fIsb_flags\fR), and
several unused fields.
For a send operation, data are copied from the user's address space
into chains of mbufs.
This is done by the socket module, which then calls the underlying
transport protocol module to place the data
on the send queue.
This is generally done by
appending to the chain beginning at \fIsb_mb\fR.
The socket module copies data from the \fIso_rcv\fR queue
to the user's address space to effect a receive operation.
The underlying transport layer is expected to have put incoming
data into \fIso_rcv\fR by calling procedures in this module.
.in -5
.sh 3 "Transport protocol management."
.pp
All protocols and address types must be \*(lqregistered\*(rq in a
common way in order to use the IPC user interface.
Each protocol must have an entry in a protocol switch table.
Each entry takes the form:
.(b
\fC
.TS
tab(+);
l s s s.
struct protosw {
.T&
l l l l.
+short+pr_type;+/* socket type used for */
+short+pr_family;+/* protocol family */
+short+pr_protocol;+/* protocol # from the database */
+short+pr_flags;+/* status information */
+++/* protocol-protocol hooks */
+int+(*pr_input)();+/* input (from below) */
+int+(*pr_output)();+/* output (from above) */
+int+(*pr_ctlinput)();+/* control input */
+int+(*pr_ctloutput)();+/* control output */
+++/* user-protocol hook */
+int+(*pr_usrreq)();+/* user request: see list below */
+++/* utility hooks */
+int+(*pr_init)();+/* initialization hook */
+int+(*pr_fasttimo)();+/* fast timeout (200ms) */
+int+(*pr_slowtimo)();+/* slow timeout (500ms) */
+int+(*pr_drain)();+/* free some space (not used) */
}
.TE
\fR
.)b
.pp
Associated with each protocol are the types of socket
abstractions supported by the protocol (\fIpr_type\fR), the
format of the addresses used by the protocol (\fIpr_family\fR),
the routines to be called to perform
a standard set of protocol functions (\fIpr_input\fR,...,\fIpr_drain\fR),
and some status information (\fIpr_flags\fR).
The field pr_flags keeps such information as
SS_ISCONNECTED (this socket has a peer),
SS_ISCONNECTING (this socket is in the process of establishing
a connection),
SS_ISDISCONNECTING (this socket is in the process of being disconnected),
SS_CANTSENDMORE (this socket is half-closed and cannot send),
SS_CANTRCVMORE (this socket is half-closed and cannot receive).
There are some flags that are specific to the TCP concept
of out-of-band data.
A flag SS_OOBAVAIL was added for the ARGO implementation, to support
the TP concept of out-of-band data (expedited data).
.sh 3 "Network Interface Drivers"
.pp
The drivers for the devices attaching a Unix machine to a network
medium share a common interface to the protocol
software.
There is a common data structure for managing queues,
not surprisingly, a chain of mbufs.
There is a set of macros that are used to enqueue and
dequeue mbuf chains at high priority.
A driver
delivers an indication to a protocol entity when
an incoming packet has been placed on a queue by
issuing a
software
interrupt.
.sh 3 "Support for individual protocols."
.pp
Each protocol is written as a separate functional unit.
Because all protocols share the clock and the mbuf pool, they
are not entirely insulated from each other.
The details of TP are described in a section that
follows.
.\"*****************************************************
.\" FIGURE
.so figs/unix_ipc.nr
.pp
.CF
shows the arrangement of the IPC support.
.pp
The AOS
IPC was designed for DoD Internet protocols, all of
which run over DoD IP.
The assumptions that DoD Internet is the domain
and that DoD IP is the network layer
appear in the code and data structures in numerous places.
For example, it is assumed that addresses can be compared
by a bitwise comparison of 4 octets.
Another example is that the transport protocols all directly call
IP routines.
There are no hooks in the data structures through
which the transport layer can choose a network level protocol.
A third example is that the host's local addresses
are stored in the network interface drivers and the drivers
have only one address - an Internet address.
A fourth example is that headers are assumed to
fit in one small mbuf (112 bytes for data in AOS).
A fifth example is this:
It is assumed in many places that buffer space is managed
in units of characters or octets.
The user data are copied from user address space into the kernel mbufs
amorphously
by the socket code, a protocol-independent part of the kernel.
This is fine for a stream protocol, but it means that a
packet protocol, in order to \*(lqpacketize\*(rq the data,
must perform a memory-to-memory copy
that might have been avoided had the protocol layer done the original
copy from user address space.
Furthermore, protocols that count credit in terms of packets or
buffers rather than characters do not work efficiently because
the computation of buffer space is not in the protocol module,
but rather it is in the socket code module.
This list of examples is not complete.
.pp
To summarize, adding a new transport protocol to the kernel consists of
adding entries to the tables in the protocol management
unit,
modifying the network interface driver(s) to recognize
new network protocol identifiers,
adding the
new system calls to the kernel and to the user library,
and
adding code modules for each of the protocols,
and correcting deficiencies in the socket code,
where the assumptions made about the nature of
transport protocols do not apply.

50
share/doc/iso/wisc/macros.nr Normal file
View File

@ -0,0 +1,50 @@
.\"
.\" Macro to initialize chapter macros
.\"
.de IC
.nr CN 0 1
..
.\"
.\" Macro to begin new chapter
.\"
.de NC
.he 'ARGO Kernel Programmer\'s Guide''Chapter \\n+(CN'
.bp
.sh 0 "_" 1 1 1 1 1 1
.sz +2
.(l C
CHAPTER \\n(CN
\fB\\$1\fR
.)l
.sp 1
.(x
Chapter \\n(CN \\$1
.)x
.sz -2
..
.\"
.\" Figure conventions:
.\" 1) do .so of figure source - figure reg incremented here
.\" 2) make references to figure via CF
.\"
.\"
.\" Macro to initialize figure register
.\"
.de IF
.nr FG 0 1
..
.\"
.\" Macro for current figure number
.\"
.de CF
Figure \\n(FG
..
.\"
.\" Define this macro to include section headings in table of contents
.\"
.de $0
.(x
Section \\$2 \\$1
.)x
..

1139
share/doc/iso/wisc/net_design.nr Normal file
View File

File diff suppressed because it is too large Load Diff

163
share/doc/iso/wisc/net_serv.nr Normal file
View File

@ -0,0 +1,163 @@
.NC "Network Service Interface"
.sh 1 "Connectionless Network Service"
.pp
This section describes the interface to the ISO connectionless network service.
There are really two interfaces to the CLNS: the internal interface
and the IPC interface.
The internal interface is based on
procedure calls. It is used only within the kernel. The IPC interface
allows a user process to access the CLNS directly. This is used only
for testing and debugging purposes.
.sh 2 "Primitives"
.pp
The CLNS is, by definition, connectionless. Therefore, there are no
primitives associated with connection establishment or connection release.
There is one primitive associated with data transfer: N-UNITDATA.
The parameters to a N-UNITDATA request are: source NSAP address,
destination NSAP address, quality of service, and user data.
The parameters of a N-UNITDATA indication are identical to those of the
request.
In this implementation, the quality of service parameter is not supported.
.sh 2 "Internal Interface"
.pp
Within the kernel, an N-UNITDATA request is effected by the procedure
\fIclnp_output()\fR:
.(b
\fC
.TS
tab(+);
l s s.
clnp_output(m0, isop, datalen, flags)
.T&
l l l.
+struct mbuf+*m0;+/* data */
+struct isopcb+*isop;+/* ISO protocol control block */
+int+datalen;+
+int+flags;+/* flags */
.TE
\fR
.)b
This procedure will construct a DT NPDU, route it, and transmit it on
the appropriate subnetwork. \fIM0\fR is an mbuf chain containing the
user data portion of the N-UNITDATA request. \fIIsopcb\fR is the iso protocol
control block previously allocated. \fIClnp_output\fR will use the following
fields: \fIisop_laddr\fR, isop_faddr, isop_route, isop_options,
isop_optindex, \fI and \fRisop_clnpcache\fR.
\fIDatalen\fR specifies the number of bytes of user data.
The \fIflags\fR parameter will be discussed in a subsequent chapter.
.pp
A N-UNITDATA indication occurs when a DT NPDU arrives. The indication is
generated by calling the appropriate upper layer protocol input routine.
In the case of TP, the procedure \fItpclnp_input()\fR is called:
.(b
\fC
.TS
tab(+);
l s s.
tpclnp_input(m, src, dst, len)
.T&
l l l.
+struct mbuf+*m;+/* DT NPDU */
+struct iso_addr+*src;+/* source of packet */
+struct iso_addr+*dst;+/* destination of packet */
+int+len;+/* length of clnp header */
.TE
\fR
.)b
\fIM\fR contains the entire DT NPDU packet. \fILen\fR indicates the size
of the CLNP header. In other words, the user data of the DT NPDU begins
\fIlen\fR bytes into \fIm\fR. \fISrc\fR and \fIdst\fR indicate the
source and destination NSAP addresses of the packet.
.sh 3 "CLNP/Subnetwork Interface"
.pp
The design of the interface between the subnetwork and the CLNP is
determined by the design of the Unix network interface drivers. CLNP
follows the conventional mechanisms for exchanging packets with a network
interface. See the section on Network Interface Drivers in Chapter Five
for more information on these conventions.
.sh 2 "IPC (\*(lqRaw\*(rq) Interface"
.pp
The IPC interface to the CLNS allows direct (called \*(lqraw\*(rq)
access to CLNP.
This interface is intended for testing and debugging only.
Its use results in the
transmission of CLNP datagrams with nonstandard identification fields.
These raw packets may be rejected by a system not employing the same
convention. See the section on network implementation for more information
about the conventions.
.pp
In order to gain access to the raw interface
a \fIsocket\fR, with address family AF_ISO and type SOCK_RAW must be created.
With this socket in hand,
the system calls \fIsendto()\fR and \fIrecvfrom()\fR can be used to
transmit and receive raw CLNP datagrams.
.sh 3 "Sending raw datagrams"
.pp
The format of the \fIsendto()\fR system call is:
.(b
\fC
.TS
tab(+);
l s s.
cc = sendto(s, msg, len, flags, to, tolen)
.T&
l l l.
int+cc,s;
char+*msg;
int+len,flags;
struct sockaddr+*to;
int+to;
.TE
\fR
.)b
\f\fIS\fR is the socket previously created. \fIMsg\fR is a pointer to
the data for the NPDU. CLNP will prepend a header to this data before
transmission. \fILen\fR specifies the number of bytes of data. The
\fIflags\fR parameter is unused and should be zero. \fITo\fR specifies the
NSAP address to be used as the destination address. The size (in bytes)
of \fIto\fR is given in \fItolen\fR. CLNP will automatically insert
the source address based upon the route taken by the packet. The number of
user data bytes transmitted is returned as \fIcc\fR. See \fIsendto(2)\fR
for more information on this system call.
.sh 3 "Receiving raw datagrams"
.pp
The format of the \fIrecvfrom()\fR system call is:
.(b
\fC
.TS
tab(+);
l s s.
cc = recvfrom(s, buf, len, flags, from, fromlen)
.T&
l l l.
int+cc,s;
char+*buf;
int+len,flags;
struct sockaddr+*from;
int+*fromlen;
.TE
\fR
.)b
When used with a CLNP raw socket \fIs\fR, \fIrecvfrom()\fR will read a
NPDU from the CLNS. If no packet is available, the call will block.
\fIBuf\fR specifies a buffer of \fIlen\fR bytes into which the NPDU will
be read. The entire packet, including the header, will be read into the
buffer. The \fIflags\fR parameter is unused, and should be zero. If
\fIfrom\fR is non-zero, the source address of the NPDU is filled in.
\fIFromlen\fR is a value-result parameter, initialized to the size of
the buffer associated with \fIfrom\fR, and modified on return to
indicate the actual size of the address stored there. The total number
of bytes received (header and data) is returned as \fIcc\fR.
See \fIrecvfrom(2)\fR for more information about this system call.
.sh 1 "Connection Oriented Network Service"
.pp
The ARGO Connection Oriented Network Service (CONS) is not a complete
implementation of the
OSI network service.
It is that subset of the OSI network service that is used
by ARGO Transport and by ARGO CLNP.
.\" FIGURE
.so figs/NS_primitives.nr
.pp
.CF
shows which CONS service elements are provided.

39
share/doc/iso/wisc/parts.nr Normal file
View File

@ -0,0 +1,39 @@
.\"$Header: /cvsroot/src/share/doc/iso/wisc/Attic/parts.nr,v 1.1.1.1 1994/06/19 00:07:17 cgd Exp $
.\"$Source: /cvsroot/src/share/doc/iso/wisc/Attic/parts.nr,v $
.\"
.\"
.\" LOOK FOR ALL CASES OF 'writing' (as in, "at this writing")
.\" to be sure you've updated everything before distributing this!
.\"
.\"This file uses -me and tbl macros.
.so macros.nr
.pn 1
.IC
.IF
.(l C
.sz 16
Wisconsin ARGO Kernel Programmer's Guide for
Academic Information Systems 4.3
Current source: argo:/usr/argo/doc/kernel
.sz 8
.)l
.so ../icon/ARGO.nr
.he 'ARGO Kernel Programmer\'s Guide'''
.fo '%''\*(td'
.bp
.\".so intro.nr
.\".so def.nr
.\".so trans_serv.nr
.\".so net_serv.nr
.\".so ipc.nr
.\".so addr.nr
.so trans_design.nr
.\".so net_design.nr
.\".so errors.nr
.\".so debug.nr
.\".so appendix_a.nr
.\".so appendix_b.nr
.\".fo ''Table of Contents''
.bp
.xp

7
share/doc/iso/wisc/preview Executable file
View File

@ -0,0 +1,7 @@
#! /bin/csh -f
echo $argv
set dev=fa
foreach m ($argv)
grn -P$dev $m.grn > $m.nr
ditroff -P$dev $m.nr
end

51
share/doc/iso/wisc/program.nr Normal file
View File

@ -0,0 +1,51 @@
.\"$Header: /cvsroot/src/share/doc/iso/wisc/Attic/program.nr,v 1.1.1.1 1994/06/19 00:07:17 cgd Exp $
.\"$Source: /cvsroot/src/share/doc/iso/wisc/Attic/program.nr,v $
.\"
.\"
.\" FONT CONVENTIONS
.\"
.\" \fIprocedure()\fR
.\" \fIsyscall()\fR
.\" \fImanpage(3)\fR
.\" \fIdata_structure_name\fR
.\" \fC/file/or/directory/name\fR
.\" \fC
.\" section of code
.\" \fR
.\"
.\"
.\" LOOK FOR ALL CASES OF 'writing' (as in, "at this writing")
.\" to be sure you've updated everything before distributing this!
.\"
.\"This file uses -me and tbl macros.
.so macros.nr
.pn 1
.IC
.IF
.(l C
.sz 16
Wisconsin ARGO 1.0 Kernel Programmer's Guide for
Academic Operating Systems 4.3
.sz 8
.)l
.so ../icon/ARGO.nr
.he 'ARGO 1.0 Kernel Programmer\'s Guide'''
.fo '%''December 9, 1988'
.bp
.so intro.nr
.so def.nr
.so trans_serv.nr
.so net_serv.nr
.so ipc.nr
.so addr.nr
.so trans_design.nr
.so net_design.nr
.so eicon.nr
.so errors.nr
.so debug.nr
.so appendix_a.nr
.\" Leave manual pages out!
.\".so appendix_b.nr
.fo ''Table of Contents''
.bp
.xp

1466
share/doc/iso/wisc/trans_design.nr Normal file
View File

File diff suppressed because it is too large Load Diff

692
share/doc/iso/wisc/trans_serv.nr Normal file
View File

@ -0,0 +1,692 @@
.NC "Transport Service Interface"
.sh 1 "General"
.pp
It is assumed that the reader is acquainted with the
set of system calls and library routines that
compose the
Berkeley
Unix interprocess communication service (IPC).
To every extent possible
the ARGO transport service is provided by the same IPC mechanisms
that support
the transport-level services
included in the
AOS distribution.
In some instances, the interface
provided by AOS does not support
the services required by ISO 8073,
so system calls were added to support these services.
It is felt that this is superior to modifying
existing system calls, in order to avoid the
recoding of existing Unix utilities.
.pp
What follows is a description of the system calls
that are used to provide the transport service.
According to Unix custom,
the return value of a system call is 0
if the call succeeds and -1 if
the call fails for any reason.
In the latter case,
the global variable
\fIerrno\fR contains more information
about the error that caused the failure.
In the descriptions of all the system calls for which
this custom is followed,
the return value is named
\fIstatus\fR.
.sh 1 "Connection establishment"
.pp
Establishing a TP connection is similar to
establishing a connection using any other
transport protocol supported by Unix.
The same system calls are used, and the passive open
is required.
Some of the parameters to the system calls differ.
.pp
The following call creates a communication endpoint called a
\fIsocket\fR.
It returns
a positive integer called a
\fIsocket descriptor\fR,
which
will be a parameter in all communication primitives.
.(b
\fC
.TS
tab(+);
l s s s.
s = socket( af, type, protocol )
.T&
l l l.
+int+s,af,type,protocol;
.TE
\fR
.)b
.pp
The \fIaf\fR parameter describes the format of addresses
used in this communication.
Existing formats include AF_INET (DoD Internet addresses),
AF_PUP (Xerox PUP-I Internet addresses), and AF_UNIX
(addresses are Unix file names, for intra-machine IPC only).
TP runs in either the Internet domain or the ISO domain (AF_ISO).
When using the Internet domain, the network layer is the DoD Internet IP
with Internet-style addresses. The ISO domain uses the ISO
network service and ISO-style addresses\**.
.(f
\**ISO/DP 8348/DAD2 Addendum to the Network
Service Definition Covering Network Layer Addressing.
.)f
Regardless of the address family used, an address takes the
general form,
.(b
\fC
.TS
tab(+);
l s s s.
struct sockaddr {
.T&
l l l l.
+short+sa_family;+/* address family */
+char+sa_data[14];+/* space for an address */
}+
.TE
\fR
.)b
.sp 1
When viewed as an Internet address, it takes the form
.(b
\fC
.TS
tab(+);
l s s s.
struct sockaddr_in {
.T&
l l l l.
+short+sin_family;+/* address family */
+u_short+sin_port;+/* internet port */
+struct in_addr+sin_addr;+/* network addr A.B.C.D */
+char+sin_zero[8];+/* unused */
}
.TE
\fR
.)b
.sp 1
When viewed as an ISO address, it takes the form
.(b
\fC
.TS
tab(+);
l s s s.
struct sockaddr_iso {
.T&
l l l l.
+short+siso_family;+/* address family */
+u_short+siso_tsuffix;+/* transport suffix */
+struct iso_addr+siso_addr;+/* ISO NSAP addr */
+char+siso_zero[2];+/* unused */
}
.TE
\fR
.)b
The address described by a \fIsockaddr_iso\fR structure
is a TSAP-address (transport service access point address).
It is made of an NSAP-address (network service access point address)
and a TSAP selector (also called a transport suffix or
transport selector, hereafter called a TSEL).
The structure \fIsockaddr_iso\fR contains a 2-byte TSEL.
This is for compatibility with Internet addressing.
ARGO supports
TSELs of length 1-64 bytes.
TSELs of any length other than 2
are called \*(lqextended TSELs\*(rq.
They are described in detail in the section \fB\*(lqExtended TSELs\*(rq\fR.
If extended TSELs are not requested, 2-byte TSELs are used by default.
.pp
Refer to Chapter Five for more information about ISO NSAP-addresses.
.pp
The \fItype\fR parameter in the \fIsocket()\fR call
distinguishes
datagram protocols, stream protocols, sequenced
packet protocols, reliable datagram protocols, and
"raw" protocols (in other words, the absence of a transport protocol).
Unix provides manifest named constants for each of these types.
TP supports the sequenced packet protocol abstraction, to which
the manifest constant SOCK_SEQPACKET applies.
.pp
The \fIprotocol\fR
parameter is an integer that identifies the protocol to be used.
Unix provides a database of protocol names and their associated
protocol numbers.
Unix also provides user-level tools
for searching the database.
The tools take the form of library routines.
A protocol number for TP has been chosen
by the Internet NIC to allow TP to run in the Internet domain, and this
has been added to the Unix network protocol database.
The standard Internet database tools that serve TCP users
can
also serve user of TP
in the Internet domain, if the TP protocol number is added to the
proper Internet database file,
\fC/etc/protocols\fR.
This change must be made for TP to run in either the Internet or
in the ISO domain.
The ARGO package contains a set of tools and a database
for use with TP in the ISO domain.
This set of tools is described in the manual pages
\fIisodir(5)\fR and
\fIisodir(3)\fR.
.pp
When a socket is created, it is not given an address.
Since a socket cannot be reached by a remote entity unless it has an address,
the user must request that a socket be given an address by
using the \fIbind()\fR system call:
.(b
\fC
.TS
tab(+);
l s s s.
status = bind( s, addr, addrlen )
.T&
l l l.
+int+s;
+struct sockaddr+*addr;
+int+addrlen;
.TE
\fR
.)b
.pp
The address is expected to be in the format specified by the
\fIaf\fR parameter to the \fIsocket()\fR
call that yielded the socket descriptor \fIs\fR.
If the user
passes an address parameter with a zero-valued transport suffix,
the transport layer
assigns an unused 2-byte transport selector.
This is a 4.3 Unix convention; it is not part of any ISO standard.
.pp
The \fIconnect()\fR system call effects an active open.
It is used to establish a connection with an entity that is
passively waiting for connection requests, and whose
transport address is known.
.(b
\fC
.TS
tab(+);
l s s s.
status = connect( s, addr, addrlen )
.T&
l l l.
+int+s;
+struct sockaddr+*addr;
+int+addrlen;
.TE
\fR
.)b
.pp
The first parameter is a socket descriptor.
The \fIaddr\fR parameter is a transport address in the format
specified by the \fIaf\fR parameter to the \fIsocket()\fR
call that yielded the socket descriptor \fIs\fR.
.pp
A passive open is accomplished with two system calls,
\fIlisten()\fR followed by \fIaccept()\fR.
.(b
\fC
.TS
tab(+);
l s s s.
status = listen( s, queuelen )
.T&
l l l.
+int+s;
+int+queuelen;
.TE
\fR
.)b
.pp
The \fIqueuelen\fR argument specifies the maximum
number of pending connection
requests that will be queued for acceptance by this user.
Connections are then accepted by the
system call \fIaccept()\fR.
There is no way to refuse connections.
The functional equivalent of connection
refusal is accomplished by accepting a connection and immediately
disconnecting.
.(b
\fC
.TS
tab(+);
l s s s.
new_s = accept( s, addr, addrlen )
.T&
l l l.
+int+new_s, s;
+struct sockaddr+*addr;
+int+addrlen;
.TE
\fR
.)b
.pp
The \fIaccept()\fR call completes the connection
establishment. If a connection request from a prospective peer
is pending on the socket described by \fIs\fR, it is removed and
a new socket is created for use with this connection.
A socket descriptor for the new socket is returned by the
system call.
If no connection requests are pending, this call blocks.
If the \fIaccept()\fR call fails, -1 is returned.
The transport address of the entity requesting the connection
is returned in the \fIaddr\fR parameter, and the length
of the address is returned in the \fIaddrlen\fR parameter.
The address associated with the new socket is inherited
from the socket on which the \fIlisten()\fR and \fIaccept()\fR were performed.
.pp
It is possible for the \fIaccept()\fR call to be interrupted
by an asynchronous event such as the arrival of expedited
data.
When system calls are interrupted, Unix returns the value -1
to the caller and puts the constant
EINTR in the global variable \fIerrno\fR.
This can create problems with the system call \fIaccept()\fR.
In the case of incoming expedited data, the interruption does
not indicate a problem, but the data may have arrived before
the caller has received the new socket descriptor, which is the
socket descriptor on which the expedited data are to be received.
In order to prevent this problem from occurring, the caller must
prevent the issuance of asynchronous indications until the
\fIaccept()\fR
call has returned.
Asynchronous indications are discussed below, in
the section titled
"Indications from the transport layer to the transport user".
.pp
It is possible to discover the
address bound to a
socket with the
\fIgetsockname()\fR system call.
.(b
\fC
.TS
tab(+);
l s s s.
status = getsockname( s, addr, addrlen )
.T&
l l l.
+int+s;
+struct sockaddr+*addr;
+int+addrlen;
.TE
\fR
.)b
.pp
If the socket has a peer, that is, it is connected,
the system call
\fIgetpeername()\fR
is used to discover the peer's address.
.(b
\fC
.TS
tab(+);
l s s s.
status = getpeername( s, addr, addrlen )
.T&
l l l.
+int+s;
+struct sockaddr+*addr;
+int+addrlen;
.TE
\fR
.)b
.lp
The names returned by
\fIgetsockname()\fR and \fIgetpeername()\fR
do not contain extended TSELs.
Extended TSELs can be retrieved with
the \fIgetsockopt()\fR and
\fIsetsockopt()\fR system calls, described below.
.pp
Unix supports several protocol-independent options
and protocol-specific options
associated with sockets.
These options can be inspected and changed by using
the \fIgetsockopt()\fR and
\fIsetsockopt()\fR system calls.
.(b
\fC
.TS
tab(+);
l s s s.
status = getsockopt( s, level, option, value, valuelen )
.T&
l l l.
+int+s, level, option;
+char+*value;
+int+*valuelen;
.TE
\fR
.)b
.(b
\fC
.TS
tab(+);
l s s s.
status = setsockopt( s, level, option, value, valuelen )
.T&
l l l.
+int+s, level, option;
+char+*value;
+int+valuelen;
.TE
\fR
.)b
.pp
The \fIlevel\fR argument may indicate
either
that this option applies to sockets or that it applies to
a specific protocol.
The constants SOL_SOCKET, SOL_TRANSPORT, and SOL_NETWORK
are possible values for the \fIlevel\fR argument.
The \fIoption\fR argument is an integer that identifies
the option chosen.
.\" LIST THE OPTIONS HERE
The options available to TP users provide the
user with the ability to control various TP protocol options
including but not limited to
TP class, TPDU size negotiated, TPDU format used,
acknowledgment and retransmission strategies.
For a detail list of the options, see the manual page \fItp(4p)\fR.
.sh 1 "Extended TSELs"
.pp
ARGO supports TSELs
of length 1 byte - 64 bytes for sockets bound to addresses in the
AF_ISO address family.
The ARGO user program uses the
\fIgetsockopt()\fR
and
\fIsetsockopt()\fR
system calls to
discover and assign extended TSELs.
.pp
To create a socket with an extended TSEL,
the process
.ip \(bu 5
opens a socket with \fCsocket(AF_ISO, SOCK_SEQPACKET, ISOPROTO_TP)\fR
.ip \(bu 5
binds an NSAP-address to the socket with \fIbind()\fR.
The address bound may contain a 2-byte selector (\fIiso_tsuffix\fR).
.ip \(bu 5
uses \fIsetsockopt()\fR with the command TPOPT_MY_TSEL,
to assign a TSEL to the socket.
.ip \(bu 5
calls \fIlisten(), connect()\fR, or any other appopriate system calls
to use the socket as desired.
.lp
To connect to a transport entity that is bound to a TSAP-address with
an extended TSEL, the
process
.ip \(bu 5
opens a socket with \fCsocket(AF_ISO, SOCK_SEQPACKET, ISOPROTO_TP)\fR
.ip \(bu 5
uses \fIsetsockopt()\fR, with the command TPOPT_PEER_TSEL,
to assign a PEER TSEL to the socket.
This TSEL is used by the transport entity
for all subsequent connect requests made on this socket,
unless the peer TSEL is changed by another call to
\fIsetsockopt()\fR employing the command TPOPT_PEER_TSEL.
.lp
To discover the TSEL of the peer of a connected socket,
the process
.ip \(bu 5
uses \fIgetsockopt()\fR with the command TPOPT_PEER_TSEL.
.lp
To discover the TSEL of socket's own address,
the process
.ip \(bu 5
uses \fIgetsockopt()\fR with the command TPOPT_MY_TSEL.
.sh 1 "Data transfer"
.pp
The system calls provided by AOS for data transfer have
semantics that are unsuitable for TP,
and in fact they are seriously deficient for the correct
operation of any user program that uses out-of-band or expedited
data in any way except to cause the program to abort.
The problem lies in the manner in which the kernel
handles interrupted system calls.
The send and receive primitives
may be interrupted by signals.
A signal is the mechanism used to indicate
the presence of expedited data or out-of-band data.
If the send or receive primitive is interrupted before completion,
the user needs to know how many octets of data were sent or received.
The existing system call interface does not provide this
information, nor does it permit TP to provide
this information.
All forms of the existing interface
(\fIsend()\fR,
\fIrecv()\fR,
\fIsendmsg()\fR,
\fIrecvmsg()\fR,
\fIsendto()\fR,
\fIrecvfrom()\fR,
\fIwrite()\fR,
\fIread\fR,
\fIwritev()\fR,
and \fIreadv()\fR system calls)
return an octet count
when the system call completes, and return an error
indication (-1, \fIerrno\fR == EINTR) if the system call is interrupted.
To change the semantics
of these calls would create havoc with existing user-level software.
Instead two new system calls are provided to support data transfer.
(The existing interface may be used if the user does not need the additional
service provided by the new system calls.)
.pp
The two new system calls are patterned after
\fIreadv()\fR and \fIwritev()\fR,
the scatter-gather or "vectored"
versions of \fIread()\fR and \fIwrite()\fR.
.(b
\fC
.TS
tab(+);
l s s s.
cc = sendv( s, iov, iovlen, flags )
.T&
l l l.
+int+s:
+io_vector+iov;
+int+iovlen;
+unsigned int+*flags;
.TE
\fR
.)b
.(b
\fC
.TS
tab(+);
l s s s.
cc = recvv( s, iov, iovlen, flags )
.T&
l l l.
+int+s:
+io_vector+iov;
+int+iovlen;
+unsigned int+*flags;
.TE
\fR
.)b
.pp
The \fIiov\fR argument is an \fIio_vector\fR,
an array of pointers and lengths that
describe the areas from (or to) which the data will be gathered (or scattered).
The \fIiovlen\fR argument is an integer that tells how many parts are in
the io_vector.
The \fIflags\fR parameter serves several purposes.
The TP specification requires that TSDUs be unlimited in size.
System calls cannot pass unlimited amounts of data between the user
and the kernel, so
there cannot be a one-to-one correspondence between TSDUs and
system calls.
The \fIflags\fR
parameter is used to mark the end-of-TSDU on both sending and
receiving.
This way one TSDU can span several system calls.
When sending,
the user sets
this flag
to indicate that this request completes a TSDU.
When receiving,
TP sets this flag when
the end of a TSDU is reached.
In the latter case, the end of the data received by the transport user
with a given system call
coincides with the end of the TSDU
if
the TP has set the end-of-TSDU bit
in the \fIflags\fR parameter of the \fIrecv()\fR system call.
It is possible for the peer to send an empty TPDU with the end-of-TSDU
flag set, in which case the transport user
may receive zero octets with the end-of-TSDU flag set.
See the manual pages
\fIrecvv(2)\fR
and
\fIsendv(2)\fR
for details.
.pp
The \fIflags\fR parameter also serves to distinguish data transfer primitives
from expedited data transfer primitives.
The flag bit MSG_OOB is provided for "out of band data" in the
DoD Internet protocols. It is also used to provide the expedited data service
of the ISO protocols.
The transport layer will deliver one expedited datum (there will be a
one-to-one correspondence between expedited TSDUs and XPD TPDUs)
at a time.
The user must receive the datum before the transport
layer will accept more expedited data.
Each expedited datum my contain up to 16 octets.
.pp
.sh 1 "Disconnection"
.pp
The \fIclose\fR system call will disconnect any association
between two TP entities.
.(b
\fC
.TS
tab(+);
l s s s.
status = close( s )
.T&
l l l.
+int+s;
.TE
\fR
.)b
.pp
The argument \fIs\fR is a socket descriptor.
If a Unix user process terminates, Unix will close all files and
sockets associated with the process, which means all transport
connections associated with the process will be disconnected.
.sh 1 "Indications from the transport layer to the transport user"
.pp
While the above set of system calls allows you to establish
a connection, transfer data, and disconnect,
several elements of the transport service are not supported
by these system calls alone.
These system calls do not support
any way to indicate to the
to the transport user
the
presence of expedited data or
a disconnection initiated by the peer or by one of the
cooperating TP entities.
.pp
The Unix signal mechanism is used to provide these
service elements.
When an expedited data TSDU arrives, the TP interrupts
the user with a SIGURG signal ("urgent condition present on socket").
The user must have previously registered a procedure to handle
the signal by using the \fIsigvec()\fR system call or the
\fIsignal()\fR library routine provided for that purpose.
The signal handler takes the form
.(b
\fC
.TS
tab(+);
l s s s.
int sighandler( signal_number)
.T&
l l l.
+int+signal_number;
.TE
\fR
.)b
.pp
The \fIsignal_number\fR argument will be the well-known constant SIGURG.
There are two reasons for
the transport layer to issue
a SIGURG:
expedited data
are present or
disconnection was initiated by a transport entity or by the peer.
Should the user have more than one transport connection open,
another system call is used to determine to which socket(s)
the urgent condition applies.
This is the \fIselect()\fR system call, described below.
.pp
When the SIGURG indicates a disconnection, there may be
user data from the peer present.
TP
discards all queued normal data and expedited data.
It saves the disconnect data for the user to receive via the
\fIgetsockopt()\fR system call.
Unfortunately, the socket is already considered closed
by the kernel, so there is no way
for the user to read the incoming disconnect data, so receipt
of disconnect data is not supported.
.\"
.\"If the user does not receive the disconnect data before the
.\"reference timer expires, the data will be discarded and the
.\"socket will be closed.
.pp
Transport service users may use more than one transport
connection at a time.
The \fIselect()\fR system call facilitates this.
.(b
\fC
.TS
tab(+);
l s s s.
#include <sys/types.h>
+
nfound = select( num_to_scan, recvmask, sendmask,
+exceptmask, timeout )
.T&
l l l.
+int+nfound, num_to_scan;
+fd_set+*recvmask, *sendmask, *exceptmask;
+time+timeout;
.TE
\fR
.)b
.pp
This system call takes as parameters a set of masks
that specify a subset of the socket descriptors that are in
use by the user program.
\fISelect()\fR inspects the sockets to see if they have data
to be received, can service a send without blocking, or
have an exceptional condition pending, respectively.
The masks will be set upon return to indicate the socket descriptors
for which the respective conditions exist.
The \fInum_to_scan\fR argument limits the number of sockets that are
inspected.
The call will return within the amount of time given in the
\fItimeout\fR parameter, or, if the parameter is zero, \fIselect()\fR
will block indefinitely.
.\" FIGURE
.so figs/TS_primitives.nr
.pp
.CF
summarizes the mapping of the transport service primitives
to Unix facilities.

118
share/doc/iso/wiscman/arp.4p Normal file
View File

@ -0,0 +1,118 @@
.\" Copyright (c) 1983 Regents of the University of California.
.\" All rights reserved. The Berkeley software License Agreement
.\" specifies the terms and conditions for redistribution.
.\"
.\" @(#)arp.4p 6.2 (Berkeley) 5/15/86
.\"
.TH ARP 4P "May 15, 1986"
.UC 5
.SH NAME
arp \- Address Resolution Protocol
.SH SYNOPSIS
.B "pseudo-device ether"
.SH DESCRIPTION
ARP is a protocol used to dynamically map between DARPA Internet
and 10Mb/s Ethernet addresses. It is
used by all the 10Mb/s Ethernet interface drivers.
It is not specific to Internet protocols or to 10Mb/s Ethernet,
but this implementation currently supports only that combination.
.PP
ARP caches Internet-Ethernet address mappings. When an interface
requests a mapping for an address not in the cache, ARP queues the
message which requires the mapping and broadcasts
a message on the associated network requesting the address mapping.
If a response is provided, the new mapping is cached and any pending
message is transmitted.
ARP will queue
at most one packet while waiting for a mapping request to be responded to;
only the most recently ``transmitted'' packet is kept.
.PP
To facilitate communications with systems which do not use ARP,
.IR ioctl \^s
are provided to enter and delete entries in the Internet-to-Ethernet tables.
Usage:
.LP
.nf
.ft B
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <net/if.h>
struct arpreq arpreq;
ioctl(s, SIOCSARP, (caddr_t)&arpreq);
ioctl(s, SIOCGARP, (caddr_t)&arpreq);
ioctl(s, SIOCDARP, (caddr_t)&arpreq);
.fi
.ft R
Each ioctl takes the same structure as an argument.
SIOCSARP sets an ARP entry, SIOCGARP gets an ARP entry, and SIOCDARP
deletes an ARP entry. These ioctls may be applied to any socket descriptor
.I s,
but only by the super-user.
The
.I arpreq
structure contains:
.LP
.RS
.ta \w'#define\ \ 'u +\w'ATF_USETRAILERS\ \ 'u +\w'0x08\ \ \ \ 'u
.nf
/*
* ARP ioctl request
*/
struct arpreq {
struct sockaddr arp_pa; /* protocol address */
struct sockaddr arp_ha; /* hardware address */
int arp_flags; /* flags */
};
/* arp_flags field values */
#define ATF_COM 0x02 /* completed entry (arp_ha valid) */
#define ATF_PERM 0x04 /* permanent entry */
#define ATF_PUBL 0x08 /* publish (respond for other host) */
#define ATF_USETRAILERS 0x10 /* send trailer packets to host */
.fi
.RE
.LP
The address family for the
.I arp_pa
sockaddr must be AF_INET; for the
.I arp_ha
sockaddr it must be AF_UNSPEC.
The only flag bits which may be written are ATF_PERM, ATF_PUBL
and ATF_USETRAILERS.
ATF_PERM causes the entry to be permanent if the ioctl call succeeds.
The peculiar nature of the ARP tables may cause the ioctl to fail if more
than 8 (permanent) Internet host addresses hash to the same slot.
ATF_PUBL specifies that the ARP code should respond to ARP requests for the
indicated host coming from other machines. This allows a host to act as an
``ARP server,'' which may be useful in convincing an ARP-only machine to talk
to a non-ARP machine.
.PP
ARP is also used to negotiate the use of trailer IP encapsulations;
trailers are an alternate encapsulation used to allow efficient packet
alignment for large packets despite variable-sized headers.
Hosts which wish to receive trailer encapsulations so indicate
by sending gratuitous ARP translation replies along with replies
to IP requests; they are also sent in reply to IP translation replies.
The negotiation is thus fully symmetrical, in that either or both hosts
may request trailers.
The ATF_USETRAILERS flag is used to record the receipt of such a reply,
and enables the transmission of trailer packets to that host.
.PP
ARP watches passively for hosts impersonating the local host (i.e. a host
which responds to an ARP mapping request for the local host's address).
.SH DIAGNOSTICS
.B "duplicate IP address!! sent from ethernet address: %x:%x:%x:%x:%x:%x."
ARP has discovered another host on the local network which responds to
mapping requests for its own Internet address.
.SH SEE ALSO
ec(4), de(4), il(4), inet(4F), arp(8C), ifconfig(8C)
.br
``An Ethernet Address Resolution Protocol,'' RFC826, Dave Plummer,
Network Information Center, SRI.
.br
``Trailer Encapsulations,'' RFC893, S.J. Leffler and M.J. Karels,
Network Information Center, SRI.
.SH BUGS
ARP packets on the Ethernet use only 42 bytes of data; however, the smallest
legal Ethernet packet is 60 bytes (not including CRC).
Some systems may not enforce the minimum packet size, others will.

91
share/doc/iso/wiscman/clnp.4p Normal file
View File

@ -0,0 +1,91 @@
.TH CLNP 4P "9 December 1988"
.ds ]W Wisconsin ARGO 1.0
.UC 4
.SH NAME
clnp \- Connectionless-Mode Network Protocol
.SH SYNOPSIS
.B #include <sys/socket.h>
.br
.B #include <netargo/iso.h>
.br
.B #include <netargo/clnp.h>
.PP
.B s = socket(AF_ISO, SOCK_RAW, 0);
.SH DESCRIPTION
CLNP is the connectionless-mode network protocol used by the
connectionless-mode network service. This protocol is specified in
ISO 8473.
It may be accessed
through a \*(lqraw socket\*(rq for debugging purposes only.
CLNP sockets are connectionless,
and are normally used with the
.I sendto
and
.I recvfrom
calls, though the
.IR connect (2)
call may also be used to fix the destination for future
packets (in which case the
.IR read (2)
or
.IR recv (2)
and
.IR write (2)
or
.IR send (2)
system calls may be used).
.PP
Outgoing packets automatically have a CLNP header prepended to
them. Incoming packets received by the user contain the full CLNP header.
The following \fIsetsockopt\fR options apply to CLNP:
.TP
CLNPOPT_FLAGS
Sets the flags which are passed to clnp when sending a datagram.
Valid flags are:
.nf
.br
CLNP_NO_SEG-Do not allow segmentation
CLNP_NO_ER-Suppress ER pdus
CLNP_NO_CKSUM-Do not generate the CLNP checksum
.br
.fi
.TP
CLNPOPT_OPTS
Sets CLNP options. The options must be formatted exactly as specified by
ISO 8473, section 7.5 "Options Part." Once an option has been set, it will
be sent on all packets until a different option is set.
.SH DIAGNOSTICS
A socket operation may fail with one of the following errors returned:
.TP 15
[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;
.TP 15
[ENOTCONN]
when trying to send a datagram, but
no destination address is specified, and the socket hasn't been
connected;
.TP 15
[ENOBUFS]
when the system runs out of memory for
an internal data structure;
.TP 15
[EADDRNOTAVAIL]
when an attempt is made to create a
socket with a network address for which no network interface
exists;
.TP 15
[EHOSTUNREACH]
when trying to send a datagram, but no route to the destination
address exists.
.TP 15
[EINVAL]
when specifying unsupported options.
.SH SEE ALSO
send(2), recv(2), intro(4N), iso(4F)
.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 CLNP packets.
.PP
No more than MLEN bytes of options can be specified.

241
share/doc/iso/wiscman/cons.4 Normal file
View File

@ -0,0 +1,241 @@
.\"
.\" 5799-WZQ (C) COPYRIGHT IBM CORPORATION 1986,1987,1988
.\" LICENSED MATERIALS - PROPERTY OF IBM
.\" REFER TO COPYRIGHT INSTRUCTIONS FORM NUMBER G120-2083
.\"
.\"$Header: /cvsroot/src/share/doc/iso/wiscman/Attic/cons.4,v 1.1.1.1 1994/06/19 00:07:23 cgd Exp $
.\"$ACIS:cons.4_ca 11.3$
.\"$Source: /cvsroot/src/share/doc/iso/wiscman/Attic/cons.4,v $
.\" This file uses -man macros.
.TH CONS 4 "Sept 1988" "Space overwritten by .AC macro" " "
.AC 1 0
.SH NAME
cons \- keyboard and console display interface
.SH DESCRIPTION
The keyboard and various possible displays combine to
provide a terminal-like
interface to the system. Internally, these are separate devices which
software combines to emulate a normal terminal. See the appropriate manual
pages for information about each display and the keyboard.
.PP
The keyboard adapter also supports the speaker, which is activated
when the ASCII character \fBbel\fP (\fB^G\fP)
is sent to the display with software.
For additional information on speaker control, see \fIspeaker\fP(4).
.PP
.B Console Device Control
.PP
The display devices,
\fI/dev/ttyaed\fR, \fI/dev/ttyap16\fR, \fI/dev/ttyap8c\fR,
\fI/dev/ttyapa8\fR, \fI/dev/ttyega\fR, \fI/dev/ttymono\fR,
\fI/dev/ttympel\fR, \fI/dev/ttyvga\fR, and \fI/dev/tty8514\fR are all
minor devices under
\fI/dev/console\fR, and are all capable of displaying console output.
Unique to this system is the fact that you may have one or more of these
displays on your workstation at a time and any one can act as a console.
With only one keyboard and system mouse, the console driver
multiplexes these input devices to the many displays.
All of the displays may have simultaneous logins and the user
can ``hot key'' between each display.
At first, this
``input focus''
is on
the first device in the above sequence to
be found at initialization time. The input focus
can be manually switched to the next available display by pressing the
default ``hot key'' <Alt><Scroll Lock>.
When the
input focus
is on a display, all keyboard and mouse data are sent to the process(es)
that read from that display.
.PP
If no other console tty device is open, and only the default input
emulator is used (see \fIkbdemul\fP(4)), the input focus is set to
\fI/dev/console\fP. In this case, <Alt><Scroll Lock> only switches
which display gets console output.
In the case where one or more tty devices are open, or the default input
emulator changes, \fI/dev/console\fP gets no input. It tries to send output
to the currently focused device. A user can redirect these console messages
to any tty devices with the TIOCCONS ioctl.
.PP
To support the many displays and the multiplexing between them, an
emulator package was developed to work with the console driver.
This package allows different types of emulation on input and output to
be written independently of device.
.PP
The display devices \fI/dev/aed\fP, \fI/dev/apa16\fP, \fI/dev/apa8c\fP,
\fI/dev/apa8\fP, \fI/dev/ega\fR, \fI/dev/mono\fP,
\fI/dev/mpel\fR, \fI/dev/vga\fR, and \fI/dev/ibm8514\fR
are also minor devices to
\fI/dev/console\fP. They are typically used by window managers and other
graphic applications. When the focus is pointed to one of these display
devices, the console messages are put in a circular buffer
(see \fIbufemul\fP(4))
unless redirected with the TIOCCONS ioctl.
The buffer is flushed to the screen upon closing the display device.
.PP
The following are generic console \fIioctls\fP defined in \fIscreen_cousf.u\fP:
.TP 20
CON_SELECT_SCREEN
Output focus is set to display number (arg > 0) or
to next display in list (arg < 0). Previous display number is returned.
.TP 20
CON_GET_SCREEN
Just returns the current output focus display number.
.TP 20
EIGETD
Gets the number of the current input emulator for this display.
.TP 20
EOGETD
Gets the number of the current output emulator for this display.
.TP 20
EISETD
Sets the input emulator and returns the previous for this display.
.TP 20
EOSETD
Sets the output emulator and returns the previous for this display.
.TP 20
CON_INIT_SCREEN
Initializes the specified display (arg >=0) or this display
(arg < 0).
.TP 20
CON_GET_FOCUS_CODE
Gets the current keyboard code for setting the console
focus (affects xemul only).
.TP 20
CON_SET_FOCUS_CODE
Sets the current keyboard code for setting the console
focus (affects xemul only), and return the previous code.
.PP
All of the above commands take integer arguments.
.PP
The following are generic console \fIioctls\fP defined in \fIconsio.h\fP:
.TP 20
SCRIOCGETF
Gets the screen control flags for the given display number.
.TP 20
SCRIOCSETC
Sets the screen control flags for the given display number.
.PP
.in +10
SCRIOCGETF and SCRIOCSETC use the following structure:
.DT
.nf
struct screen_control {
int device; /* which screen/display to control */
int switches; /* Flags for this screen */
};
.fi
.sp 2
.RS 6
.TP 20
CONSDEV_PRESENT
Display is present on this system.
This bit cannot be changed by SCRIOSETC.
.TP 20
CONSDEV_KERNEL
Display is available to the kernel.
.TP 20
CONSDEV_USER
Display is available to the user.
.TP 20
CONSDEV_INIT
Display has been initialized for output.
.TP 20
CONSDEV_TTY
Diplay has been initialuzed for output.
This bit cannot be changed by SCRIOSETC.
.TP 20
CONSDEV_GRA
Graphics display has been opened directly by minor device number.
This bit cannot be changed by SCRIOSETC.
.TP 20
CONSDEV_NOINPUT
Prevents the "round-robin" console focus-switching from finding this
display. This flag is cleared when \fIbuf_emul\fP is closed.
.TP 20
SCRSETNIP
Sets the no-input bit in the screen control flags for the
display's current file description.
.TP 20
SCRCLRNIP
Clears the no-input bit in the screen control flags for the
display's current file description.
.RE
.PP
The following \fIioctl\fP is defined in \fIbufemul.h\fP:
.TP 20
BUFDISPINFO
\fIArg\fP returns the following information about the display:
.PP
.RS 6
.TP 20
BUF_IS_ATR(arg)
True when the CPU is an IBM 6152 Academic System.
.TP 20
BUF_IS_RTPC(arg)
True when the CPU is an IBM RT PC.
.TP 20
BUF_GET_PCCODE(x)
Get PC-Code version/type byte (IBM 6152 only).
.bp
.TP 20
BUF_GET_VGA(arg)
Get the type of display connected to the VGA.
0=none, 1=color, 2=gray. Valid only for the IBM 6152 Academic System.
.TP 20
BUF_GET_8514(arg)
Get the type of display connected to the IBM 8514/A.
0=none, 1=color, 2=gray. Valid only for the IBM 6152 Academic System.
.TP 20
BUF_GET_EGA(arg)
Returns the value of the switches on the EGA display. Valid only for the IBM RT PC with an EGA card installed.
.RE
.PP
All of the above \fIioctl\fP system calls are device-independent controls
for dealing with the emulators.
.PP
Each emulator has its own set of \fIioctls\fP for its own emulation purposes.
These other \fIiotls\fP are used in window-manager emulators for operations
such as passing/positioning the mouse locator for/on the display.
See the man page for any particular emulator for more information.
.PP
.SH NOTE
On the IBM RT PC, the kernel flashes ``98'' on the LEDs if it cannot find any
configured display during initialization, and then proceeds.
.SH DIAGNOSTICS
None.
.SH FILES
.PP
For the IBM RT PC:
.br
/dev/console
.br
/dev/aed
.br
/dev/apa16
.br
/dev/apa8c
.br
/dev/apa8
.br
/dev/ega
.br
/dev/mono
.br
/dev/mpel
.br
.PP
For the IBM 6152 Academic System:
.br
/dev/vga
.br
/dev/ibm8514
.SH "SEE ALSO"
bufemul(4), bus(4), ibm5081(4), ibm5151(4), ibm6153(4), ibm6154(4),
ibm6155(4), ibm8514(4), ibmaed(4), ibmemul(4), kbdemul(4),
speaker(4), stdemul(4), tty(4), vga(4), xemul(4), setscreen(8)
.br
``IBM/4.3 Console Emulators'', in Volume II, Supplementary Documents

196
share/doc/iso/wiscman/cons.4p Normal file
View File

@ -0,0 +1,196 @@
.TH CONS 4P "9 December 1988"
.ds ]W Wisconsin ARGO 1.0
.UC 4
.SH NAME
CONS \- Connection Oriented Network Service
.SH SYNOPSIS
For use as a network service (CONS):
.nf
.sp
\fB#include <sys/socket.h>\fR
\fB#include <sys/mbuf.h>\fR
\fB#include <netargo/iso.h>\fR
\fB#include <netargo/cons.h>\fR
\fB#include <netargo/iso_errno.h>\fR
.sp
\fBint cons_output(isop, m, len, isdatagram)\fR
.sp
or for use as a subnetwork service (COSNS):
.sp
\fB#include <sys/socket.h>\fR
\fB#include <sys/mbuf.h>\fR
\fB#include <netargo/iso.h>\fR
\fB#include <net/if.h>\fR
\fB#include <netargo/cons.h>\fR
\fB#include <netargo/iso_errno.h>\fR
.sp
\fBint cosns_output(ifp, m, dst)
.fi
.SH DESCRIPTION
.PP
The Connection Oriented Network Service (CONS) implemented for the AOS R2
at the University of Wisconsin - Madison
supports transport protocols, acting as a network service,
and it also supports other network protocols, acting as a subnetwork
service or link-layer service.
Several software modules are combined to provide these services.
.TP 10
X.25
The CCITT X.25 packet layer and link layer protocols run on
a coprocessor (the EICON Network Adapter), which serves as a DTE.
.TP 10
Ecn driver
A device driver manages the interaction between
the coprocessor and the PC/RT.
.TP 10
CONS "glue"
A software module implements portions of the OSI CONS (ISO 8878),
which describes a way to use the X.25 protocols to support the
OSI connection-oriented network service.
.PP
The OSI CONS contains several "service elements"
that ARGO does not use or support.
Expedited data,
quality of service maintenance,
call collision resolution,
permanent virtual circuits,
user data on connect and release,
user-level acknowledgement
("receipt confirmation" in CCITT/ISO argot), and reset/resynchronize
are not supported.
Several of the service primitives for connection establishment
and release are not supported, and
numerous parameters to other primitives specified in the OSI CONS
are not supported.
The CONS glue does provide all the support necessary to run
ISO transport classes 0 and 4 over X.25, and ISO CLNP (also called
ISO IP) over X.25.
The subnetwork dependent convergence functions implemented in the glue
permit interoperability with
OSINET and EAN at this writing.
Interoperability with other networks will be established in the future.
.PP
The coprocessor that implements the X.25 link and packet layers
is the Eicon Technologies Access/X.25 Stand-Alone Network Adaper
(see \fIecn(4)\fR).
.PP
The glue module provides two interfaces to higher layers:
a "subnetwork service" (COSNS) used by network layer protocols, which
has a typical BSD kernel device driver interface
and
a "network service" (CONS) used by transport protocols, which has
a procedure call interface similar to that of IP and CLNP.
.PP
The network service is reliable and sequenced but does not
provide a graceful close service; it provides only an abort service.
.PP
The subnetwork service is neither reliable nor sequenced.
The subnetwork service implemented by the glue hides the
connection-oriented aspects of the protocols; nevertheless,
we call it the "connection-oriented subnetwork service" (COSNS)
here, for lack of a better name.
.SS "LIBRARIES
No libraries are needed to use the CONS, however,
the numerous error values returned by X.25 cannot be accommodated
by the standard \fIperror()\fR in the C library.
The ISO library
.nf
.sp
.in +5
\fC/usr/argo/lib/libisodir.a\fR
.in -5
.sp
.fi
provides an expanded perror() to handle the additional error return codes.
.SS "ERROR VALUES
.PP
The error codes returned by the CONS are taken from
the diagnostic code of the X.25 level 3 packets, as
descibed in figure 14-B of ISO 8208 (the ISO standard which
is equivalent to CCITT X.25).
The actual error value returned in
\fIerrno\fR
is the X.25 diagnostic code in the lower 10 bits
logically "or"ed with the hexadecimal value 0x8400 (bits
10 and 15 set, counting from zero at the the least significant bit).
The error values can be found in
the file
.nf
.in +5
.sp
\fC<netargo/iso_errno.h>\fR
.sp
.in -5
.fi
.SS "PROTOCOL IDENTIFICATION
.PP
The purpose of this section is to describe how incoming packets
are forwarded from the glue to the various higher
layers (ISO transport, CLNP), how
routes are chosen from the higher layers to the glue, and
how NSAP-addresses are related to all this.
.SS Outgoing path:
The ARGO transport entity routes packets either to
the CONS glue, to the CLNP module, or to the DARPA Internet IP
module, based on the value of the network service parameter
given to the transport layer by the user.
The \fInetserv\fR property of records in the ARGO
directory service database
can be used to determine the network service to be used by the
transport layer. See also \fIisodir(5)\fR and \fIisodir(3)\fR.
.PP
The connectionless network layer entity routes packets to the
COSNS based on the routing table entries in the connectionless network layer.
This means that any type of NSAP-address supported by the kernel
may be used with a CLNP packet
that is routed over X.25.
.PP
When the glue creates an X.25 Call Request packet, it
places an X.121 address (DTE address)
in both the Calling and Called DTE address fields.
The X.121 addresses are extracted from the \fISNPA cache\fR,
a table that maps NSAP-addresses to SNPA-addresses, and
is maintained by the ES-IS protocol module of the OSI network layer.
In addition to placing a DTE address in the X.25 packet,
the "glue" may
uses the 1984 Called Address Extension facility to convey the
NSAP-addresses.
Whether or not this is done depends on the compile-time option -DX25_1984.
.SS Incoming path:
The X.25 Call Request User Data field and the
1984 X.25 Address Extension Facility are used
to determing the incoming path through the network layer.
The NSAP addresses passed up along with the packet are taken from the
Address Extension facility, if present.
If the facility is absent, the glue creates two type-37 NSAP-addresses,
filling in the X.121 address from the called and
calling DTE-addresses on the Call Request packet, if present.
The glue then requests of the ES-IS module to add an entry to the
SNPA cache to associate the calling DTE address with its
derived NSAP-address.
These cache entries have a holding of 5 minutes, and get
refreshed as long as there is activity on the virtual circuit
resulting from the call request.
.PP
If a Call Request packet contains a protocol identifier
as described in ISO PTDR 9577, this protocol identifier is used
to route the packet to the higher layers.
If there is no protocol identifier, the higher layer is assumed to be ISO
transport.
.SH "BUGS
.PP
If an incoming X.25 Call Request contains no DTE-addresses and
no NSAP-addresses (in the Address Extension facility)
the kernel panics.
.SH "SEE ALSO
.PP
isodir(3),
ecn(4),
clnp(4),
tp(4),
isodir(5),
isoroute(8),
ifconfig(8),
netstat(1),
xstat(8),
"ARGO 1.0 Kernel Programmer's Manual"

136
share/doc/iso/wiscman/if.4n Normal file
View File

@ -0,0 +1,136 @@
#
# 5799-WZQ (C) COPYRIGHT IBM CORPORATION 1988
# LICENSED MATERIALS - PROPERTY OF IBM
# REFER TO COPYRIGHT INSTRUCTIONS FORM NUMBER G120-2083
#
.\"# $Header: /cvsroot/src/share/doc/iso/wiscman/Attic/if.4n,v 1.1.1.1 1994/06/19 00:07:23 cgd Exp $
.\"# $ACIS:if.4n_ca 1.5$
.\"# $Source: /cvsroot/src/share/doc/iso/wiscman/Attic/if.4n,v $
.\" @(#)if.4n 1.2 87/08/23 3.2/4.3NFSSRC
.\" @(#)if.4n 1.2 87/02/10 NFSSRC
.\" @(#)if.4n 1.1 86/09/25 SMI;
.TH IF 4N "Sept 1988" "Space overwritten" " "
.AC 1 0
.SH NAME
if \- general properties of network interfaces (NFS only)
.SH DESCRIPTION
.IX "if device" "" "\fLif\fP \(em network interface general properties" "" PAGE START
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, but
certain interfaces, such as the loopback interface
.IR lo (4),
do not.
.LP
At boot time each interface which has underlying hardware support
makes itself known to the system during the autoconfiguration
process. Once the interface has acquired its address it is
expected to install a routing table entry so that messages may
be routed through it. Most interfaces require some part of
their address specified with an SIOCSIFADDR ioctl before they
will allow traffic to flow through them. On interfaces where
the network-link layer address mapping is static, only the
network number is taken from the ioctl; the remainder is found
in a hardware specific manner. On interfaces which provide
dynamic network-link layer address mapping facilities (for example,
10Mb/s Ethernets using
.IR arp (4P),),
the entire address specified in the ioctl is used.
.LP
The following
.I ioctl
calls may be used to manipulate network interfaces. Unless
specified otherwise, the request takes an
.I ifreq
structure as its parameter. This structure has the form
.RS
.nf
struct ifreq {
char ifr_name[16]; /* name of interface (e.g. "ec0") */
union {
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
short ifru_flags;
} 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_flags ifr_ifru.ifru_flags /* flags */
};
.fi
.RE
.IP SIOCSIFADDR 5
.IX "ioctls for sockets" "SIOCSIFADDR" "\fLioctl\fP's for sockets" "\fLSIOCSIFADDR\fP \(em set ifnet address"
.IX "SIOCSIFADDR set ifnet address" "" "\fLSIOCSIFADDR\fP \(em set ifnet address"
.IX set "ifnet address ioctl \(em \fLSIOCSIFADDR\fP"
.IX "network interface ioctls" SIOCSIFADDR "network interface \fLioctl\fP's" "\fLSIOCSIFADDR\fP \(em set ifnet address"
Set interface address. Following the address
assignment, the ``initialization'' routine for
the interface is called.
.IP SIOCGIFADDR
.IX "ioctls for sockets" "SIOCGIFADDR" "\fLioctl\fP's for sockets" "\fLSIOCGIFADDR\fP \(em get ifnet address"
.IX "SIOCGIFADDR get ifnet address" "" "\fLSIOCGIFADDR\fP \(em get ifnet address"
.IX get "ifnet address \fLioctl\fP \(em \fLSIOCGIFADDR\fP"
.IX "network interface ioctls" SIOCGIFADDR "network interface \fLioctl\fP's" "\fLSIOCGIFADDR\fP \(em get ifnet address"
Get interface address.
.IP SIOCSIFDSTADDR
.IX "ioctls for sockets" "SIOCSIFDSTADDR" "\fLioctl\fP's for sockets" "\fLSIOCSIFDSTADDR\fP \(em set p-p address"
.IX "SIOCSIFDSTADDR set p-p address" "" "\fLSIOCSIFDSTADDR\fP \(em set p-p address"
.IX set "p-p address ioctl \(em \fLSIOCSIFDSTADDR\fP"
.IX "network interface ioctls" SIOCSIFDSTADDR "network interface \fLioctl\fP's" "\fLSIOCSIFDSTADDR\fP \(em set p-p address"
Set point to point address for interface.
.IP SIOCGIFDSTADDR
.IX "ioctls for sockets" "SIOCGIFDSTADDR" "\fLioctl\fP's for sockets" "\fLSIOCGIFDSTADDR\fP \(em get p-p address"
.IX "SIOCGIFDSTADDR get p-p address" "" "\fLSIOCGIFDSTADDR\fP \(em get p-p address"
.IX get "p-p address \fLioctl\fP \(em \fLSIOCGIFDSTADDR\fP"
.IX "network interface ioctls" SIOCGIFDSTADDR "network interface \fLioctl\fP's" "\fLSIOCGIFDSTADDR\fP \(em get p-p address"
Get point to point address for interface.
.IP SIOCSIFFLAGS
.IX "ioctls for sockets" "SIOCSIFFLAGS" "\fLioctl\fP's for sockets" "\fLSIOCSIFFLAGS\fP \(em set ifnet flags"
.IX "SIOCSIFFLAGS set ifnet flags" "" "\fLSIOCSIFFLAGS\fP \(em set ifnet flags"
.IX set "ifnet flags ioctl \(em \fLSIOCSIFFLAGS\fP"
.IX "network interface ioctls" SIOCSIFFLAGS "network interface \fLioctl\fP's" "\fLSIOCSIFFLAGS\fP \(em set ifnet flags"
Set interface flags field. If the interface is marked down,
any processes currently routing packets through the interface
are notified.
.IP SIOCGIFFLAGS
.IX "ioctls for sockets" "SIOCGIFFLAGS" "\fLioctl\fP's for sockets" "\fLSIOCGIFFLAGS\fP \(em get ifnet flags"
.IX "SIOCGIFFLAGS get ifnet flags" "" "\fLSIOCGIFFLAGS\fP \(em get ifnet flags"
.IX get "ifnet flags \fLioctl\fP \(em \fLSIOCGIFFLAGS\fP"
.IX "network interface ioctls" SIOCGIFFLAGS "network interface \fLioctl\fP's" "\fLSIOCGIFFLAGS\fP \(em get ifnet flags"
Get interface flags.
.IP SIOCGIFCONF
.IX "ioctls for sockets" "SIOCGIFCONF" "\fLioctl\fP's for sockets" "\fLSIOCGIFCONF\fP \(em get ifnet list"
.IX "SIOCGIFCONF get ifnet list" "" "\fLSIOCGIFCONF\fP \(em get ifnet list"
.IX get "ifnet list \fLioctl\fP \(em \fLSIOCGIFCONF\fP"
.IX "network interface ioctls" SIOCGIFCONF "network interface \fLioctl\fP's" "\fLSIOCGIFCONF\fP \(em get ifnet list"
Get interface configuration list. This request takes an
.I ifconf
structure (see below) as a value-result parameter. The
.I ifc_len
field should be initially set to the size of the buffer
pointed to by
.IR ifc_buf .
On return it will contain the length, in bytes, of the
configuration list.
.RS
.nf
/*
* 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 */
};
.RE
.fi
.IX "if device" "" "\fLif\fP \(em network interface general properties" "" PAGE END
.SH "SEE ALSO
arp(4P), ec(4S), lo(4)

87
share/doc/iso/wiscman/iso.4f Normal file
View File

@ -0,0 +1,87 @@
.TH ISO 4F "9 December 1988"
.ds ]W Wisconsin ARGO 1.0
.UC 4
.SH NAME
iso \- ISO protocol family
.SH SYNOPSIS
.B #include <sys/types.h>
.br
.B #include <netargo/iso.h>
.SH DESCRIPTION
The ISO protocol family is a collection of protocols
that uses the ISO address format.
The ISO family provides protocol support for the
SOCK_SEQPACKET abstraction through the TP protocol (ISO 8073),
and for the SOCK_RAW abstraction
by providing direct access (for debugging) to the
CLNP (ISO 8473) network layer protocol.
.SH ADDRESSING
ISO addresses are based upon ISO 8348/AD2,
"Addendum to the Network Service Definition Covering Network Layer Addressing."
.PP
Sockets bound to the OSI protocol family use
the following address structure:
.sp 1
.nf
._f
struct sockaddr_iso {
short siso_family;
u_short siso_tsuffix;
struct iso_addr siso_addr;
};
.sp 1
.fi
.PP
This fields of this structure are:
.TP 10
\fIsiso_family:\fR
Identifies the domain: AF_ISO or AF_INET.
.TP 10
\fIsiso_tsuffix:\fR
The transport part of the address, described below.
.TP 10
\fIsiso_addr:\fR
The network part of the address, described below.
.SS TRANSPORT ADDRESSING
.PP
The above structure describes a simple form of
ISO \fItransport\fR addresses.
An 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 \fIport\fR.
In the ISO domain, this is called a \fItransport selector\fR
(also known at one time as a \fItransport suffix\fR).
While ports are always 16 bits,
transport selectors may be
of (almost) arbitrary size.
ARGO supports two forms of transport selectors:
"normal" or 16-bit selectors, and
"extended" selectors, or selectors that may be from 1-64 bytes
in length.
The default mode of operation is to use 16-bit transport selectors.
These addresses can be represented with the above structure.
When transport selectors of any other size are used, the transport
selector is kept in a separate structure.
See the manual page \fItp(4p)\fR.
.SS NETWORK ADDRESSING
.PP
ISO network addresses are limited to 20 bytes in length.
ISO network addresses can take any format.
ARGO 1.0 supports three formats.
See \fIisodir(3)\fR and \fIisodir(5)\fR.
.SH PROTOCOLS
The ARGO 1.0 implementation of the
ISO protocol family comprises
the Connectionless-Mode Network Protocol (CLNP),
and the Transport Protocol (TP), classes 4 and 0,
and X.25.
TP is used to support the SOCK_SEQPACKET
abstraction.
A raw interface to CLNP is available
by creating an ISO socket of type SOCK_RAW.
This is used for CLNP debugging only.
.SH SEE ALSO
tp(4P), cons(4p), clnp(4P), isodir(3), iso(4f), isodir(5),
"The ARGO 1.0 Kernel Programmer's Guide",
"Installing ARGO 1.0 on Academic Operating Systems 4.3 Release 2"

90
share/doc/iso/wiscman/rvd.4p Normal file
View File

@ -0,0 +1,90 @@
.\"
.\" 5799-WZQ (C) COPYRIGHT IBM CORPORATION 1986,1987,1988
.\" LICENSED MATERIALS - PROPERTY OF IBM
.\" REFER TO COPYRIGHT INSTRUCTIONS FORM NUMBER G120-2083
.\"
.\"$Header: /cvsroot/src/share/doc/iso/wiscman/Attic/rvd.4p,v 1.1.1.1 1994/06/19 00:07:23 cgd Exp $
.\"$ACIS:rvd.4p_ca 11.0$
.\"$Source: /cvsroot/src/share/doc/iso/wiscman/Attic/rvd.4p,v $
.\"This file contains -man macros.
.TH RVD 4P "July 1987" "Space overwritten by .AC macro" " "
.AC 1 0
.SH NAME
rvd \- Remote Virtual Disk protocol
.SH DESCRIPTION
RVD
is a network service which allows several
physical machines to share one
physical mass storage device such as a hard disk. The basic
concept is to have the machine to which the device is physically attached
act as a server to read and write blocks for all the other
machines desiring use of the resource.
.PP
The server program apportions the
physical blocks into \*(lqvirtual disk packs\*(rq based on a
table maintained with
.IR vddb (8).
The packs can then be used separately by clients. There are
three modes of use: read-only, shared, and exclusive.
Exclusive mode is used for
read-write access, while read-only mode is as it sounds.
Shared mode is not supported under IBM/4.3.
If a disk pack is \*(lqspun up\*(rq in read-only mode,
several clients may share the pack and read its information. In
exclusive mode, one client has exclusive use of the disk pack.
.PP
Packs are \*(lqspun up\*(rq and \*(lqspun down\*(rq with the
.I up
and
.I down
commands (see
.IR up (1)).
This can be done
at reboot time within
.I /etc/rc.local
(see
.IR rc (8))
or
at login time within
.I ~/.login
(see
.IR csh (1)).
Once a pack is spun up, it behaves like a disk physically attached to
the local machine (excepting network latency).
The client can do anything desired with the pack;
both MS-DOS and UNIX operating system file systems have
been used on the same physical
drive at the same time (on separate packs, of course).
.PP
RVD
is implemented in two parts: server code and client code. The server
code is written as a
.IR "user process" ,
i.e. it does not require any special
privileges beyond read/write access to the disks it manages. The server
opens a network socket and listens for UDP connections. It also accepts
all
RVD
packets and acts on them.
RVD is a protocol different from both
UDP and TCP,
although similar in nature to the former.
.PP
The client code is implemented as a pseudo-device and corresponding
device driver in the kernel. It can handle up to 10
remote virtual disks
simultaneously, which are associated with the pseudo-devices below.
.SH FILES
.DT
/dev/vd[0-9]a block special file pseudo-device
.br
/dev/rvd[0-9]a character special file pseudo-device
.SH "SEE ALSO"
up(1), rvddb(5), rvdtab(5),
rvdflush(8), rvdchlog(8), rvddown(8),
rvdexch(8), rvdflush(8), rvdlog(8), rvdsend(8), rvdshow(8),
rvdshut(8), rvdsrv(8), savervd(8),
spinup(8), vddb(8), vdstats(8)
.br
``The Remote Virtual Disk System'' in Volume II, Supplementary Documents

609
share/doc/iso/wiscman/tp.4p Normal file
View File

@ -0,0 +1,609 @@
.TH TP 4P "9 December 1988"
.ds ]W Wisconsin ARGO 1.0
.UC 4
.SH NAME
TP \- ISO Transport Protocol
.SH SYNOPSIS
.nf
\fB#include <sys/socket.h>\fR
\fB#include <netargo/iso_errno.h>\fR
\fB#include <netargo/tp_param.h>\fR
\fB#include <netargo/tp_user.h>\fR
.PP
\fBs = socket( [ AF_INET, AF_ISO ] , SOCK_SEQPACKET, 0);\fR
.SH DESCRIPTION
.PP
The ISO Transport Protocol implemented for AOS R2
at the University of Wisconsin - Madison
includes classes 0 and 4
of the ISO transport protocols
as specified in
the September 1984 version of DIS 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 ISO domain.
Class 4 may be used in the Internet domain as well as in the ISO domain.
.PP
The user interface to this protocol is the Berkeley interprocess communication
interface (see \fIsocket(2)\fR.)
Two new system calls for sending and receiving
were added to this interface to
to permit the support the end-of-transport-service-data-unit (EOTSDU)
indication.
See \fIsendv(2)\fR and \fIrecvv(2)\fR.
If the EOTSDU is not needed, the Berkeley 4.3BSD interface
can be used.
See \fIsend(2)\fR and \fIrecv(2)\fR.
.PP
Through the
\fIgetsockopt\fR and \fIsetsockopt\fR
system calls,
TP supports several options
to control such things as negotiable options
in the protocol and protocol strategies.
.\"These system calls are used
.\"to submit data for inclusion on connect and disconnect TPDUs.
The options are defined in \fB<netargo/tp_user.h>\fR,
and are described below.
.\".PP
.\"The options marked with a percent sign ( \fB%\fR )
.\"are limited to use by the super-user.
.PP
In the tables below,
the options marked with a pound sign ( \fB#\fR )
may be used
with \fIsetsockopt()\fR
after a connection is established.
Others must be used before the connection
is established, in other words,
before calling
\fIconnect()\fR or
\fIaccept()\fR.
All options may be used
with \fIgetsockopt()\fR
before or
after a connection is established.
.\"
.\" .PP
.\" The options marked with an exclamation point ( \fB!\fR )
.\" may be used after a connection is released,
.\" but before
.\" the TP reference timer (which generally
.\" has a value in minutes) expires, and before
.\" a \fIclose()\fR system call.
.\" In other words, these commands may be used when the peer closes
.\" a connection (possibly causing a disconnect indication), as long as the command
.\" is issued "soon" after the disconnection occurred.
.\" 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 \fIclose()\fR.
.\" .PP
.\" The implementation of data on connect and disconnect is incomplete
.\" and is not supported.
.sp 1
.TP 25
\fBName\fR
\fBValue [default]\fR
.IP
\fBDescription\fR
.\".TP 25
.\"TPOPT_CONN_DATA
.\"(char *) [none]
.\".IP
.\"Data to send on \fIconnect()\fR.
.\".TP 25
.\"TPOPT_DISC_DATA\fB # !\fR
.\"(char *) [none]
.\".IP
.\"Data to send on \fIclose()\fR.
.\".TP 25
.\"TPOPT_CDDATA_CLEAR\fB #\fR
.\"No associated value.
.\".IP
.\"Erase outgoing connect or disconnect data.
.TP 25
TPOPT_MY_TSEL\fB \fR
1-64 bytes.
.IP
An "extended" transport selector (tsel) for this socket.
This option is used to set or get the local tsel.
When this option is used to set a tsel,
the default the 2-byte tsel
that may have been allocated by \fIbind()\fR
is retained, but this "extended" tsel is the
tsel that is transmitted in a connection request
When this option is used to get a tsel,
it will return whatever transport tsel exists;
if no "extended" tsel was given to this socket,
the 2-byte tsel is returned.
.TP 25
TPOPT_PEER_TSEL\fB \fR
1-64 bytes.
.IP
An "extended" transport selector (tsel) for the
peer transport entity.
This option is used to get the peer's tsel after
a connection is established.
When used before a connection
is established, this option can set the tsel that
will be transmitted as the "called" tsel
in a connection request.
.TP 25
TPOPT_PERF_MEAS\fB #\fR
Boolean.
.IP
When \fBtrue\fR, 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 ARGO
implementation, this will cause performance measurement to be
turned on
on the passive side as well.
See \fItpperf(8)\fR.
.TP 25
TPOPT_PSTATISTICS\fB\fR
No associated value on input.
On output, struct tp_pmeas.
.IP
This command is used to read the performance statistics accumulated
during a connection's lifetime.
It can only be used with \fIgetsockopt()\fR.
The structure it returns is described in \fB<netargo/tp_stat.h>\fR.
See \fItpperf(8)\fR.
.TP 25
TPOPT_FLAGS
unsigned integer. [ 0x0 ]
.IP
This command can only be used with \fIgetsockopt()\fR.
See the description of the flags below.
.TP 25
TPOPT_PARAMS\fB\fR
struct tp_conn_param.
.IP
Used to get or set a group parameters for a connection.
The struct tp_conn_param is the argument used with the
\fIgetsockopt()\fR or \fIsetsockopt()\fR system call.
It is described in
\fB<netargo/tp_user.h>\fR.
.PP
The fields of the \fItp_conn_param\fR structure are
described below.
.nf
.sp 1
\fIValues for TPOPT_PARAMS:\fR
.fi
.TP 25
\fBField\fR
\fBValue [default]\fR
.IP
\fBDescription\fR
.\" ******************8
.TP 25
p_Nretrans
nonzero short integer [ 1 ]
.IP
Number of times a TPDU will be retransmitted before the
local TP entity closes a connection.
.\" ******************8
.TP 25
p_dr_ticks
nonzero short integer [ various ]
.IP
Number of clock ticks between retransmissions of disconnect request TPDUs.
.\" ******************8
.TP 25
p_dt_ticks
nonzero short integer [ various ]
.IP
Number of clock ticks between retransmissions of data TPDUs.
This parameter applies only to class 4.
.\" ******************8
.TP 25
p_cr_ticks
nonzero short integer [ various ]
.IP
Number of clock ticks between retransmissions of connection request TPDUs.
.\" ******************8
.TP 25
p_cc_ticks
nonzero short integer [ various ]
.IP
Number of clock ticks between retransmissions of connection confirm TPDUs.
This parameter applies only to class 4.
.\" ******************8
.TP 25
p_x_ticks
nonzero short integer [ various ]
.IP
Number of clock ticks between retransmissions of expedited data TPDUs.
This parameter applies only to class 4.
.\" ******************8
.TP 25
p_sendack_ticks
nonzero short integer [ various ]
.IP
Number of clock ticks that the local TP entity
will wait before sending an acknowledgment for normal data
(not applicable if the acknowlegement strategy is TPACK_EACH).
This parameter applies only to class 4.
.\" ******************8
.TP 25
p_ref_ticks
nonzero short integer [ various ]
.IP
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
ARGO implementation, despite the fact that
the frozen reference function is required only for
class 4.
.\" ******************8
.TP 25
p_inact_ticks
nonzero short integer [ various ]
.IP
Number of clock ticks without an incoming packet from the peer after which
TP close the connection.
This parameter applies only to class 4.
.\" ******************8
.TP 25
p_keepalive_ticks
nonzero short integer [ various ]
.IP
nonzero short integer [ various ]
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.
.\" ******************8
.TP 25
p_winsize
short integer between 128 and 16384. [4096 bytes]
.IP
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.
.\" ******************8
.TP 25
p_tpdusize
unsigned char between 0x7 and 0xd.
[ 0xc for class 4 ] [ 0xb for class 0 ]
.IP
Log 2 of the maximum TPDU size to be negotiated.
The TP standard (ISO 8473) gives an upper bound of
0xd for class 4 and 0xb for class 0.
The ARGO implementation places upper bounds of
0xc on class 4 and 0xb on class 0.
.\" ******************8
.TP 25
p_ack_strat
TPACK_EACH or TPACK_WINDOW. [ TPACK_WINDOW ]
.IP
This parameter applies only to class 4.
Two acknowledgment strategies are supported:
.IP
TPACK_EACH means that each data TPDU is acknowledged
with an AK TPDU.
.IP
TPACK_WINDOW
means that upon receipt of the packet that represents
the high edge of the last window advertised, and AK TPDU is generated.
.\" ******************8
.TP 25
p_rx_strat
4 bit mask
[ TPRX_USE_CW | TPRX_FASTSTART over
connectionless network protocols ]
[ TPRX_USE_CW over
connection-oriented network protocols ]
.IP
This parameter applies only to class 4.
The bit mask may include the following values:
.IP
TPRX_EACH: When a retransmission timer expires, retransmit
each packet in the send window rather than
just the first unacknowledged packet.
.IP
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.
.IP
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 real peer's window 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.
.\" ******************8
.TP 25
p_class
5 bit mask
[ TP_CLASS_4 | TP_CLASS_0 ]
.IP
Bit mask including one or both of the values TP_CLASS_4 and TP_CLASS_0.
The higher class indicated is the preferred class.
If only one class is indicated, negotiation will not occur
during connection establishment.
.\" ******************8
.TP 25
p_xtd_format
Boolean.
[ false ]
.IP
Boolean indicating that extended format shall be negotiated.
This parameter applies only to class 4.
.\" ******************8
.TP 25
p_xpd_service
Boolean.
[ true ]
.IP
Boolean indicating that
the expedited data transport service will be negotiated.
This parameter applies only to class 4.
.\" ******************8
.TP 25
p_use_checksum
Boolean.
[ true ]
.IP
Boolean indicating the the use of checksums will be negotiated.
This parameter applies only to class 4.
.\" ******************8
.TP 25
p_use_nxpd
Reserved for future use.
.\" ******************8
.TP 25
p_use_rcc
Reserved for future use.
.\" ******************8
.TP 25
p_use_efc
Reserved for future use.
.\" ******************8
.TP 25
p_no_disc_indications
Boolean.
[ false ]
.IP
Boolean indicating that the local TP entity shall not issue
indications (signals) when a TP connection is disconnected.
.\" ******************8
.TP 25
p_dont_change_params
Boolean.
[ false ]
.IP
If \fBtrue\fR the TP entity will not override
any of the other values given in this structure.
If the values cannot be used, the TP entity will drop, disconnect,
or refuse to establish the connection to which this structure pertains.
.\" ******************8
.TP 25
p_netservice
One of { ISO_CLNS, ISO_CONS, ISO_COSNS, IN_CLNS }.
[ ISO_CLNS ]
.IP
Indicates which network service is to be used.
.IP
ISO_CLNS indicates the connectionless network service provided
by CLNP (ISO 8473).
.IP
ISO_CONS indicates the connection-oriented network service provided
by X.25 (ISO 8208) and ISO 8878.
.IP
ISO_COSNS indicates the
connectionless network service running over a
connection-oriented subnetwork service : CLNP (ISO 8473) over X.25 (ISO 8208).
.IP
IN_CLNS indicates the
DARPA Internet connectionless network service provided by IP (RFC 791).
.\" ******************8
.TP 25
p_dummy
Reserved for future use.
.sp 1
.PP
The TPOPT_FLAGS option is used for obtaining
various boolean-valued options.
Its meaning is as follows.
The bit numbering used is that of the PC/RT, which means that bit
0 is the most significant bit, while bit 8 is the least significant bit.
.nf
.sp 1
\fIValues for TPOPT_FLAGS:\fR
.fi
.TP 10
\fBBits\fR
\fBDescription [Default]\fR
.TP 10
0
TPFLAG_NLQOS_PDN : set when the quality of the
network service is
similar to that of a public data network.
.TP 10
1
TPFLAG_PEER_ON_SAMENET : set when the peer TP entity
is considered to be on the same network as the local
TP entity.
.TP 10
2
Not used.
.TP 10
3
TPFLAG_XPD_PRES : set when expedited data are present
[ 0 ]
.TP 10
4..7
Reserved.
.\".TP 10
.\"4
.\"Reserved.
.\".TP 10
.\"5
.\"TPFLAG_DISC_DATA_IN : read only flag, if set indicates that
.\"data from a disconnect TPDU are present.
.\".TP 10
.\"6
.\"Reserved.
.\".TP 10
.\"7
.\"TPFLAG_CONN_DATA_IN : read only flag, if set indicates that
.\"data from a connect TPDU are present.
.SH "LIBRARIES
.PP
The new system calls \fIrecvv\fR and \fIsendv\fR are supported by a
library, \fIlibtp.a\fR (rather than a modified C library).
Also in this
library are new optional interfaces to the \fIconnect\fR and \fIaccept\fR
system calls. See LIBTP(3).
.SH FILES
.PP
The following files in have entries necessary for the correct operation
of the TP utilities.
.nf
\fC
/etc/isodir
/etc/protocols
\fR
.fi
.PP
The symbolic link is needed for users to write programs using IPC
with TP:
.nf
\fC
/usr/include/netargo@ -> /sys/netargo
\fR
.fi
.PP
The following utilities have changed:
.nf
netstat
ifconfig
config
.fi
.PP
The following are new utilities and daemons:
.nf
isoroute
rlogin.iso, rcp.iso, rsh.iso, isod, rlogind
tpdiscard
tpping
tppt (for maintenance and debugging)
bark (for maintenance and debugging)
tpfileget, tpfileput (for debugging)
tpstat, tpmon
tpset
tppkt
viid
.fi
.PP
In the kernel source, many files have changed or been added.
For a list of these, see the installation guide,
"Installing Wisconsin ARGO 1.0 on Academic Operating System 4.3
Release 2".
.SH "ERROR VALUES
.PP
The TP entity returns \fIerrno\fR error values as defined in
\fB<sys/errno.h>\fR
and
\fB<netargo/iso_errno.h>\fR.
User programs may print messages associated with these value by
using an expanded version of \fIperror()\fR
found in the ISO library, \fIlibisodir.a\fR.
.PP
If the 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 TP entity issues a 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
\fIerrno\fR value upon return from the system call is EINTR.
If the signal SIGURG
is being handled by reading
from the socket, and it was a \fIaccept()\fR that
timed out, the read may result in ENOTSOCK,
because the \fIaccept()\fR call had not yet returned a
legitimate socket descriptor when the signal was handled.
ETIMEDOUT (or a some other errno value appropriate to the
type of error) is returned if SIGURG is blocked
for the duration of the system call.
A user program should take one of the following approaches:
.IP "Block SIGURG." 5
If the program is servicing
only one connection, it can block or ignore SIGURG during connection
establishment.
The advantage of this is that the \fIerrno\fR 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.
.IP "Handle SIGURG." 5
If the program is servicing more than one connection at a time
or expedited data may arrive or both, the program must
service SIGURG.
It can use the \fIgetsockopt(...TPOPT_FLAGS...)\fR system
call to see if the signal
was due to the arrival of expedited data or due to a disconnection.
In the latter case,
\fIgetsockopt()\fR
will return ENOTCONN.
.SH BUGS
.PP
When running TP over the token ring, if checksumming
is NOT used, the TP entity sents packets to the lan driver faster than
the driver can reasonably handle them.
A bug in the lan driver causes it to reorder the packets in this
situation, causing an overall degradation of TP performance.
In general, this is not a problem because very few applications
will actually be able to send packets this fast.
Nevertheless,
in order to prevent this reordering,
one may induce a delay in the TP entity by setting the 1-byte
value
\fItp_delay\fR
to 1
using the debugger.
Hit the <pause> key, then
type \fB/b tp_delay\fR followed by the <enter key>.
The debugger will print the value 00.
You then type \fB1\fR followed by the <enter key>.
Then type \fBend\fR <enter key>.
Then type \fBgo\fR <enter key>.
.SH SEE ALSO
.PP
tcp(4P), sendv(2), recvv(2), libtp(3),
isodir(3), isodir(5), netstat(1),
iso(4F), clnp(4P), viid(8)
tppt(8), tpstat(8), bark(8), tppkt(8), tpset(8), tpperf(8)
isoroute(8), ifconfig(8), isod(8), rlogin.iso(1),
"Installing Wisconsin ARGO 1.0 on Academic Operating System 4.3
Release 2",
"ARGO 1.0 Kernel Programmer's Manual"

7
share/doc/papers/beyond4.3/Makefile Normal file
View File

@ -0,0 +1,7 @@
# @(#)Makefile 5.2 (Berkeley) 6/8/93
DIR= papers/beyond43
SRCS= beyond43.ms
MACROS= -ms
.include <bsd.doc.mk>

518
share/doc/papers/beyond4.3/beyond43.ms Normal file
View File

@ -0,0 +1,518 @@
.\" Copyright (c) 1989 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.
.\"
.\" @(#)beyond43.ms 5.1 (Berkeley) 6/5/90
.\"
.\" *troff -ms
.rm CM
.sp 2
.ce 100
\fB\s+2Current Research by
The Computer Systems Research Group
of Berkeley\s-2\fP
.ds DT "February 10, 1989
.\" \fBDRAFT of \*(DT\fP
.sp 2
.nf
Marshall Kirk McKusick
Michael J Karels
Keith Sklower
Kevin Fall
Marc Teitelbaum
Keith Bostic
.fi
.sp 2
.ce 1
\fISummary\fP
.ce 0
.PP
The release of 4.3BSD in April of 1986 addressed many of the
performance problems and unfinished interfaces
present in 4.2BSD [Leffler84] [McKusick85].
The Computer Systems Research Group at Berkeley
has now embarked on a new development phase to
update other major components of the system, as well as to offer
new functionality.
There are five major ongoing projects.
The first is to develop an OSI network protocol suite and to integrate
existing ISO applications into Berkeley UNIX.
The second is to develop and support an interface compliant with the
P1003.1 POSIX standard recently approved by the IEEE.
The third is to refine the TCP/IP networking to improve
its performance and limit congestion on slow and/or lossy networks.
The fourth is to provide a standard interface to file systems
so that multiple local and remote file systems can be supported,
much as multiple networking protocols are supported by 4.3BSD.
The fifth is to evaluate alternate access control mechanisms and
audit the existing security features of the system, particularly
with respect to network services.
Other areas of work include multi-architecture support,
a general purpose kernel memory allocator, disk labels, and
extensions to the 4.2BSD fast filesystem.
.PP
We are planning to finish implementation prototypes for each of the
five main areas of work over the next year, and provide an informal
test release sometime next year for interested developers.
After incorporating feedback and refinements from the testers,
they will appear in the next full Berkeley release, which is typically
made about a year after the test release.
.br
.ne 10
.sp 2
.NH
Recently Completed Projects
.PP
There have been several changes in the system that were included
in the recent 4.3BSD Tahoe release.
.NH 2
Multi-architecture support
.PP
Support has been added for the DEC VAX 8600/8650, VAX 8200/8250,
MicroVAXII and MicroVAXIII.
.PP
The largest change has been the incorporation of support for the first
non-VAX processor, the CCI Power 6/32 and 6/32SX. (This addition also
supports the
Harris HCX-7 and HCX-9, as well as the Sperry 7000/40 and ICL machines.)
The Power 6 version of 4.3BSD is largely based on the compilers and
device drivers done for CCI's 4.2BSD UNIX,
and is otherwise similar to the VAX release of 4.3BSD.
The entire source tree, including all kernel and user-level sources,
has been merged using a structure that will easily accommodate the addition
of other processor families. A MIPS R2000 has been donated to us,
making the MIPS architecture a likely candidate for inclusion into a future
BSD release.
.NH 2
Kernel Memory Allocator
.PP
The 4.3BSD UNIX kernel used 10 different memory allocation mechanisms,
each designed for the particular needs of the utilizing subsystem.
These mechanisms have been replaced by a general purpose dynamic
memory allocator that can be used by all of the kernel subsystems.
The design of this allocator takes advantage of known memory usage
patterns in the UNIX kernel and a hybrid strategy that is time-efficient
for small allocations and space-efficient for large allocations.
This allocator replaces the multiple memory allocation interfaces
with a single easy-to-program interface,
results in more efficient use of global memory by eliminating
partitioned and specialized memory pools,
and is quick enough (approximately 15 VAX instructions) that no
performance loss is observed relative to the current implementations.
[McKusick88].
.NH 2
Disk Labels
.PP
During the work on the CCI machine,
it became obvious that disk geometry and filesystem layout information
must be stored on each disk in a pack label.
Disk labels were implemented for the CCI disks and for the most common
types of disk controllers on the VAX.
A utility was written to create and maintain the disk information,
and other user-level programs that use such information now obtain
it from the disk label.
The use of this facility has allowed improvements in the file system's
knowledge of irregular disk geometries such as track-to-track skew.
.NH 2
Fat Fast File System
.PP
The 4.2 fast file sytem [McKusick84]
contained several statically sized structures,
imposing limits on the number of cylinders per cylinder group,
inodes per cylinder group,
and number of distinguished rotational positions.
The new ``fat'' filesystem allows these limits to be set at filesystem
creation time.
Old kernels will treat the new filesystems as read-only,
and new kernels
will accomodate both formats.
The filesystem check facility, \fCfsck\fP, has also been modified to check
either type.
.br
.ne 10
.sp 2
.NH
Current UNIX Research at Berkeley
.PP
Since the release of 4.3BSD in mid 1986,
we have begun work on several new major areas of research.
Our goal is to apply leading edge research ideas into a stable
and reliable implementation that solves current problems in
operating systems development.
.NH 2
OSI network protocol development
.PP
The network architecture of 4.2BSD was designed to accommodate
multiple network protocol families and address formats,
and an implementation of the ISO OSI network protocols
should enter into this framework without much difficulty.
We plan to
implement the OSI connectionless internet protocol (CLNP),
and device drivers for X.25, 802.3, and possibly 802.5 interfaces, and
to integrate these with an OSI transport class 4 (TP-4) implementation.
We will also incorporate into the Berkeley Software Distribution an
updated ISO Development Environment (ISODE)
featuring International Standard (IS) versions of utilities.
ISODE implements the session and presentation layers of the OSI protocol suite,
and will include an implementation of the file transfer protocol (FTAM).
It is also possible that an X.400 implementation now being done at
University College, London and the University of Nottingham
will be available for testing and distribution.
.LP
This implementation is comprised of four areas.
.IP 1)
We are updating the University of
Wisconsin TP-4 to match GOSIP requirements.
The University of Wisconsin developed a transport class 4
implementation for the 4.2BSD kernel under contract to Mitre.
This implementation must be updated to reflect the National Institute
of Standards and Technology (NIST, formerly NBS) workshop agreements,
GOSIP, and 4.3BSD requirements.
We will make this TP-4 operate with an OSI IP,
as the original implementation was built to run over the DoD IP.
.IP 2)
A kernel version of the OSI IP and ES-IS protocols must be produced.
We will implement the kernel version of these protocols.
.IP 3)
The required device drivers need to be integrated into a BSD kernel.
4.3BSD has existing device drivers for many ethernet devices; future
BSD versions may also support X.25 devices as well as token ring
networks.
These device drivers must be integrated
into the kernel OSI protocol implementations.
.IP 4)
The existing OSINET interoperability test network is available so
that the interoperability of the ISODE and BSD kernel protocols
can be established through tests with several vendors.
Testing is crucial because an openly available version of GOSIP protocols
that does not interoperate with DEC, IBM, SUN, ICL, HIS, and other
major vendors would be embarrassing.
To allow testing of the integrated pieces the most desirable
approach is to provide access to OSINET at UCB.
A second approach is to do the interoperability testing at
the site of an existing OSINET member, such as the NBS.
.NH 2
Compliance with POSIX 1003
.PP
Berkeley became involved several months ago in the development
of the IEEE POSIX P1003.1 system interface standard.
Since then, we have been parcipating in the working groups
of P1003.2 (shell and application utility interface),
P1003.6 (security), P1003.7 (system administration), and P1003.8
(networking).
.PP
The IEEE published the POSIX P1003.1 standard in late 1988.
POSIX related changes to the BSD system have included a new terminal
driver, support for POSIX sessions and job control, expanded signal
functionality, restructured directory access routines, and new set-user
and set-group id facilities.
We currently have a prototype implementation of the
POSIX driver with extensions to provide binary compatibility with
applications developed for the old Berkeley terminal driver.
We also have a prototype implementation of the 4.2BSD-based POSIX
job control facility.
.PP
The P1003.2 draft is currently being voted on by the IEEE
P1003.2 balloting group.
Berkeley is particularly interested in the results of this standard,
as it will profoundly influence the user environment.
The other groups are in comparatively early phases, with drafts
coming to ballot sometime in the 90's.
Berkeley will continue to participate in these groups, and
move in the near future toward a P1003.1 and P1003.2 compliant
system.
We have many of the utilities outlined in the current P1003.2 draft
already implemented, and have other parties willing to contribute
additional implementations.
.NH 2
Improvements to the TCP/IP Networking Protocols
.PP
The Internet and the Berkeley collection of local-area networks
have both grown at high rates in the last year.
The Bay Area Regional Research Network (BARRNet),
connecting several UC campuses, Stanford and NASA-Ames
has recently become operational, increasing the complexity
of the network connectivity.
Both Internet and local routing algorithms are showing the strain
of continued growth.
We have made several changes in the local routing algorithm
to keep accommodating the current topology,
and are participating in the development of new routing algorithms
and standard protocols.
.PP
Recent work in collaboration with Van Jacobson of the Lawrence Berkeley
Laboratory has led to the design and implementation of several new algorithms
for TCP that improve throughput on both local and long-haul networks
while reducing unnecessary retransmission.
The improvement is especially striking when connections must traverse
slow and/or lossy networks.
The new algorithms include ``slow-start,''
a technique for opening the TCP flow control window slowly
and using the returning stream of acknowledgements as a clock
to drive the connection at the highest speed tolerated by the intervening
network.
A modification of this technique allows the sender to dynamically modify
the send window size to adjust to changing network conditions.
In addition, the round-trip timer has been modified to estimate the variance
in round-trip time, thus allowing earlier retransmission of lost packets
with less spurious retransmission due to increasing network delay.
Along with a scheme proposed by Phil Karn of Bellcore,
these changes reduce unnecessary retransmission over difficult paths
such as Satnet by nearly two orders of magnitude
while improving throughput dramatically.
.PP
The current TCP implementation is now being readied
for more widespread distribution via the network and as a
standard Berkeley distribution unencumbered by any commercial licensing.
We are continuing to refine the TCP and IP implementations
using the ARPANET, BARRNet, the NSF network
and local campus nets as testbeds.
In addition, we are incorporating applicable algorithms from this work
into the TP-4 protocol implementation.
.NH 2
Toward a Compatible File System Interface
.PP
The most critical shortcoming of the 4.3BSD UNIX system was in the
area of distributed file systems.
As with networking protocols,
there is no single distributed file system
that provides sufficient speed and functionality for all problems.
It is frequently necessary to support several different remote
file system protocols, just as it is necessary to run several
different network protocols.
.PP
As network or remote file systems have been implemented for UNIX,
several stylized interfaces between the file system implementation
and the rest of the kernel have been developed.
Among these are Sun Microsystems' Virtual File System interface (VFS)
using \fBvnodes\fP [Sandburg85] [Kleiman86],
Digital Equipment's Generic File System (GFS) architecture [Rodriguez86],
AT&T's File System Switch (FSS) [Rifkin86],
the LOCUS distributed file system [Walker85],
and Masscomp's extended file system [Cole85].
Other remote file systems have been implemented in research or
university groups for internal use,
notably the network file system in the Eighth Edition UNIX
system [Weinberger84] and two different file systems used at Carnegie Mellon
University [Satyanarayanan85].
Numerous other remote file access methods have been devised for use
within individual UNIX processes,
many of them by modifications to the C I/O library
similar to those in the Newcastle Connection [Brownbridge82].
.PP
Each design attempts to isolate file system-dependent details
below a generic interface and to provide a framework within which
new file systems may be incorporated.
However, each of these interfaces is different from
and incompatible with the others.
Each addresses somewhat different design goals,
having been based on a different version of UNIX,
having targeted a different set of file systems with varying characteristics,
and having selected a different set of file system primitive operations.
.PP
Our effort in this area is aimed at providing a common framework to
support these different distributed file systems simultaneously rather than to
simply implement yet another protocol.
This requires a detailed study of the existing protocols,
and discussion with their implementors to determine whether
they could modify their implementation to fit within our proposed
framework. We have studied the various file system interfaces to determine
their generality, completeness, robustness, efficiency, and aesthetics
and are currently working on a file system interface
that we believe includes the best features of
each of the existing implementations.
This work and the rationale underlying its development
have been presented to major software vendors as an early step
toward convergence on a standard compatible file system interface.
Briefly, the proposal adopts the 4.3BSD calling convention for file
name lookup but otherwise is closely related to Sun's VFS
and DEC's GFS. [Karels86].
.NH 2
System Security
.PP
The recent invasion of the DARPA Internet by a quickly reproducing ``worm''
highlighted the need for a thorough review of the access
safeguards built into the system.
Until now, we have taken a passive approach to dealing with
weaknesses in the system access mechanisms, rather than actively
searching for possible weaknesses.
When we are notified of a problem or loophole in a system utility
by one of our users,
we have a well defined procedure for fixing the problem and
expeditiously disseminating the fix to the BSD mailing list.
This procedure has proven itself to be effective in
solving known problems as they arise
(witness its success in handling the recent worm).
However, we feel that it would be useful to take a more active
role in identifying problems before they are reported (or exploited).
We will make a complete audit of the system
utilities and network servers to find unintended system access mechanisms.
.PP
As a part of the work to make the system more resistant to attack
from local users or via the network, it will be necessary to produce
additional documentation on the configuration and operation of the system.
This documentation will cover such topics as file and directory ownership
and access, network and server configuration,
and control of privileged operations such as file system backups.
.PP
We are investigating the addition of access control lists (ACLs) for
filesystem objects.
ACLs provide a much finer granularity of control over file access permissions
than the current
discretionary access control mechanism (mode bits).
Furthermore, they are necessary
in environments where C2 level security or better, as defined in the DoD
TCSEC [DoD83], is required.
The POSIX P1003.6 security group has made notable progress in determining
how an ACL mechanism should work, and several vendors have implemented
ACLs for their commercial systems.
Berkeley will investigate the existing implementations and determine
how to best integrate ACLs with the existing mechanism.
.PP
A major shortcoming of the present system is that authentication
over the network is based solely on the privileged port mechanism
between trusting hosts and users.
Although privileged ports can only be created by processes running as root
on a UNIX system,
such processes are easy for a workstation user to obtain;
they simply reboot their workstation in single user mode.
Thus, a better authentication mechanism is needed.
At present, we believe that the MIT Kerberos authentication
server [Steiner88] provides the best solution to this problem.
We propose to investigate Kerberos further as well as other
authentication mechanisms and then to integrate
the best one into Berkeley UNIX.
Part of this integration would be the addition of the
authentication mechanism into utilities such as
telnet, login, remote shell, etc.
We will add support for telnet (eventually replacing rlogin),
the X window system, and the mail system within an authentication
domain (a Kerberos \fIrealm\fP).
We hope to replace the existing password authentication on each host
with the network authentication system.
.NH
References
.sp
.IP Brownbridge82
Brownbridge, D.R., L.F. Marshall, B. Randell,
``The Newcastle Connection, or UNIXes of the World Unite!,''
\fISoftware\- Practice and Experience\fP, Vol. 12, pp. 1147-1162, 1982.
.sp
.IP Cole85
.br
Cole, C.T., P.B. Flinn, A.B. Atlas,
``An Implementation of an Extended File System for UNIX,''
\fIUsenix Conference Proceedings\fP,
pp. 131-150, June, 1985.
.sp
.IP DoD83
.br
Department of Defense,
``Trusted Computer System Evaluation Criteria,''
\fICSC-STD-001-83\fP,
DoD Computer Security Center, August, 1983.
.sp
.IP Karels86
Karels, M., M. McKusick,
``Towards a Compatible File System Interface,''
\fIProceedings of the European UNIX Users Group Meeting\fP,
Manchester, England, pp. 481-496, September 1986.
.sp
.IP Kleiman86
Kleiman, S.,
``Vnodes: An Architecture for Multiple File System Types in Sun UNIX,''
\fIUsenix Conference Proceedings\fP,
pp. 238-247, June, 1986.
.sp
.IP Leffler84
Leffler, S., M.K. McKusick, M. Karels,
``Measuring and Improving the Performance of 4.2BSD,''
\fIUsenix Conference Proceedings\fP, pp. 237-252, June, 1984.
.sp
.IP McKusick84
McKusick, M.K., W. Joy, S. Leffler, R. Fabry,
``A Fast File System for UNIX'',
\fIACM Transactions on Computer Systems 2\fP, 3.
pp 181-197, August 1984.
.sp
.IP McKusick85
McKusick, M.K., M. Karels, S. Leffler,
``Performance Improvements and Functional Enhancements in 4.3BSD,''
\fIUsenix Conference Proceedings\fP, pp. 519-531, June, 1985.
.sp
.IP McKusick86
McKusick, M.K., M. Karels,
``A New Virtual Memory Implementation for Berkeley UNIX,''
\fIProceedings of the European UNIX Users Group Meeting\fP,
Manchester, England, pp. 451-460, September 1986.
.sp
.IP McKusick88
McKusick, M.K., M. Karels,
``Design of a General Purpose Memory Allocator for the 4.3BSD UNIX Kernel,''
\fIUsenix Conference Proceedings\fP,
pp. 295-303, June, 1988.
.sp
.IP Rifkin86
Rifkin, A.P., M.P. Forbes, R.L. Hamilton, M. Sabrio, S. Shah, K. Yueh,
``RFS Architectural Overview,'' \fIUsenix Conference Proceedings\fP,
pp. 248-259, June, 1986.
.sp
.IP Rodriguez86
Rodriguez, R., M. Koehler, R. Hyde,
``The Generic File System,''
\fIUsenix Conference Proceedings\fP,
pp. 260-269, June, 1986.
.sp
.IP Sandberg85
Sandberg, R., D. Goldberg, S. Kleiman, D. Walsh, B. Lyon,
``Design and Implementation of the Sun Network File System,''
\fIUsenix Conference Proceedings\fP,
pp. 119-130, June, 1985.
.sp
.IP Satyanarayanan85
Satyanarayanan, M., \fIet al.\fP,
``The ITC Distributed File System: Principles and Design,''
\fIProc. 10th Symposium on Operating Systems Principles\fP, pp. 35-50,
ACM, December, 1985.
.sp
.IP Steiner88
Steiner, J., C. Newman, J. Schiller,
``\fIKerberos:\fP An Authentication Service for Open Network Systems,''
\fIUsenix Conference Proceedings\fP, pp. 191-202, February, 1988.
.sp
.IP Walker85
Walker, B.J. and S.H. Kiser, ``The LOCUS Distributed File System,''
\fIThe LOCUS Distributed System Architecture\fP,
G.J. Popek and B.J. Walker, ed., The MIT Press, Cambridge, MA, 1985.
.sp
.IP Weinberger84
Weinberger, P.J., ``The Version 8 Network File System,''
\fIUsenix Conference presentation\fP,
June, 1984.

11
share/doc/papers/diskperf/Makefile Normal file
View File

@ -0,0 +1,11 @@
# @(#)Makefile 6.3 (Berkeley) 6/8/93
DIR= papers/diskperf
SRCS= abs.ms motivation.ms equip.ms methodology.ms tests.ms results.ms \
conclusions.ms appendix.ms
MACROS= -ms
paper.ps: ${SRCS}
${TBL} ${SRCS} | ${ROFF} > ${.TARGET}
.include <bsd.doc.mk>

176
share/doc/papers/diskperf/abs.ms Normal file
View File

@ -0,0 +1,176 @@
.\" Copyright (c) 1983 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.
.\"
.\" @(#)abs.ms 6.2 (Berkeley) 4/16/91
.\"
.if n .ND
.TL
Performance Effects of Disk Subsystem Choices
for VAX\(dg Systems Running 4.2BSD UNIX*
.sp
Revised July 27, 1983
.AU
Bob Kridle
.AI
mt Xinu
2560 9th Street
Suite #312
Berkeley, California 94710
.AU
Marshall Kirk McKusick\(dd
.AI
Computer Systems Research Group
Computer Science Division
Department of Electrical Engineering and Computer Science
University of California, Berkeley
Berkeley, CA 94720
.AB
.FS
\(dgVAX, UNIBUS, and MASSBUS are trademarks of Digital Equipment Corporation.
.FE
.FS
* UNIX is a trademark of Bell Laboratories.
.FE
.FS
\(ddThis work was supported under grants from
the National Science Foundation under grant MCS80-05144,
and the Defense Advance Research Projects Agency (DoD) under
Arpa Order No. 4031 monitored by Naval Electronic System Command under
Contract No. N00039-82-C-0235.
.FE
Measurements were made of the UNIX file system
throughput for various I/O operations using the most attractive currently
available Winchester disks and controllers attached to both the
native busses (SBI/CMI) and the UNIBUS on both VAX 11/780s and VAX 11/750s.
The tests were designed to highlight the performance of single
and dual drive subsystems operating in the 4.2BSD
.I
fast file system
.R
environment.
Many of the results of the tests were initially counter-intuitive
and revealed several important aspects of the VAX implementations
which were surprising to us.
.PP
The hardware used included two Fujitsu 2351A
``Eagle''
disk drives on each of two foreign-vendor disk controllers
and two DEC RA-81 disk drives on a DEC UDA-50 disk controller.
The foreign-vendor controllers were Emulex SC750, SC780
and Systems Industries 9900 native bus interfaced controllers.
The DEC UDA-50 controller is a UNIBUS interfaced, heavily buffered
controller which is the first implementation of a new DEC storage
system architecture, DSA.
.PP
One of the most important results of our testing was the correction
of several timing parameters in our device handler for devices
with an RH750/RH780 type interface and having high burst transfer
rates.
The correction of these parameters resulted in an increase in
performance of over twenty percent in some cases.
In addition, one of the controller manufacturers altered their bus
arbitration scheme to produce another increase in throughput.
.AE
.LP
.de PT
.lt \\n(LLu
.pc %
.nr PN \\n%
.tl '\\*(LH'\\*(CH'\\*(RH'
.lt \\n(.lu
..
.af PN i
.ds LH Performance
.ds RH Contents
.bp 1
.\".if t .ds CF July 27, 1983
.\".if t .ds LF CSRG TR/8
.\".if t .ds RF Kridle, et. al.
.ce
.B "TABLE OF CONTENTS"
.LP
.sp 1
.nf
.B "1. Motivation"
.LP
.sp .5v
.nf
.B "2. Equipment
2.1. DEC UDA50 disk controller
2.2. Emulex SC750/SC780 disk controllers
2.3. Systems Industries 9900 disk controller
2.4. DEC RA81 disk drives
2.5. Fujitsu 2351A disk drives
.LP
.sp .5v
.nf
.B "3. Methodology
.LP
.sp .5v
.nf
.B "4. Tests
.LP
.sp .5v
.nf
.B "5. Results
.LP
.sp .5v
.nf
.B "6. Conclusions
.LP
.sp .5v
.nf
.B Acknowledgements
.LP
.sp .5v
.nf
.B References
.LP
.sp .5v
.nf
.B "Appendix A
A.1. read_8192
A.2. write_4096
A.3. write_8192
A.4. rewrite_8192
.ds RH Motivation
.af PN 1
.bp 1
.de _d
.if t .ta .6i 2.1i 2.6i
.\" 2.94 went to 2.6, 3.64 to 3.30
.if n .ta .84i 2.6i 3.30i
..
.de _f
.if t .ta .5i 1.25i 2.5i
.\" 3.5i went to 3.8i
.if n .ta .7i 1.75i 3.8i
..

98
share/doc/papers/diskperf/appendix.ms Normal file
View File

@ -0,0 +1,98 @@
.\" Copyright (c) 1983 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.
.\"
.\" @(#)appendix.ms 6.2 (Berkeley) 4/16/91
.\"
.nr H2 1
.ds RH Appendix A
.SH
\s+2Appendix A\s0
.SH
read_8192
.DS
#define BUFSIZ 8192
main( argc, argv)
char **argv;
{
char buf[BUFSIZ];
int i, j;
j = open(argv[1], 0);
for (i = 0; i < 1024; i++)
read(j, buf, BUFSIZ);
}
.DE
.SH
write_4096
.DS
#define BUFSIZ 4096
main( argc, argv)
char **argv;
{
char buf[BUFSIZ];
int i, j;
j = creat(argv[1], 0666);
for (i = 0; i < 2048; i++)
write(j, buf, BUFSIZ);
}
.DE
.SH
write_8192
.DS
#define BUFSIZ 8192
main( argc, argv)
char **argv;
{
char buf[BUFSIZ];
int i, j;
j = creat(argv[1], 0666);
for (i = 0; i < 1024; i++)
write(j, buf, BUFSIZ);
}
.DE
.bp
.SH
rewrite_8192
.DS
#define BUFSIZ 8192
main( argc, argv)
char **argv;
{
char buf[BUFSIZ];
int i, j;
j = open(argv[1], 2);
for (i = 0; i < 1024; i++)
write(j, buf, BUFSIZ);
}
.DE

127
share/doc/papers/diskperf/conclusions.ms Normal file
View File

@ -0,0 +1,127 @@
.\" Copyright (c) 1983 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.
.\"
.\" @(#)conclusions.ms 6.2 (Berkeley) 4/16/91
.\"
.ds RH Conclusions
.NH
Conclusions
.PP
Peak available throughput is only one criterion
in most storage system purchasing decisions.
Most of the VAX UNIX systems we are familiar with
are not I/O bandwidth constrained.
Nevertheless, an adequate disk bandwidth is necessary for
good performance and especially to preserve snappy
response time.
All of the disk systems we tested provide more than
adequate bandwidth for typical VAX UNIX system application.
Perhaps in some I/O-intensive applications such as
image processing, more consideration should be given
to the peak throughput available.
In most situations, we feel that other factors are more
important in making a storage choice between the systems we
tested.
Cost, reliability, availability, and support are some of these
factors.
The maturity of the technology purchased must also be weighed
against the future value and expandability of newer technologies.
.PP
Two important conclusions about storage systems in general
can be drawn from these tests.
The first is that buffering can be effective in smoothing
the the effects of lower bus speeds and bus contention.
Even though the UDA50 is located on the relatively slow
UNIBUS, its performance is similar to controllers located on
the faster processor busses.
However, the SC780 with only one sector of buffering shows that
little buffering is needed if the underlying bus is fast enough.
.PP
Placing more intelligence in the controller seems to hinder UNIX system
performance more than it helps.
Our profiling tests have indicated that UNIX spends about
the same percentage of time in the SC780 driver and the UDA50 driver
(about 10-14%).
Normally UNIX uses a disk sort algorithm that separates reads and
writes into two seek order queues.
The read queue has priority over the write queue,
since reads cause processes to block,
while writes can be done asynchronously.
This is particularly useful when generating large files,
as it allows the disk allocator to read
new disk maps and begin doing new allocations
while the blocks allocated out of the previous map are written to disk.
Because the UDA50 handles all block ordering,
and because it keeps all requests in a single queue,
there is no way to force the longer seek needed to get the next disk map.
This disfunction causes all the writes to be done before the disk map read,
which idles the disk until a new set of blocks can be allocated.
.PP
The additional functionality of the UDA50 controller that allows it
to transfer simultaneously from two drives at once tends to make
the two drive transfer tests run much more effectively.
Tuning for the single drive case works more effectively in the two
drive case than when controllers that cannot handle simultaneous
transfers are used.
.ds RH Acknowledgements
.nr H2 1
.sp 1
.SH
\s+2Acknowledgements\s0
.PP
We thank Paul Massigilia and Bill Grace
of Digital Equipment Corp for helping us run our
disk tests on their UDA50/RA81.
We also thank Rich Notari and Paul Ritkowski
of Emulex for making their machines available
to us to run our tests of the SC780/Eagles.
Dan McKinster, then of Systems Industries,
arranged to make their equipment available for the tests.
We appreciate the time provided by Bob Gross, Joe Wolf, and
Sam Leffler on their machines to refine our benchmarks.
Finally we thank our sponsors,
the National Science Foundation under grant MCS80-05144,
and the Defense Advance Research Projects Agency (DoD) under
Arpa Order No. 4031 monitored by Naval Electronic System Command under
Contract No. N00039-82-C-0235.
.ds RH References
.nr H2 1
.sp 1
.SH
\s+2References\s0
.LP
.IP [McKusick83] 20
M. McKusick, W. Joy, S. Leffler, R. Fabry,
``A Fast File System for UNIX'',
\fIACM Transactions on Computer Systems 2\fP, 3.
pp 181-197, August 1984.
.ds RH Appendix A
.bp

177
share/doc/papers/diskperf/equip.ms Normal file
View File

@ -0,0 +1,177 @@
.\" Copyright (c) 1983 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.
.\"
.\" @(#)equip.ms 6.2 (Berkeley) 4/16/91
.\"
.ds RH Equipment
.NH
Equipment
.PP
Various combinations of the three manufacturers disk controllers,
and two pairs of Winchester disk drives were tested on both
VAX 11/780 and VAX 11/750 CPUs. The Emulex and Systems Industries
disk controllers were interfaced to Fujitsu 2351A
``Eagle''
404 Megabyte disk drives.
The DEC UDA50 disk controller was interfaced to two DEC RA81
456 Megabyte Winchester disk drives.
All three controllers were tested on the VAX 780 although
only the Emulex and DEC controllers were benchmarked on the VAX 11/750.
Systems Industries makes a VAX 11/750 CMI interface for
their controller, but we did not have time to test this device.
In addition, not all the storage systems were tested for
two drive throughput.
Each of the controllers and disk drives used in the benchmarks
is described briefly below.
.NH 2
DEC UDA50 disk controller
.PP
This is a new controller design which is part of a larger, long range
storage architecture referred to as
``DSA''
or \fBD\fRigital \fBS\fRtorage \fBA\fRrchetecture.
An important aspect of DSA is migrating a large part
of the storage management previously handled in the operating
system to the storage system. Thus, the UDA50 is a much more
intelligent controller than previous interfaces like the RH750 or
RH780.
The UDA50 handles all error correction.
It also deals with most of the physical storage parameters.
Typically, system software requests a logical block or
sequence of blocks.
The physical locations of these blocks,
their head, track, and cylinder indices,
are determined by the controller.
The UDA50 also orders disk requests to maximize throughput
where possible, minimizing total seek and rotational delays.
Where multiple drives are attached to a single controller,
the UDA50 can interleave
simultaneous
data transfers from multiple drives.
.PP
The UDA50 is a UNIBUS implementation of a DSA controller.
It contains 52 sectors of internal buffering to minimize
the effects of a slow UNIBUS such as the one on the VAX-11/780.
This buffering also minimizes the effects of contention with
other UNIBUS peripherals.
.NH 2
Emulex SC750/SC780 disk controllers
.PP
These two models of the same controller interface to the CMI bus
of a VAX 11/750 and the SBI bus of a 11/VAX 780, respectively.
To the operating system, they emulate either an RH750 or
and RH780.
The controllers install in the
MASSBUS
locations in the CPU cabinets and operate from the
VAX power suplies.
They provide an
``SMD''
or \fBS\fRtorage \fBM\fRodule \fBD\fRrive
interface to the disk drives.
Although a large number of disk drives use this interface, we tested
the controller exclusively connected to Fujitsu 2351A disks.
.PP
The controller ws first implemented for the VAX-11/750 as the SC750
model several years ago. Although the SC780 was introduced more
recently, both are stable products with no bugs known to us.
.NH 2
System Industries 9900 disk controller
.PP
This controller is an evolution of the S.I. 9400 first introduced
as a UNIBUS SMD interface.
The 9900 has been enhanced to include an interface to the VAX 11/780 native
bus, the SBI.
It has also been upgraded to operate with higher data rate drives such
as the Fujitsu 2351As we used in this test.
The controller is contained in its own rack-mounted drawer with an integral
power supply.
The interface to the SMD is a four module set which mounts in a
CPU cabinet slot normally occupied by an RH780.
The SBI interface derives power from the VAX CPU cabinet power
supplies.
.NH 2
DEC RA81 disk drives
.PP
The RA81 is a rack-mountable 456 Megabyte (formatted) Winchester
disk drive manufactured by DEC.
It includes a great deal of technology which is an integral part
of the DEC \fBDSA\fR scheme.
The novel technology includes a serial packet based communications
protocol with the controller over a pair of mini-coaxial cables.
The physical characteristics of the RA81 are shown in the
table below:
.DS
.TS
box,center;
c s
l l.
DEC RA81 Disk Drive Characteristics
_
Peak Transfer Rate 2.2 Mbytes/sec.
Rotational Speed 3,600 RPM
Data Sectors/Track 51
Logical Cylinders 1,248
Logical Data Heads 14
Data Capacity 456 Mbytes
Minimum Seek Time 6 milliseconds
Average Seek Time 28 milliseconds
Maximum Seek Time 52 milliseconds
.TE
.DE
.NH 2
Fujitsu 2351A disk drives
.PP
The Fujitsu 2351A disk drive is a Winchester disk drive
with an SMD controller interface.
Fujitsu has developed a very good reputation for
reliable storage products over the last several years.
The 2351A has the following physical characteristics:
.DS
.TS
box,center;
c s
l l.
Fujitsu 2351A Disk Drive Characteristics
_
Peak Transfer Rate 1.859 Mbytes/sec.
Rotational Speed 3,961 RPM
Data Sectors/Track 48
Cylinders 842
Data Heads 20
Data Capacity 404 Mbytes
Minimum Seek Time 5 milliseconds
Average Seek Time 18 milliseconds
Maximum Seek Time 35 milliseconds
.TE
.DE
.ds RH Methodology
.bp

111
share/doc/papers/diskperf/methodology.ms Normal file
View File

@ -0,0 +1,111 @@
.\" Copyright (c) 1983 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.
.\"
.\" @(#)methodology.ms 6.2 (Berkeley) 4/16/91
.\"
.ds RH Methodology
.NH
Methodology
.PP
Our goal was to evaluate the performance of the target peripherals
in an environment as much like our 4.2BSD UNIX systems as possible.
There are two basic approaches to creating this kind of test environment.
These might be termed the \fIindirect\fR and the \fIdirect\fR approach.
The approach used by DEC in producing most of the performance data
on the UDA50/RA81 system under VMS is what we term the indirect
approach.
We chose to use the direct approach.
.PP
The indirect approach used by DEC involves two steps.
First, the environment in which performance is to be evaluated
is parameterized.
In this case, the disk I/O characteristics of VMS were measured
as to the distribution of various sizes of accesses and the proportion
of reads and writes.
This parameterization of
typical
I/O activity was termed a
``vax mix.''
The second stage involves simulating this mixture of I/O activities
with the devices to be tested and noting the total volume of transactions
processed per unit time by each system.
.PP
The problems encountered with this indirect approach often
have to do with the completeness and correctness of the parameterization
of the context environment.
For example, the
``vax mix''
model constructed for DECs tests uses a random distribution of seeks
to the blocks read or written.
It is not likely that any real system produces a distribution
of disk transfer locations which is truly random and does not
exhibit strong locality characteristics.
.PP
The methodology chosen by us is direct
in the sense that it uses the standard structured file system mechanism present
in the 4.2BSD UNIX operating system to create the sequence of locations
and sizes of reads and writes to the benchmarked equipment.
We simply create, write, and read
files as they would be by user's activities.
The disk space allocation and disk cacheing mechanism built into
UNIX is used to produce the actual device reads and writes as well
as to determine their size and location on the disk.
We measure and compare the rate at which these
.I
user files
.R
can be written, rewritten, or read.
.PP
The advantage of this approach is the implicit accuracy in
testing in the same environment in which the peripheral
will be used.
Although this system does not account for the I/O produced
by some paging and swapping, in our memory rich environment
these activities account for a relatively small portion
of the total disk activity.
.PP
A more significant disadvantage to the direct approach
is the occasional difficulty we have in accounting for our
measured results.
The apparently straight-forward activity of reading or writing a logical file
on disk can produce a complex mixture of disk traffic.
File I/O is supported by a file management system that
buffers disk traffic through an internal cache,
which allows writes to ba handled asynchronously.
Reads must be done synchronously,
however this restriction is moderated by the use of read-ahead.
Small changes in the performance of the disk controller
subsystem can result in large and unexpected
changes in the file system performance,
as it may change the characteristics of the memory contention
experienced by the processor.
.ds RH Tests
.bp

93
share/doc/papers/diskperf/motivation.ms Normal file
View File

@ -0,0 +1,93 @@
.\" Copyright (c) 1983 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.
.\"
.\" @(#)motivation.ms 6.2 (Berkeley) 4/16/91
.\"
.ds RH Motivation
.NH
Motivation
.PP
These benchmarks were performed for several reasons.
Foremost was our desire to obtain guideline to aid
in choosing one the most expensive components of any
VAX UNIX configuration, the disk storage system.
The range of choices in this area has increased dramatically
in the last year.
DEC has become, with the introduction of the UDA50/RA81 system,
cost competitive
in the area of disk storage for the first time.
Emulex's entry into the VAX 11/780 SBI controller
field, the SC780, represented a important choice for us to examine, given
our previous success with their VAX 11/750 SC750 controller and
their UNIBUS controllers.
The Fujitsu 2351A
Winchester disk drive represents the lowest cost-per-byte disk storage
known to us.
In addition, Fujitsu's reputation for reliability was appealing.
The many attractive aspects of these components justified a more
careful examination of their performance aspects under UNIX.
.PP
In addition to the direct motivation of developing an effective
choice of storage systems, we hoped to gain more insight into
VAX UNIX file system and I/O performance in general.
What generic characteristics of I/O subsystems are most
important?
How important is the location of the controller on the SBI/CMI versus
the UNIBUS?
Is extensive buffering in the controller essential or even important?
How much can be gained by putting more of the storage system
management and optimization function in the controller as
DEC does with the UDA50?
.PP
We also wanted to resolve particular speculation about the value of
storage system optimization by a controller in a UNIX
environment.
Is the access optimization as effective as that already provided
by the existing 4.2BSD UNIX device handlers for traditional disks?
VMS disk handlers do no seek optimization.
This gives the UDA50 controller an advantage over other controllers
under VMS which is not likely to be as important to UNIX.
Are there penalties associated with greater intelligence in the controller?
.PP
A third and last reason for evaluating this equipment is comparable
to the proverbial mountain climbers answer when asked why he climbs
a particular mountain,
``It was there.''
In our case the equipment
was there.
We were lucky enough to assemble all the desired disks and controllers
and get them installed on a temporarily idle VAX 11/780.
This got us started collecting data.
Although many of the tests were later rerun on a variety of other systems,
this initial test bed was essential for working out the testing bugs
and getting our feet wet.
.ds RH Equipment
.bp

337
share/doc/papers/diskperf/results.ms Normal file
View File

@ -0,0 +1,337 @@
.\" Copyright (c) 1983 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.
.\"
.\" @(#)results.ms 6.2 (Berkeley) 4/16/91
.\"
.ds RH Results
.NH
Results
.PP
The following tables indicate the results of our
test runs.
Note that each table contains results for tests run
on two varieties of 4.2BSD file systems.
The first set of results is always for a file system
with a basic blocking factor of eight Kilobytes and a
fragment size of 1 Kilobyte. The second sets of measurements
are for file systems with a four Kilobyte block size and a
one Kilobyte fragment size.
The values in parenthesis indicate the percentage of CPU
time used by the test program.
In the case of the two disk arm tests,
the value in parenthesis indicates the sum of the percentage
of the test programs that were run.
Entries of ``n. m.'' indicate this value was not measured.
.DS
.TS
box,center;
c s s s s
c s s s s
c s s s s
l | l s | l s
l | l s | l s
l | l l | l l
l | c c | c c.
4.2BSD File Systems Tests - \fBVAX 11/750\fR
=
Logically Sequential Transfers
from an \fB8K/1K\fR 4.2BSD File System (Kbytes/sec.)
_
Test Emulex SC750/Eagle UDA50/RA81
1 Drive 2 Drives 1 Drive 2 Drives
_
read_8192 490 (69%) 620 (96%) 310 (44%) 520 (65%)
write_4096 380 (99%) 370 (99%) 370 (97%) 360 (98%)
write_8192 470 (99%) 470 (99%) 320 (71%) 410 (83%)
rewrite_8192 650 (99%) 620 (99%) 310 (50%) 450 (70%)
=
.T&
c s s s s
c s s s s
l | l s | l s
l | l s | l s
l | l l | l l
l | c c | c c.
Logically Sequential Transfers
from \fB4K/1K\fR 4.2BSD File System (Kbytes/sec.)
_
Test Emulex SC750/Eagle UDA50/RA81
1 Drive 2 Drives 1 Drive 2 Drives
_
read_8192 300 (60%) 400 (84%) 210 (42%) 340 (77%)
write_4096 320 (98%) 320 (98%) 220 (67%) 290 (99%)
write_8192 340 (98%) 340 (99%) 220 (65%) 310 (98%)
rewrite_8192 450 (99%) 450 (98%) 230 (47%) 340 (78%)
.TE
.DE
.PP
Note that the rate of write operations on the VAX 11/750 are ultimately
CPU limited in some cases.
The write rates saturate the CPU at a lower bandwidth than the reads
because they must do disk allocation in addition to moving the data
from the user program to the disk.
The UDA50/RA81 saturates the CPU at a lower transfer rate for a given
operation than the SC750/Eagle because
it causes more memory contention with the CPU.
We do not know if this contention is caused by
the UNIBUS controller or the UDA50.
.PP
The following table reports the results of test runs on a VAX 11/780
with 4 Megabytes of main memory.
.DS
.TS
box,center;
c s s s s s s
c s s s s s s
c s s s s s s
l | l s | l s | l s
l | l s | l s | l s
l | l l | l l | l l
l | c c | c c | c c.
4.2BSD File Systems Tests - \fBVAX 11/780\fR
=
Logically Sequential Transfers
from an \fB8K/1K\fR 4.2BSD File System (Kbytes/sec.)
_
Test Emulex SC780/Eagle UDA50/RA81 Sys. Ind. 9900/Eagle
1 Drive 2 Drives 1 Drive 2 Drives 1 Drive 2 Drives
_
read_8192 560 (70%) 480 (58%) 360 (45%) 540 (72%) 340 (41%) 520 (66%)
write_4096 440 (98%) 440 (98%) 380 (99%) 480 (96%) 490 (96%) 440 (84%)
write_8192 490 (98%) 490 (98%) 220 (58%)* 480 (92%) 490 (80%) 430 (72%)
rewrite_8192 760 (100%) 560 (72%) 220 (50%)* 180 (52%)* 490 (60%) 520 (62%)
=
.T&
c s s s s s s
c s s s s s s
l | l s | l s | l s
l | l s | l s | l s
l | l l | l l | l l
l | c c | c c | c c.
Logically Sequential Transfers
from an \fB4K/1K\fR 4.2BSD File System (Kbytes/sec.)
_
Test Emulex SC780/Eagle UDA50/RA81 Sys. Ind. 9900/Eagle
1 Drive 2 Drives 1 Drive 2 Drives 1 Drive 2 Drives
_
read_8192 490 (77%) 370 (66%) n.m. n.m. 200 (31%) 370 (56%)
write_4096 380 (98%) 370 (98%) n.m. n.m. 200 (46%) 370 (88%)
write_8192 380 (99%) 370 (97%) n.m. n.m. 200 (45%) 320 (76%)
rewrite_8192 490 (87%) 350 (66%) n.m. n.m. 200 (31%) 300 (46%)
.TE
* the operation of the hardware was suspect during these tests.
.DE
.PP
The dropoff in reading and writing rates for the two drive SC780/Eagle
tests are probably due to the file system using insufficient
rotational delay for these tests.
We have not fully investigated these times.
.PP
The following table compares data rates on VAX 11/750s directly
with those of VAX 11/780s using the UDA50/RA81 storage system.
.DS
.TS
box,center;
c s s s s
c s s s s
c s s s s
l | l s | l s
l | l s | l s
l | l l | l l
l | c c | c c.
4.2BSD File Systems Tests - \fBDEC UDA50 - 750 vs. 780\fR
=
Logically Sequential Transfers
from an \fB8K/1K\fR 4.2BSD File System (Kbytes/sec.)
_
Test VAX 11/750 UNIBUS VAX 11/780 UNIBUS
1 Drive 2 Drives 1 Drive 2 Drives
_
read_8192 310 (44%) 520 (84%) 360 (45%) 540 (72%)
write_4096 370 (97%) 360 (100%) 380 (99%) 480 (96%)
write_8192 320 (71%) 410 (96%) 220 (58%)* 480 (92%)
rewrite_8192 310 (50%) 450 (80%) 220 (50%)* 180 (52%)*
=
.T&
c s s s s
c s s s s
l | l s | l s
l | l s | l s
l | l l | l l
l | c c | c c.
Logically Sequential Transfers
from an \fB4K/1K\fR 4.2BSD File System (Kbytes/sec.)
_
Test VAX 11/750 UNIBUS VAX 11/780 UNIBUS
1 Drive 2 Drives 1 Drive 2 Drives
_
read_8192 210 (42%) 342 (77%) n.m. n.m.
write_4096 215 (67%) 294 (99%) n.m. n.m.
write_8192 215 (65%) 305 (98%) n.m. n.m.
rewrite_8192 227 (47%) 336 (78%) n.m. n.m.
.TE
* the operation of the hardware was suspect during these tests.
.DE
.PP
The higher throughput available on VAX 11/780s is due to a number
of factors.
The larger main memory size allows a larger file system cache.
The block allocation routines run faster, raising the upper limit
on the data rates in writing new files.
.PP
The next table makes the same comparison using an Emulex controller
on both systems.
.DS
.TS
box, center;
c s s s s
c s s s s
c s s s s
l | l s | l s
l | l s | l s
l | l l | l l
l | c c | c c.
4.2BSD File Systems Tests - \fBEmulex - 750 vs. 780\fR
=
Logically Sequential Transfers
from an \fB8K/1K\fR 4.2BSD File System (Kbytes/sec.)
_
Test VAX 11/750 CMI Bus VAX 11/780 SBI Bus
1 Drive 2 Drives 1 Drive 2 Drives
_
read_8192 490 (69%) 620 (96%) 560 (70%) 480 (58%)
write_4096 380 (99%) 370 (99%) 440 (98%) 440 (98%)
write_8192 470 (99%) 470 (99%) 490 (98%) 490 (98%)
rewrite_8192 650 (99%) 620 (99%) 760 (100%) 560 (72%)
=
.T&
c s s s s
c s s s s
l | l s | l s
l | l s | l s
l | l l | l l
l | c c | c c.
Logically Sequential Transfers
from an \fB4K/1K\fR 4.2BSD File System (Kbytes/sec.)
_
Test VAX 11/750 CMI Bus VAX 11/780 SBI Bus
1 Drive 2 Drives 1 Drive 2 Drives
_
read_8192 300 (60%) 400 (84%) 490 (77%) 370 (66%)
write_4096 320 (98%) 320 (98%) 380 (98%) 370 (98%)
write_8192 340 (98%) 340 (99%) 380 (99%) 370 (97%)
rewrite_8192 450 (99%) 450 (98%) 490 (87%) 350 (66%)
.TE
.DE
.PP
The following table illustrates the evolution of our testing
process as both hardware and software problems effecting
the performance of the Emulex SC780 were corrected.
The software change was suggested to us by George Goble
of Purdue University.
.PP
The 4.2BSD handler for RH750/RH780 interfaced disk drives
contains several constants which to determine how
much time is provided between an interrupt signaling the completion
of a positioning command and the subsequent start of a data transfer
operation. These lead times are expressed as sectors of rotational delay.
If they are too small, an extra complete rotation will often be required
between a seek and subsequent read or write operation.
The higher bit rate and rotational speed of the 2351A Fujitsu
disk drives required
increasing these constants.
.PP
The hardware change involved allowing for slightly longer
delays in arbitrating for cycles on the SBI bus by
starting the bus arbitration cycle a little further ahead of
when the data was ready for transfer.
Finally we had to increase the rotational delay between consecutive
blocks in the file because
the higher bandwidth from the disk generated more memory contention,
which slowed down the processor.
.DS
.TS
box,center,expand;
c s s s s s s
c s s s s s s
c s s s s s s
l | l s | l s | l s
l | l s | l s | l s
l | l s | l s | l s
l | c c | c c | c c
l | c c | c c | c c.
4.2BSD File Systems Tests - \fBEmulex SC780 Disk Controller Evolution\fR
=
Logically Sequential Transfers
from an \fB8K/1K\fR 4.2BSD File System (Kbytes/sec.)
_
Test Inadequate Search Lead OK Search Lead OK Search Lead
Initial SBI Arbitration Init SBI Arb. Improved SBI Arb.
1 Drive 2 Drives 1 Drive 2 Drives 1 Drive 2 Drives
_
read_8192 320 370 440 (60%) n.m. 560 (70%) 480 (58%)
write_4096 250 270 300 (63%) n.m. 440 (98%) 440 (98%)
write_8192 250 280 340 (60%) n.m. 490 (98%) 490 (98%)
rewrite_8192 250 290 380 (48%) n.m. 760 (100%) 560 (72%)
=
.T&
c s s s s s s
c s s s s s s
l | l s | l s | l s
l | l s | l s | l s
l | l s | l s | l s
l | c c | c c | c c
l | c c | c c | c c.
Logically Sequential Transfers
from an \fB4K/1K\fR 4.2BSD File System (Kbytes/sec.)
_
Test Inadequate Search Lead OK Search Lead OK Search Lead
Initial SBI Arbitration Init SBI Arb. Improved SBI Arb.
1 Drive 2 Drives 1 Drive 2 Drives 1 Drive 2 Drives
_
read_8192 200 220 280 n.m. 490 (77%) 370 (66%)
write_4096 180 190 300 n.m. 380 (98%) 370 (98%)
write_8192 180 200 320 n.m. 380 (99%) 370 (97%)
rewrite_8192 190 200 340 n.m. 490 (87%) 350 (66%)
.TE
.DE
.ds RH Conclusions
.bp

108
share/doc/papers/diskperf/tests.ms Normal file
View File

@ -0,0 +1,108 @@
.\" Copyright (c) 1983 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.
.\"
.\" @(#)tests.ms 6.2 (Berkeley) 4/16/91
.\"
.ds RH Tests
.NH
Tests
.PP
Our battery of tests consists of four programs,
read_8192, write_8192, write_4096
and rewrite_8192 originally written by [McKusick83]
to evaluate the performance of the new file system in 4.2BSD.
These programs all follow the the same model and are typified by
read_8192 shown here.
.DS
#define BUFSIZ 8192
main( argc, argv)
char **argv;
{
char buf[BUFSIZ];
int i, j;
j = open(argv[1], 0);
for (i = 0; i < 1024; i++)
read(j, buf, BUFSIZ);
}
.DE
The remaining programs are included in appendix A.
.PP
These programs read, write with two different blocking factors,
and rewrite logical files in structured file system on the disk
under test.
The write programs create new files while the rewrite program
overwrites an existing file.
Each of these programs represents an important segment of the
typical UNIX file system activity with the read program
representing by far the largest class and the rewrite the smallest.
.PP
A blocking factor of 8192 is used by all programs except write_4096.
This is typical of most 4.2BSD user programs since a standard set of
I/O support routines is commonly used and these routines buffer
data in similar block sizes.
.PP
For each test run, a empty eight Kilobyte block
file system was created in the target
storage system.
Then each of the four tests was run and timed.
Each test was run three times;
the first to clear out any useful data in the cache,
and the second two to insure that the experiment
had stablized and was repeatable.
Each test operated on eight Megabytes of data to
insure that the cache did not overly influence the results.
Another file system was then initialized using a
basic blocking factor of four Kilobytes and the same tests
were run again and timed.
A command script for a run appears as follows:
.DS
#!/bin/csh
set time=2
echo "8K/1K file system"
newfs /dev/rhp0g eagle
mount /dev/hp0g /mnt0
mkdir /mnt0/foo
echo "write_8192 /mnt0/foo/tst2"
rm -f /mnt0/foo/tst2
write_8192 /mnt0/foo/tst2
rm -f /mnt0/foo/tst2
write_8192 /mnt0/foo/tst2
rm -f /mnt0/foo/tst2
write_8192 /mnt0/foo/tst2
echo "read_8192 /mnt0/foo/tst2"
read_8192 /mnt0/foo/tst2
read_8192 /mnt0/foo/tst2
read_8192 /mnt0/foo/tst2
umount /dev/hp0g
.DE
.ds RH Results
.bp

7
share/doc/papers/fsinterface/Makefile Normal file
View File

@ -0,0 +1,7 @@
# @(#)Makefile 5.3 (Berkeley) 6/8/93
DIR= papers/fsinterface
SRCS= fsinterface.ms
MACROS= -ms
.include <bsd.doc.mk>

73
share/doc/papers/fsinterface/abstract.ms Normal file
View File

@ -0,0 +1,73 @@
.\" Copyright (c) 1986 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.
.\"
.\" @(#)abstract.ms 5.2 (Berkeley) 4/16/91
.\"
.TL
Toward a Compatible Filesystem Interface
.AU
Michael J. Karels
Marshall Kirk McKusick
.AI
Computer Systems Research Group
Computer Science Division
Department of Electrical Engineering and Computer Science
University of California, Berkeley
Berkeley, California 94720
.LP
As network or remote filesystems have been implemented for
.UX ,
several stylized interfaces between the filesystem implementation
and the rest of the kernel have been developed.
Notable among these are Sun Microsystems' virtual filesystem interface
using vnodes, Digital Equipment's Generic File System architecture,
and AT&T's File System Switch.
Each design attempts to isolate filesystem-dependent details
below the generic interface and to provide a framework within which
new filesystems may be incorporated.
However, each of these interfaces is different from
and incompatible with the others.
Each of them addresses somewhat different design goals.
Each was based upon a different starting version of
.UX ,
targetted a different set of filesystems with varying characteristics,
and uses a different set of primitive operations provided by the filesystem.
The current study compares the various filesystem interfaces.
Criteria for comparison include generality, completeness, robustness,
efficiency and esthetics.
As a result of this comparison, a proposal for a new filesystem interface
is advanced that includes the best features of the existing implementations.
The proposal adopts the calling convention for name lookup introduced
in 4.3BSD.
A prototype implementation is described.
This proposal and the rationale underlying its development
have been presented to major software vendors
as an early step toward convergence upon a compatible filesystem interface.

1176
share/doc/papers/fsinterface/fsinterface.ms Normal file
View File

File diff suppressed because it is too large Load Diff

318
share/doc/papers/fsinterface/slides.t Normal file
View File

@ -0,0 +1,318 @@
.\" Copyright (c) 1986 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.
.\"
.\" @(#)slides.t 5.2 (Berkeley) 4/16/91
.\"
.so macros
.nf
.LL
Encapsulation of namei parameters
.NP 0
.ta .5i +\w'caddr_t\0\0'u +\w'struct\0\0'u +\w'vnode *nc_prevdir;\0\0\0\0\0'u
struct nameidata {
/* arguments and context: */
caddr_t ni_dirp;
enum uio_seg ni_seg;
short ni_nameiop;
struct vnode *ni_cdir;
struct vnode *ni_rdir;
struct ucred *ni_cred;
.sp .2
/* shared with lookup and commit: */
caddr_t ni_pnbuf;
char *ni_ptr;
int ni_pathlen;
short ni_more;
short ni_loopcnt;
.sp .2
/* results: */
struct vnode *ni_vp;
struct vnode *ni_dvp;
.sp .2
/* BEGIN UFS SPECIFIC */
struct diroffcache {
struct vnode *nc_prevdir;
long nc_id;
off_t nc_prevoffset;
} ni_nc;
/* END UFS SPECIFIC */
};
.bp
.LL
Namei operations and modifiers
.NP 0
.ta \w'#define\0\0'u +\w'WANTPARENT\0\0'u +\w'0x40\0\0\0\0\0\0\0'u
#define LOOKUP 0 /* name lookup only */
#define CREATE 1 /* setup for creation */
#define DELETE 2 /* setup for deletion */
#define WANTPARENT 0x10 /* return parent vnode also */
#define NOCACHE 0x20 /* remove name from cache */
#define FOLLOW 0x40 /* follow symbolic links */
.bp
.LL
Namei operations and modifiers
.NP 0
.ta \w'#define\0\0'u +\w'WANTPARENT\0\0'u +\w'0x40\0\0\0\0\0\0\0'u
#define LOOKUP 0
#define CREATE 1
#define DELETE 2
#define WANTPARENT 0x10
#define NOCACHE 0x20
#define FOLLOW 0x40
.bp
.LL
Credentials
.NP 0
.ta .5i +\w'caddr_t\0\0\0'u +\w'struct\0\0'u +\w'vnode *nc_prevdir;\0\0\0\0\0'u
struct ucred {
u_short cr_ref;
uid_t cr_uid;
short cr_ngroups;
gid_t cr_groups[NGROUPS];
/*
* The following either should not be here,
* or should be treated as opaque.
*/
uid_t cr_ruid;
gid_t cr_svgid;
};
.bp
.LL
Scatter-gather I/O
.NP 0
.ta .5i +\w'caddr_t\0\0\0'u +\w'struct\0\0'u +\w'vnode *nc_prevdir;\0\0\0\0\0'u
struct uio {
struct iovec *uio_iov;
int uio_iovcnt;
off_t uio_offset;
int uio_resid;
enum uio_rw uio_rw;
};
enum uio_rw { UIO_READ, UIO_WRITE };
.ta .5i +\w'caddr_t\0\0\0'u +\w'vnode *nc_prevdir;\0\0\0\0\0'u
struct iovec {
caddr_t iov_base;
int iov_len;
enum uio_seg iov_segflg;
int (*iov_op)();
};
.bp
.LL
Per-filesystem information
.NP 0
.ta .25i +\w'struct vfsops\0\0\0'u +\w'*vfs_vnodecovered;\0\0\0\0\0'u
struct vfs {
struct vfs *vfs_next;
\fB+\fP struct vfs *vfs_prev;
struct vfsops *vfs_op;
struct vnode *vfs_vnodecovered;
int vfs_flag;
\fB!\fP int vfs_fsize;
\fB+\fP int vfs_bsize;
\fB!\fP uid_t vfs_exroot;
short vfs_exflags;
caddr_t vfs_data;
};
.NP 0
.ta \w'\fB+\fP 'u +\w'#define\0\0'u +\w'VFS_EXPORTED\0\0'u +\w'0x40\0\0\0\0\0'u
/* vfs flags: */
#define VFS_RDONLY 0x01
\fB+\fP #define VFS_NOEXEC 0x02
#define VFS_MLOCK 0x04
#define VFS_MWAIT 0x08
#define VFS_NOSUID 0x10
#define VFS_EXPORTED 0x20
/* exported vfs flags: */
#define EX_RDONLY 0x01
.bp
.LL
Operations supported on virtual file system.
.NP 0
.ta .25i +\w'int\0\0'u +\w'*vfs_mountroot();\0'u
struct vfsops {
\fB!\fP int (*vfs_mount)(vfs, path, data, len);
\fB!\fP int (*vfs_unmount)(vfs, forcibly);
\fB+\fP int (*vfs_mountroot)();
int (*vfs_root)(vfs, vpp);
int (*vfs_statfs)(vfs, sbp);
\fB!\fP int (*vfs_sync)(vfs, waitfor);
\fB+\fP int (*vfs_fhtovp)(vfs, fhp, vpp);
\fB+\fP int (*vfs_vptofh)(vp, fhp);
};
.bp
.LL
Dynamic file system information
.NP 0
.ta .5i +\w'struct\0\0\0'u +\w'*vfs_vnodecovered;\0\0\0\0\0'u
struct statfs {
\fB!\fP short f_type;
\fB+\fP short f_flags;
\fB!\fP long f_fsize;
\fB+\fP long f_bsize;
long f_blocks;
long f_bfree;
long f_bavail;
long f_files;
long f_ffree;
fsid_t f_fsid;
\fB+\fP char *f_mntonname;
\fB+\fP char *f_mntfromname;
long f_spare[7];
};
typedef long fsid_t[2];
.bp
.LL
Filesystem objects (vnodes)
.NP 0
.ta .25i +\w'struct vnodeops\0\0'u +\w'*v_vfsmountedhere;\0\0\0'u
enum vtype { VNON, VREG, VDIR, VBLK, VCHR, VLNK, VSOCK };
struct vnode {
u_short v_flag;
u_short v_count;
u_short v_shlockc;
u_short v_exlockc;
struct vfs *v_vfsmountedhere;
struct vfs *v_vfsp;
struct vnodeops *v_op;
\fB+\fP struct text *v_text;
enum vtype v_type;
caddr_t v_data;
};
.ta \w'#define\0\0'u +\w'NOFOLLOW\0\0'u +\w'0x40\0\0\0\0\0\0\0'u
/* vnode flags */
#define VROOT 0x01
#define VTEXT 0x02
#define VEXLOCK 0x10
#define VSHLOCK 0x20
#define VLWAIT 0x40
.bp
.LL
Operations on vnodes
.NP 0
.ta .25i +\w'int\0\0'u +\w'(*vn_getattr)(\0\0\0\0\0'u
struct vnodeops {
\fB!\fP int (*vn_lookup)(ndp);
\fB!\fP int (*vn_create)(ndp, vap, fflags);
\fB+\fP int (*vn_mknod)(ndp, vap, fflags);
\fB!\fP int (*vn_open)(vp, fflags, cred);
int (*vn_close)(vp, fflags, cred);
int (*vn_access)(vp, fflags, cred);
int (*vn_getattr)(vp, vap, cred);
int (*vn_setattr)(vp, vap, cred);
.sp .5
\fB+\fP int (*vn_read)(vp, uiop,
offp, ioflag, cred);
\fB+\fP int (*vn_write)(vp, uiop,
offp, ioflag, cred);
\fB!\fP int (*vn_ioctl)(vp, com,
data, fflag, cred);
int (*vn_select)(vp, which, cred);
\fB+\fP int (*vn_mmap)(vp, ..., cred);
int (*vn_fsync)(vp, cred);
\fB+\fP int (*vn_seek)(vp, offp, off,
whence);
.bp
.LL
Operations on vnodes (cont)
.NP 0
.ta .25i +\w'int\0\0'u +\w'(*vn_getattr)(\0\0\0\0\0'u
\fB!\fP int (*vn_remove)(ndp);
\fB!\fP int (*vn_link)(vp, ndp);
\fB!\fP int (*vn_rename)(sndp, tndp);
\fB!\fP int (*vn_mkdir)(ndp, vap);
\fB!\fP int (*vn_rmdir)(ndp);
\fB!\fP int (*vn_symlink)(ndp, vap, nm);
\fB!\fP int (*vn_readdir)(vp, uiop,
offp, ioflag, cred);
\fB!\fP int (*vn_readlink)(vp, uiop,
offp, ioflag, cred);
.sp .5
\fB+\fP int (*vn_abortop)(ndp);
\fB!\fP int (*vn_inactive)(vp);
};
.NP 0
.ta \w'#define\0\0'u +\w'NOFOLLOW\0\0'u +\w'0x40\0\0\0\0\0'u
/* flags for ioflag */
#define IO_UNIT 0x01
#define IO_APPEND 0x02
#define IO_SYNC 0x04
.bp
.LL
Vnode attributes
.NP 0
.ta .5i +\w'struct timeval\0\0'u +\w'*v_vfsmountedhere;\0\0\0'u
struct vattr {
enum vtype va_type;
u_short va_mode;
\fB!\fP uid_t va_uid;
\fB!\fP gid_t va_gid;
long va_fsid;
\fB!\fP long va_fileid;
short va_nlink;
u_long va_size;
\fB+\fP u_long va_size1;
long va_blocksize;
struct timeval va_atime;
struct timeval va_mtime;
struct timeval va_ctime;
dev_t va_rdev;
\fB!\fP u_long va_bytes;
\fB+\fP u_long va_bytes1;
};

11
share/doc/papers/kernmalloc/Makefile Normal file
View File

@ -0,0 +1,11 @@
# @(#)Makefile 1.8 (Berkeley) 6/8/93
DIR= papers/kernmalloc
SRCS= kernmalloc.t appendix.t
MACROS= -ms
paper.ps: ${SRCS} alloc.fig usage.tbl
${SOELIM} ${SRCS} | ${TBL} | ${PIC} | ${EQN} | ${GRIND} | \
${ROFF} > ${.TARGET}
.include <bsd.doc.mk>

Some files were not shown because too many files have changed in this diff Show More