|
NAME
SYNOPSIS
Interface Manipulation Functionsif_t
if_t
if_t
void
void
void
void
void
int
int
int
if_t
if_t
void
Interface Address Functionsstruct ifaddr *
struct ifaddr *
struct ifaddr *
struct ifaddr *
void
void
Interface Multicast Address Functionsint
int
struct ifmultiaddr *
Output queue accessors
Output queue macros
if_t accesorsuint64_t
uint64_t
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
int
const char *
void
const char *
int
void
char *
void
int
int
int
int
int
int
int
int
int
int
int
int
int
void *
void
void *
u_int
uint8_t
int
const uint8_t *
void
int
int
int
void
int
int
int
int
int
int
int
int
int
int
u_int
u_int
u_int
void
struct netmap_adapter *
void
int
struct mbuf *
int
void
void
u_int16_t
int
caddr_t
struct vnet *
void *
void
void
void
int
void
int
uint64_t
struct label *
void
struct bpf_if *
uint8_t
void *
struct ifvlantrunk *
bool
struct ifnet Member Functionsvoid
int
void
int
void
int
void
int
struct ifaddr member functionvoid
Global Variablesextern struct ifnethead ifnet;
DATA STRUCTURESThe kernel mechanisms for handling network interfaces reside
primarily in the ifnet, if_data,
ifaddr, and ifmultiaddr
structures in The system keeps a linked list of interfaces using the
Finally, those interfaces supporting reception of multicast
datagrams have a Interfaces are also associated with an output queue, defined as a struct ifqueue; this structure is used to hold packets while the interface is in the process of sending another. The ifnet accessorsThe accessors for if_t are as follows:
References to ifnet structures
are gained by calling the
There are in addition a number of function pointers which the driver must initialize to complete its interface with the generic interface layer:
Interface FlagsInterface flags are used for a number of different purposes. Some flags simply indicate information about the type of interface and its capabilities; others are dynamically manipulated to reflect the current state of the interface. Flags of the former kind are marked ⟨S⟩ in this table; the latter are marked ⟨D⟩. Flags which begin with “IFF_DRV_” are stored in if_drv_flags; all other flags are stored in if_flags. The macro
Interface Capabilities FlagsInterface capabilities are specialized features an interface may or may not support. These capabilities are very hardware-specific and allow, when enabled, to offload specific network processing to the interface or to offer a particular feature for use by other kernel parts. It should be stressed that a capability can be
completely uncontrolled (i.e., stay always enabled with no way to disable
it) or allow limited control over itself (e.g., depend on another
capability's state.) Such peculiarities are determined solely by the
hardware and driver of a particular interface. Only the driver possesses the
knowledge on whether and how the interface capabilities can be controlled.
Consequently, capabilities flags in if_capenable
should never be modified directly by kernel code other than the interface
driver. The command The following capabilities are currently supported by the system:
The ability of advanced network interfaces to offload certain computational tasks from the host CPU to the board is limited mostly to TCP/IP. Therefore a separate field associated with an interface (see ifnet.if_data.ifi_hwassist below) keeps a detailed description of its enabled capabilities specific to TCP/IP processing. The TCP/IP module consults the field to see which tasks can be done on an outgoing packet by the interface. The flags defined for that field are a superset of those for mbuf.m_pkthdr.csum_flags, namely: An interface notifies the TCP/IP module about the tasks the former has performed on an incoming packet by setting the corresponding flags in the field mbuf.m_pkthdr.csum_flags of the mbuf chain containing the packet. See mbuf(9) for details. The capability of a network interface to operate in
polling(4) mode involves several flags in different global
variables and per-interface fields. The capability flag
The if_data StructureThe if_data structure contains statistics and identifying information used by management programs, and which is exported to user programs by way of the ifmib(4) branch of the sysctl(3) MIB. The following elements of the if_data structure are initialized by the interface and are not expected to change significantly over the course of normal operation:
The structure additionally contains generic statistics applicable to a variety of different interface types (except as noted, all members are of type u_long):
Interface TypesThe header file
Interface Link StatesThe following link states are currently defined:
The ifaddr StructureEvery interface is associated with a list (or, rather, a
The members of struct ifaddr are as follows:
References to ifaddr structures
are gained by calling the
FUNCTIONSThe functions provided by the generic interface code can be divided into two groups: those which manipulate interfaces, and those which manipulate interface addresses. In addition to these functions, there may also be link-layer support routines which are used by a number of drivers implementing a specific link layer over different hardware; see the documentation for that link layer for more details. The ifmultiaddr StructureEvery multicast-capable interface is associated with a list of multicast group memberships, which indicate at a low level which link-layer multicast addresses (if any) should be accepted, and at a high level, in which network-layer multicast groups a user process has expressed interest. The elements of the structure are as follows:
Interface Manipulation Functions
Interface Address FunctionsSeveral functions exist to look up an interface address structure
given an address.
All of these functions return a null pointer if no such address can be found. Interface Multicast Address FunctionsThe
The
The
SEE ALSOioctl(2), link_addr(3), queue(3), sysctl(3), bpf(4), ifmib(4), lo(4), netintro(4), polling(4), config(8), ppp(8), mbuf(9), rtentry(9) Gary R. Wright and W. Richard Stevens, TCP/IP Illustrated, Vol. 2, Addison-Wesley, ISBN 0-201-63354-X. AUTHORSThis manual page was written by Garrett A. Wollman.
|