刚查了下资料:
The END is the original MUX network driver interface. ENDs are frame-oriented drivers that exchange frames with the MUX. The NPT-style drivers are packet-oriented drivers that exchange packets with the MUX. These packets are stripped of all datalink layer information. Currently, all network drivers supplied by Wind River are ENDs, as is the generic driver template defined in templateEnd.c. There is no generic template for an NPT driver.
Support for the NPT-style driver is part of a set of MUX extensions designed to facilitate the implementation of MUX-compatible network services. These extensions include a registration mechanism for an alternative address resolution utility and support for back ends that let you extend the sockets API so that applications can use sockets to access a new network service
END与NPT的收包函数区别:
After a driver is loaded in to the MUX and has been bound to a protocol, it can pass received packets up to the MUX by calling muxReceive( ), if it is an END, or muxTkReceive( ), in NPT drivers.
How ENDs and NPT Drivers Differ:
-
The NPT driver is a packet-oriented equivalent to the frame-oriented END. Both the NPT driver and the END are organized around the END_OBJ and the NET_FUNC structures, and both driver styles require many of the same entry points:
-
xLoad( ) - load a device into the MUX and associate a driver with the device
-
xUnload( ) - release a device, or a port on a device, from the MUX
-
xSend( ) - accept data from the MUX and send it on towards the physical layer
-
xMCastAddrDel( ) - delete a multicast address registered for a device
-
xMCastAddrGet( ) - get a list of multicast addresses registered for a device
-
xMCastAddrAdd( ) - add a multicast address to those registered for a device
-
xPollSend( ) - send packets in polled mode rather than interrupt-driven mode
-
xPollReceive( ) - receive frames in polled rather than interrupt-driven mode
-
xStart( ) - connect device interrupts and activate the interface
-
xStop( ) - stop or deactivate a network device or interface
-
xIoctl( ) - support various ioctl commands2
-
xBind( ) - exchange data with the protocol layer at bind time (optional)3
-
For the most part, the prototypes for these entry points are identical. The exceptions are the send and receive entry points.
-
- NPT send entry points take these additional parameters:
-
- a MAC address character pointer
-
- a networks service type value
-
- a void* pointer for any network service data the driver might need in order to prepare the packet for transmission on the physical layer
-
- NPT receive entry points likewise take additional parameters:
-
-
- a pointer to the start of the network frame
-
- a void* pointer for any addition network service data that is important to the protocol layer
-
The three END entry points not included in an NPT driver are:4
-
xAddressForm( ) - add addressing information to a packet
-
xAddrGet( ) - extract the addressing information from a packet
-
xPacketDataGet( ) - separate the addressing information and data in a packet
-
The above functions were removed from the NPT driver because they are frame-oriented and so irrelevant to a packet-oriented driver.
-
The following registration interface lets you manage an address resolution function for a protocol/interface pair.
-
muxAddrResFuncAdd( ) - add an address resolution function
-
muxAddrResFuncGet( ) - get the address resolution function for ifType/protocol
-
muxAddrResFuncDel( ) - delete an address resolution function
-
For Ethernet devices, the standard VxWorks implementation automatically assigns arpresolve( ) as the address resolution function. If you are writing an END that does not run over Ethernet, you also need to implement the xAddressForm( ), xAddrGet( ), and xPacketDataGet( ) entry points explicitly. ENDs running over Ethernet typically use the endLib implementations of these functions.