*** UNIX MANUAL PAGE BROWSER ***

DK(4) Kernel Interfaces Manual 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 connect 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 imple- menting 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 micro- processor board connected to a Datakit, ISN, or Hyperkit fiber interface. The host does all the protocol work. Each minor device number represents a Datakit channel; the device num- ber 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 protocol. 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 ac- tive channel. Cmc_ld and unixp_ld are line disciplines set up calls handle and con- troller 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 controller 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 channel 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 con- trol 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 chan- nel. KIOCINIT Initialize URP. These ioctl calls are provided by the call setup line disciplines: 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 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 Net- work', 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. DK(4)