730 lines
25 KiB
Plaintext
730 lines
25 KiB
Plaintext
|
.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.
|