Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

dlpi(7p) [freebsd man page]

dlpi(7P)                                                                                                                                  dlpi(7P)

dlpi - Data Link Provider Interface SYNOPSIS
#include <sys/dlpi.h> SunOS STREAMS-based device drivers wishing to support the STREAMS TCP/IP and other STREAMS-based networking protocol suite implementa- tions support Version 2 of the Data Link Provider Interface (DLPI). DLPI V2 enables a data link service user to access and use any of a variety of conforming data link service providers without special knowledge of the provider's protocol. Specifically, the interface is intended to support Ethernet, X.25 LAPB, SDLC, ISDN LAPD, CSMA/CD, FDDI, token ring, token bus, Bisync, and other datalink-level protocols. The interface specifies access to the data link service provider in the form of M_PROTO and M_PCPROTO type STREAMS messages and does not define a specific protocol implementation. The interface defines the syntax and semantics of primitives exchanged between the data link user and the data link provider to attach a physical device with physical-level address to a stream, bind a datalink-level address to the stream, get implementation-specific information from the data link provider, exchange data with a peer data link user in one of three com- munication modes (connection, connectionless, acknowledged connectionless), enable/disable multicast group and promiscuous mode reception of datalink frames, get and set the physical address associated with a stream, and several other operations. Solaris conforms to The Open Group Technical Standard for DLPI, Version 2. For free access to this specification, point your browser to Solaris also provides extensions to the DLPI standard, as detailed in this man page. SOLARIS-SPECIFIC DLPI EXTENSIONS Notification Support Enables DLPI consumers to register for notification when events of interest occur at the DLPI provider. The negotiation may be per- formed on any attached DLPI stream, and begins with the DLPI consumer, sending a DL_NOTIFY_REQ to the provider, which is an M_PROTO message with the following payload: typedef struct { t_uscalar_t dl_primitive; uint32_t dl_notifications; uint32_t dl_timelimit; } dl_notify_req_t; The dl_primitive field must be set to DL_NOTIFY_REQ; the dl_timelimit field is reserved for future use and must be set to zero. The dl_notifications field is a bitmask containing the event types the consumer is interested in receiving, and must be zero or more of: DL_NOTE_LINK_DOWN /* notify when link has gone down */ DL_NOTE_LINK_UP /* notify when link has come up */ DL_NOTE_SDU_SIZE /* notify when link mtu changes */ DL_NOTE_SPEED /* notify when link speed changes */ Consumers may find it useful to send a DL_NOTIFY_REQ message with no requested types to check if the DLPI provider supports the exten- sion. Upon receiving the DL_NOTIFY_REQ, the DLPI provider must generate a DL_NOTIFY_ACK, which is an M_PROTO message with the following pay- load: typedef struct { t_uscalar_t dl_primitive; uint32_t dl_notifications; } dl_notify_ack_t; The dl_primitive field must be set to DL_NOTIFY_ACK. The dl_notifications field must include any requested notifications that the driver supports, along with any other unrequested notifications that the driver supports. However, regardless of the notifications the driver supports, it is restricted to sending only DL_NOTIFY_IND messages (see below) that were requested in the DL_NOTIFY_REQ. Since there are additional notification types which are not yet available for public use, DLPI consumers and providers must take care when inspecting and setting the dl_notifications field. Specifically, consumers must be careful to only request the above notification types, and providers must be careful to not include any unrecognized notification types in the dl_notifications field when constructing the DL_NOTIFY_ACK. DLPI consumers may receive a DL_ERROR_ACK message (with dl_primitive set to DL_NOTIFY_REQ) in response to the initial DL_NOTIFY_REQ message. This message indicates that the DLPI provider does not support the DLPI notification extension. Otherwise, the DLPI consumer will receive a DL_NOTIFY_ACK and should expect to receive DL_NOTIFY_IND messages for any types that it requested that were still set in it. The DL_NOTIFY_IND is an M_PROTO message with the following payload: typedef struct { t_uscalar_t dl_primitive; uint32_t dl_notification; uint32_t dl_data; t_uscalar_t dl_addr_length; t_uscalar_t dl_addr_offset; } dl_notify_ind_t; The dl_primitive field must be set to DL_NOTIFY_IND, and the dl_notification field must be set to the event type that has occurred (e.g., DL_NOTE_LINK_DOWN). only a single event type may be set in each DL_NOTIFY_IND. For the DL_NOTE_SPEED event type, dl_data must be set to the current interface speed in kilobits per second, and for the DL_NOTE_SDU_SIZE event type, dl_data must be set to the cur- rent MTU in bytes; otherwise, dl_data must be set to zero. The other members of this structure are not yet available for public use and must be set to zero by DLPI providers and ignored by DLPI consumers. In addition to generating DL_NOTIFY_IND messages when a requested event has occurred, the DLPI provider must initially generate one or more DL_NOTIFY_IND messages to notify the DLPI consumer of the the current state of the interface. For instance, if the consumer has requested DL_NOTE_LINK_UP | DL_NOTE_LINK_DOWN, the provider must send a DL_NOTIFY_IND containing the current state of the link (either DL_NOTE_LINK_UP or DL_NOTE_LINK_DOWN) after sending the DL_NOTIFY_ACK. For the initial DL_NOTIFY_IND message, the DLPI provider is strongly recommended against sending DL_NOTE_LINK_DOWN, even if the inter- face is still initializing and is not yet ready to send or receive packets. Instead, either delaying the DL_NOTIFY_IND message until the interface is ready or optimistically reporting DL_NOTIFY_LINK_UP and subsequently reporting DL_NOTE_LINK_DOWN if the negotation fails is strongly preferred. This prevents DL_NOTIFY_IND consumers from needlessly triggering network failover operations and logging error messages during network interface initialization. The DLPI provider must continue to generate DL_NOTIFY_IND messages until it receives a new DL_NOTIFY_REQ message or the DLPI stream is detached (or closed). Further, a DLPI style 2 driver must keep track of the requested events after a DL_DETACH_REQ operation, and if a subsequent DL_ATTACH_REQ is received, it must send gratuitous DL_NOTIFY_IND messages to notify the consumer of the current state of the device, since the state may have changed while detached (or the consumer may have simply discarded its previous state). Files in or under /dev. hme(7D), ge(7D), qfe(7D), gld(7D) NOTES
Streams drivers for network interface cards (NIC) must meet the following driver name constraints: o Length -- Name cannot exceed 16 characters. Names containing three to eight characters are preferred. o Legal Characters -- Legal characters are: alphanumeric (a-z, A-Z, 0-9), and the underscore ('_'). Additionally, the first and/or last character of a name cannot be a digit. 7 Feb 2005 dlpi(7P)
Man Page