BOCA(4) BSD Kernel Interfaces Manual BOCA(4)NAME
boca -- multiplexing serial communications interface
SYNOPSIS
For 4-port BB1004 boards:
boca0 at isa? port 0x100 irq 5
com2 at boca? slave ?
com3 at boca? slave ?
com4 at boca? slave ?
com5 at boca? slave ?
For 8-port BB1008 boards:
boca0 at isa? port 0x100 irq 5
com2 at boca? slave ?
com3 at boca? slave ?
com4 at boca? slave ?
com5 at boca? slave ?
com6 at boca? slave ?
com7 at boca? slave ?
com8 at boca? slave ?
com9 at boca? slave ?
For 16-port BB2016 boards:
boca0 at isa? port 0x100 irq 5
com2 at boca? slave ?
com3 at boca? slave ?
com4 at boca? slave ?
com5 at boca? slave ?
com6 at boca? slave ?
com7 at boca? slave ?
com8 at boca? slave ?
com9 at boca? slave ?
boca1 at isa? port 0x140 irq 5
com10 at boca? slave ?
com11 at boca? slave ?
com12 at boca? slave ?
com13 at boca? slave ?
com14 at boca? slave ?
com15 at boca? slave ?
com16 at boca? slave ?
com17 at boca? slave ?
(The BB2016 is functionally equivalent to two BB1008 boards, and is configured as such.)
DESCRIPTION
The boca driver provides support for BOCA Research BB1004, BB1008 and BB2016 boards that multiplex together up to four, eight or sixteen EIA
RS-232C (CCITT V.28) communications interfaces.
Each boca device is the master device for up to eight com devices. The kernel configuration specifies these com devices as slave devices of
the boca device, as shown in the synopsis. The slave ID given for each com device determines which bit in the interrupt multiplexing regis-
ter is tested to find interrupts for that device. The port specification for the boca device is used to compute the base addresses for the
com subdevices and the port for the interrupt multiplexing register.
FILES
/dev/tty??
SEE ALSO com(4)HISTORY
The boca driver was written by Charles Hannum, based on the ast driver and source code from David Muir Sharnoff. David wishes to acknowledge
the assistance of Jason Venner in determining how to use the BOCA boards.
BSD January 3, 1995 BSD
Check Out this Related Man Page
pts(7) Miscellaneous Information Manual pts(7)NAME
pts - STREAMS slave pty (pseudo-terminal) driver
SYNOPSIS DESCRIPTION
A pseudo-terminal (pty) consists of a tightly-coupled pair of character devices, called the master device and slave device. The pty master
and slave device drivers work together to simulate a terminal connection where the master provides a connection to the pseudo terminal
server process and the slave provides a terminal device special file access for the terminal application processes, as depicted below:
----------------
| pty functions |
Application <--> |----------------| <--> Server
Processes | Slave | Master | Process
| (pts) | (ptm) |
----------------
The slave driver, with (STREAMS pty emulation module) and (STREAMS line discipline module) pushed on top (not shown for simplicity), pro-
vides a terminal interface as described in termio(7). Whereas devices that provide the terminal interface described in termio(7) have a
hardware device behind them; in contrast, the slave device has another process manipulating it through the master side of the pty. Data
written on the master device is given to the slave device as input and data written on the slave device is presented as input on the master
device.
In order to use the STREAMS pty subsystem, a node for the master pty driver and N number of slave pty devices must be installed (see ptm(7)
for more details on master pty). When the master device is opened, the corresponding slave device is automatically locked out. No user
can open that slave device until its permissions are changed (via the function) and the device is unlocked (via the function). The user
then call the function to obtain the name of the slave device and invoke the system call to open the slave device. Although only one open
is allowed on a master device, multiple opens are allowed on the slave device. After both the master and slave have been opened, the user
has two file descriptors which represent the end points of a full duplex connection composed of two streams that are automatically con-
nected by the master and slave devices when they are opened. The user may then push the desired modules (for example, and on for terminal
semantics and on for Packet Mode feature).
The master and slave drivers pass all STREAMS messages to their adjacent drivers. Only the message needs some special processing because
the read queue of the master is connected to the write queue of the slave and vice versa. For example, the flag is changed to flag and
vice versa whenever a message travels across the master-slave link. When the master device is closed, an message is sent to the corre-
sponding slave device which will render that slave device unusable. The process on the slave side gets the errno when attempting a system
call to the slave device file but it will be able to read any data remaining in the slave stream. Finally, when all the data has been
read, the system call will return 0, indicating that the slave can no longer be used. On the last close of the slave device, a zero-length
message is sent to the corresponding master device. When the application on the master side issues a read(2) or getmsg(2) system calls, a
0 (zero) is returned. The user of the master device may decide to close the master device file, which dismantles the stream on the master
side. If the master device remains opened, the corresponding slave device can be opened and used again by another user.
EXAMPLES
The following example shows how a STREAMS pty master and slave devices are typically opened.
AUTHOR
was developed by HP and OSF.
FILES
Streams pty master clone device
Streams pty slave devices (0 <=
N < where is a kernel tunable parameter which can be changed via SAM (see sam(1M)).
SEE ALSO insf(1M), sam(1M), getmsg(2), ioctl(2), open(2), read(2), write(2), grantpt(3C), ptsname(3C), unlockpt(3C), ldterm(7), ptem(7), ptm(7),
streamio(7), termio(7).
pts(7)