DK(4) DK(4)
NAME
dk, dkp_ld, unixp_ld, cmc_ld - Datakit interface and
protocols
SYNOPSIS
#include <sys/dkio.h>
DESCRIPTION
These device drivers and line disciplines are used to con-
nect to a Datakit network. Normally the programs in
dkmgr(8) do all the work.
Several combinations of hardware and software may be used to
connect a system to Datakit:
The dk driver works with a DR11-C or DRV11-J connected
through an adapter box to a Datakit CPM-422. The host
computer does all the protocol work.
The kdi driver works with a KMC11-B and one of several
line units (KDI, DUBHI, KMS11-P) connected to one of
several Datakit or ISN interface boards. The KMC11
runs microcode that handles the URP protocol.
The experimental kmcdk driver works with a KMC11-B and
a line unit, as above, but the KMC11 runs different
microcode implementing a simple DMA engine, and the
host does all the protocol work. This is slower, but
rather more robust, than the kdi setup.
The experimental cure driver works with a custom-built
microprocessor board connected to a Datakit, ISN, or
Hyperkit fiber interface. The host does all the proto-
col work.
Each minor device number represents a Datakit channel; the
device number is the channel number. The kdi driver allows
only 96 channels per KMC11-line unit pair; devices 96-191
are channels 0-95 on a second pair, if present, and devices
192-255 are channels 0-63 on a third. For the other
drivers, there may be only one hardware interface, which may
have up to 256 channels.
Usually there is one interface, with files in directory See
dkmgr(8) for more about naming conventions.
Dkp_ld is a stream line discipline implementing the URP pro-
tocol. The kdi driver makes its own URP arrangements; other
interfaces need the line discipline. A separate copy of
dkp_ld must be pushed on each active channel.
DK(4) DK(4)
Cmc_ld and unixp_ld are line disciplines set up calls handle
and controller handshake messages. Cmc_ld runs a Research-
only call setup protocol; unixp_ld runs the standard one.
One copy of the appropriate line discipline must be pushed
on the common signaling channel to deal with occasional con-
troller keep-alive and maintenance messages. Other copies
of the line discipline come and go as calls are placed.
These ioctl calls are provided by the device drivers:
DIOCNXCL Allow this channel to be opened many times. By
default, if a channel is open, it may not be
opened again. The default is restored whenever
the channel is completely closed.
KIOCSHUT Reset the kdi driver, hanging up all channels.
These ioctl calls are provided by the URP processors, dkp_ld
and kdi:
DIOCSTREAM Don't generate a stream delimiter when this chan-
nel receives a BOT trailer.
DIOCRECORD Insert a stream delimiter after receiving BOT;
the default.
DIOCSCTL The third argument points to a byte; send that as
a Datakit control envelope.
DIOCRCTL The third argument points to a byte; copy the
most recently received non-URP control envelope
there. Zero means no control has been received
since the last call.
DIOCXWIN Set transmit window size. The third argument
points to an array of two long integers. The
first number is the maximum size of each URP
block; the second is the number of blocks that
may be outstanding. Blocks may be no more than
4096 bytes, and the protocol allows no more than
eight blocks in a window. A KIOCINIT call should
follow immediately, or things may go awry.
KIOCISURP Return success if some URP processor is active on
this channel.
KIOCINIT Initialize URP.
These ioctl calls are provided by the call setup line disci-
plines:
DIOCLHN This is the common signalling channel.
DIOCHUP Tell the controller to initialize, hanging up all
channels.
DIOCSTOP Temporarily hold back received data, so it won't
be lost in call setup messages.
DIOCSTART Release data held by DIOCSTOP.
DIOCCHAN The third argument points to an integer; fill it
in with the number of a free channel for calling
out. This is a hint, not a promise; the channel
DK(4) DK(4)
may already be taken by the time it is opened.
The caller should be prepared to try again.
FILES
SEE ALSO
dkmgr(8), kmc(8)
A. G. Fraser and W. T. Marshall, `Data Transport in a Byte
Stream Network', IEEE J-SAC, (September, 1989)
Datakit VSC Internal Interface Specification, select code
700-283, AT&T Customer Information Center, Indianapolis
BUGS
Dkp_ld and kdi insist on using exactly three blocks in a
window, no matter what they are told in DIOCXWIN.
The kdi driver has only two block sizes, 28 and 252 bytes.