m385(7) — SPECIAL FILES AND DEVICES

NAME

m385 − MVME385 Fiber Distributed Data Interface

SYNOPSIS

#include <sys/dlpi.h>
#include <sys/macioctl.h>
fd = open("/dev/m385_c0", O_RDWR);

DESCRIPTION

The MVME385 is a VMEbus Fiber Distributed Daia Interface (FDDI) Controller for FDDI compatible networks. The m385 device driver supports TCP/IP and OSI protocol stacks. A maximum of 2 (two) boards may be configured in a single system.

The m385 is a STREAMS-based software driver used with the MVME385 FDDI board. The m385 interface conforms to the Data Link Provider Interface (DLPI). In addition, the m385 driver accepts the MAC management commands specified in the MAC Provider Interface (MPI).

The m385 driver can be opened directly, or indirectly from the clone device driver. During the TCP/IP startup, the m385 device is clone opened and linked to the IP and ARP STREAMS modules via the slink command. From then on, m385 converts all the outgoing packets received from IP/ARP to the format defined by the MVME385 board and then passes these packets to the board. If the OSI-DP package is installed on the system and linked into the kernel, the m385 driver will accept outgoing packets from the DLR (OSI LLC1) module.

Upon receiving incoming packets from the MVME385 board, m385 converts these packets to the STREAMS-based DLPI format messages and passes these packets to the appropriate user (e.g., ARP, IP, or DLR).

The mvme385 namer program creates or deletes the device special files for the m385 driver at boot time. The device special filenames, representing the clone devices, are composed of the string m385_cy, where y is the controller number. Controllers are numbered beginning at 0. The device special filename for the first controller in the system is /dev/m385_c0. If a second MVME385 board exists, then its device filename would be /dev/m385_c1. The maximum number of controllers allowed by the driver is two (2).

An m385 device special file major device number is the major device number of the clone device driver. An m385 minor device number follows the format described in the intro(7) man page, i.e., bits 17 through 15 contain the controller number, bit 14 is set, and bits 13 through 0 contain the real major number, which is found in the file /etc/master.d/mvme385.

Besides the device special filename, the driver prefix, m385, is also used as part of the Ethernet network interface name by both cenet in the network database file /etc/strcf and ifconfig in the script /etc/inet/rc.inet.

Each m385 device may have up to eight (8) minor devices open simultaneously. If no changes are made to the default /etc/strcf file, slink will, on TCP/IP startup, open minor devices 0 and 1 via the clone device, m385_c0, and link these to IP and ARP, respectively. Users may want to create their own direct-open minor device files (such as /dev/m385_c0d0, /dev/m385_c0d1, ..., /dev/m385_c0d7). Users wishing to access the driver through these direct-open devices instead of the clone device should consider starting with the last device and working their way backwards.

USAGE

STREAM Message Processing

The following are the types of STREAMS messages the driver can process:

M_PROTO/M_PCPROTO
Six DLPI protocol message types are supported: DL_INFO_REQ, DL_UNITDATA_REQ, DL_BIND_REQ, DL_UNBIND_REQ, DL_ENABMULTI_REQ, and DL_DISABMULTI_REQ. Unsupported message types that are received cause an error message of type dl_error_ack_t with dl_errno set to DL_NOTSUPPORTED to be sent back up the stream.

DL_INFO_REQ is a request for driver information. Driver information is passed back up the stream in a message of type dl_info_ack_t with dl_primitive set to DL_INFO_ACK. However, if enough memory is not available for the driver information, an error message of type dl_error_ack_t is sent back up the stream with dl_primitive set to DL_ERROR_ACK.

DL_UNITDATA_REQ is a request to transmit data. The message is in the dl_unitdata_req_t format. The driver will process this message and send data to the appropriate destination address. Most errors that can occur during this message are turned around in the message itself and sent back up stream in a message with dl_primitive set to DL_UDERROR_IND. If enough memory is not available for processing, an error message of type dl_error_ack_t is sent back up the stream with dl_primitive set to DL_ERROR_ACK.

DL_BIND_REQ is a request to bind a service access point (SAP) to the minor device number associated with the current stream. The request message is of type dl_bind_req_t. A SAP type, as long as it is valid, is assumed to be an FDDI binding. If the OSI-DP package has been installed, the DLR module will bind to this SAP and will receive all 802.3 frames. Once the stream has been bound, an acknowledgement message type dl_bind_ack_t is sent back up the stream. Errors generated during the processing of this message that cause an error message of type dl_error_ack_t to be sent back up the stream are: stream already bound, bad sap value, and cannot allocate memory for acknowledgement.

