BSP Developer's Guide

VxWorks 5.5
BSP Developer’s Guide
etherInputHook( ) decides to prevent others from seeing the packet,
etherInputHook( ) returns a non-zero value and the driver considers the packet to
be delivered. If the etherInputHook( ) returns 0, the driver hands the packet to the
TCP/IP stack.
On packet transmission, an installed etherOutputHook( ) receives a packet just
before it would have been transmitted. If etherOutputHook( ) decides to prevent
the packet from passing on, etherOutputHook( ) returns a non-zero value and the
driver considers the packet to be transmitted. If the etherOutputHook( ) returns 0,
the driver transmits the packet.
It is only possible to install one etherInputHook( ) and one etherOutputHook( )
function per driver. This limits the number of alternate protocols to one, unless
these ether*Hook( ) routines then act as a multiplexor for more protocols.
For more information on etherhooks, see the Tornado User’s Guide, 1.0.1:
G.4 Network Interface Hook Routines.
NOTE: Future versions of VxWorks will not support etherhooks.
G.2 Upgrading to 4.4 BSD
To upgrade a driver from 4.3 BSD to 4.4 BSD you must change how the driver uses
ether_attach( ). This routine is almost always called from the driver’s own
xxattach( ) routine and is responsible for placing the driver’s entry points, listed in
Table G-1, into the ifnet structure that the TCP/IP protocol to track drivers.
Consider the call to ether_attach( ) shown below:
ether_attach(
(IFNET *) & pDrvCtrl->idr,
unit,
"xx",
(FUNCPTR) NULL,
(FUNCPTR) xxIoctl,
(FUNCPTR) xxOutput,
(FUNCPTR) xxReset
);
As arguments, this routine expects an Interface Data Record (IDR), a unit number,
and a quoted string that is the name of the device, in this case, “xx”. The next four
arguments are the function pointers to relevant driver routines.
260