BK(4) COMMAND REFERENCE BK(4)
NAME
bk - line discipline for machine to machine communication
SYNOPSIS
pseudo-device bk
DESCRIPTION
The line discipline provides a replacement for the old and
new tty drivers described in tty(4) when high speed output
to and especially input from another machine is to be
transmitted over an asynchronous communications line. The
discipline was designed for use by the Berkeley network; it
may be suitable for uploading of data from microprocessors
into the system. If you are sending data over asynchronous
communications lines into the system at high speed, you must
use this discipline, as the system otherwise may detect high
input data rates on terminal lines and may disable the
lines; in any case, the processing of such data when normal
terminal mechanisms are involved saturates the system.
The line discipline is enabled by a sequence:
#include <sgtty.h>
int ldisc = NETLDISC, fildes; ...
ioctl(fildes, TIOCSETD, &ldisc);
While the line discipline is set to NETLDISC there are two
modes of operation which apply to read operations. The
default mode of operation is to block the reading process
until a complete record has been received. There are two
alternatives for delimiting a record; the default is fixed
length records of 1024 bytes. An alternative is to specify
a break character which will terminate the record and return
the characters received up to that point, including the
terminator character, to the process that issued the read.
If 1024 characters are received before a break character is
seen, the record of 1024 characters will be returned to the
reading process. The break character is specified with the
TIOCSETC ioctl.
For example, to make line feed the terminating character,
use the routine described here; note that this should be
done before setting the discipline to NETLDISC.
#include <sgtty.h>
struct tchars old_tchars, new_tchars;
ioctl(ttyfd, TIOCGETC, &old_tchars)
new_tchars = old_tchars;
new_tchars.t_brkc = '0;
ioctl(ttyfd, TIOCSETC, &new_tchars)
Printed 4/6/89 1
BK(4) COMMAND REFERENCE BK(4)
The rubout character, 0377 (0xff), is used to cancel
checking for a record break character.
If a read is issued for fewer characters than are in the
record buffer, the remaining characters will be discarded.
The second mode of operation allows non-blocking reads; this
can be invoked by the FIONBIO ioctl:
#include <sgtty.h>
int noblock = 1;
ioctl(ttyfd, FIONBIO, &noblock)
In this mode the driver never waits for a record to be
accumulated; it always returns immediately with the count of
characters transferred. The count may be zero if no
characters are in the input buffer. If the reading process
requests fewer characters than are in the buffer, the number
of characters requested will be returned and the remaining
characters in the buffer will be available on the next read.
The reading process should read as many characters as
possible, up to 1024, to minimize processing overhead.
The (old) standard teletype discipline can be restored by
typing:
ldisc = OTTYDISC:
ioctl(fildes, TIOCSETD, &ldisc);
While in NETLDISC discipline, normal teletype output
functions take place. Thus, if an 8 bit output data path is
desired, it is necessary to prepare the output line by
putting it into RAW mode using ioctl(2); this must be done
before changing the discipline with TIOCSETD, as most
ioctl(2) calls are disabled while in network line discipline
mode.
When in NETLDISC discipline, input processing is limited to
reduce overhead; currently the input path is 8 bits wide.
The application program needs to take the buffering
mechanism of the bk driver into consideration to insure
maximum throughput with no loss of data. As characters are
received they are moved from a hardware controlled buffer to
a record buffer in the UTek kernel by the hardware interrupt
service routine. Once the buffer is full, 1024 bytes, or a
record break character has been detected, no more characters
will be moved to the record buffer. If additional
characters are received they will be left in the hardware
buffer until the record buffer is emptied by the application
program. If the hardware buffer is filled, characters will
be lost. There is no mechanism to find out how many
characters have been lost or if characters in the hardware
buffer have been overwritten. Once the record buffer has
Printed 4/6/89 2
BK(4) COMMAND REFERENCE BK(4)
been transferred to the application program characters will
again be moved from the hardware's buffer to the record
buffer. This movement can take place wile the application
program is processing the previous record, i.e. before a
read is issued by the application program. The critical
requirement is that the application program issue the next
read request before the combined record an hardware buffers
fill up. The hardware buffer is 256 bytes.
Input flow control is supported while NETLDISC is in effect.
Flow control is enabled or disabled with TANDEM or DODTR in
the same manner as for normal line disciplines; see tty(4).
Input is stopped when the buffer is within 32 bytes of being
full; it is restarted when it is within 32 bytes of being
empty.
A typical application program would read a sequence of
records from the terminal port, checking header and
sequencing information on each record and acknowledging
receipt of each record to the sender, who then transmits
another record of data. Typically several hundred bytes of
data and a smaller amount of control information will be
received on each handshake. As long as the total length of
each record is less than 1024 bytes, an application
operating in this manner can support any baud rate the
hardware will support without the loss of data. Actual
throughput will be dependent on record length and the amount
of processing done on each record. If the application
processing is simple, i.e. writing the data to a file, the
data throughput should be about 80% of the hardware baud
rate. If short records are transmitted, the throughput
drops because read/write system call overhead dominates.
Applications can also read a continuous stream of characters
from the serial port without an acknowledging sequence; this
requires greater care in designing the application and is
more subject to problems if the application program must
compete with other applications. On a lightly loaded system
a simple application can read fixed length records at 19,200
baud without data loss or requiring flow control. A program
which copies from one serial port to another using non-
blocking mode, i.e. from a host connection to the user's
terminal, can operate at 9600 baud but will probably lose
characters or require flow control at 19,200 baud.
User-level programs should provide sequencing and checksums
on the information to guarantee accurate data transfer.
CAVEATS
There is no way to specify the rubout character, 0377, as
the record break character.
Printed 4/6/89 3
BK(4) COMMAND REFERENCE BK(4)
The bk driver only works for DMA RS-232 ports.
There is no bk driver support for Tektronix 6130 or
Tektronix 4301 onboard serial ports.
SEE ALSO
tty(4)
Printed 4/6/89 4
%%index%%
na:192,109;
sy:301,156;
de:457,2270;2991,2601;5856,2648;
ca:8504,176;8944,193;
se:9137,144;
%%index%%000000000125