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