DL_UNBIND_REQ is a request to unbind the minor device associated with the current stream. Errors generated during message processing that cause an error message of type dl_error_ack_t are: minor device is not bound and cannot allocate enough memory for acknowledgement. An acknowledgement message of type dl_ok_ack_t is generated when the stream has been unbound.

DL_ENABMULTI_REQ is a request to enable a multicast address on a per-stream basis. An individual stream may have a maximum of sixty-four multicast addresses in its table, subject to the following limitation. There may be no more than sixty-four unique addresses for all streams associated with each controller. An acknowledgement message of type dl_ok_ack_t is generated if the request is valid. A message of type dl_error_ack_t is generated with dl_primitive set to DL_BADADDR if the multicast address is invalid or dl_primitive set to DL_TOOMANY if there is no space left in the controller’s multicast table.

DL_DISABMULTI_REQ is a request to disable a multicast address on a per-stream basis. An acknowledgement message of type dl_ok_ack_t is generated if the request is valid. A message of type dl_error_ack_t is generated with dl_primitive set to DL_BADADDR if the multicast address is invalid or dl_primitive set to DL_NOTENAB if the requested address is not currently enabled.

M_IOCTL
ioctl commands are received in messages of type iocblk. There are many ioctl commands supported by the driver. Command data must be stored in a connected message block type M_DATA. Some commands do not require M_DATA blocks; M_DATA block requirements are listed. Data passed back upstream is always contained in an M_DATA block. All of the ioctl #defines used can be found in the file include/sys/macioctl.h.

A description of user ioctl stream messages can be found under the I_STR command in streamio(7).

MACDELAMCA is a request to delete all multicast table entries on the controller associated with this stream. This command does not require an M_DATA block.

MACDELMCA is a request to delete one multicast address from a multicast table on a per-stream basis. This command requires an M_DATA block of type mc_frame.

MACGETIA is a type of request to return the MAC address of the FDDI controller associated with the current queue. This command does not require an M_DATA block.

MACGETMCA is a request to return the entire multicast table for the controller associated with the current queue. This command does not require an M_DATA block.

MACGETSTAT is a request to return a statistic the driver has been gathering. A returned value of −1 indicates the statistic was not available. This command requires an M_DATA block. The data block is an array of structures. Each structure has the following format (see macioctl.h):

        struct macstat {
        long name ;
        long value ;
        }

A table of number defines and their descriptions follow:

MACGETSTAT
Name	Description
MACSTAT_XMITED	number of successful transmits
MACSTAT_XMITED_DEF	number of deferred transmits
MACSTAT_NOXMIT_BUFF	total number dropped frames because of no STREAM buffer
MACSTAT_RECVD	number of frames successfully received
MACSTAT_RECVD_CKSUM	number of CRC errors
MACSTAT_RECVD_ALIGN	number of frames with alignment errors
MACSTAT_NORECV_RES	number of frames dropped because of resource lack
MACSTAT_NORECV_LENGTH	number of frames dropped because of bad length
MACSTAT_RECVD_MCAST	number of multicast frames received
MACSTAT_XMITED_MCAST	number of multicast frames transmitted
MACSTAT_NORECV_MCAST	number of multicast frames rejected
MACSTAT_NORECV_TYPE	number of frames dropped because of unbound type
MACSTAT_DMA_ERRORS	number of DMA errors
MACSTAT_RECVD_BCAST	number of broadcast frames received
MACSTAT_XMITED_BCAST	number of broadcast frames transmitted

MACSETIA is a request to set the MAC address for the FDDI controller associated with the current stream. After executing MACSETIA, the networking subsystem must be stopped and then restarted. The address is subsequently changed in the mvme385.

MACSETMCA is a request to add one multicast address to a multicast table on a per-stream basis. This command requires an M_DATA block of type mc_frame. A multicast address must have the least significant bit of byte[0] of the MAC address set. An individual stream may have a maximum of sixty-four multicast addresses in its table, subject to the following limitation. There may be no more than sixty-four addresses for all streams associated with each controller.

SIOCGENADDR is a type of request to return the MAC address of the FDDI controller associated with the current queue. This command requires an M_DATA block of type struct ifreq.

M_FLUSH
If the command is a read queue flush, the read queue of the driver is flushed and the message is passed back up stream. If the command is a write queue flush, the write queue of the driver is flushed.

FILES

/dev/m385_∗
/usr/include/sys/dlpi.h
/usr/include/sys/macioctl.h
/usr/include/sys/mvme385.h

Museum

Related Articles