BSP Developer's Guide

H
Implementing a MUX-Based Network Interface Driver
H.3 Guidelines for Handling Packet Reception in Your Driver
The list of END entry points (see Table H-1) makes no mention of an endReceive( )
entry point. That is because an END does not require one. Of course, your driver
must include code that handles packet reception, but the MUX never calls this code
directly. Thus, the specifics of the code for packet reception are left to you.
However, even if the MUX API does not require an endReceive( ) entry point, you
need to consider the VxWorks system when designing your driver’s packet
reception code. For example, your network interface driver must include an entry
point that acts as your device’s interrupt service routine. In addition, your driver
also needs a different entry point for completing packet reception at the task level.
Internally, your task-level packet-reception entry point should do whatever is
necessary to prepare the packet for handing off to the MUX, such as assuring data
coherency. Likewise, this entry point might use a level of indirection in order to
check for and avoid race conditions before it attempts to do any processing on the
received data. 3 When all is ready, your driver should pass the packet up to the
MUX. To do this, it calls the function referenced in the receiveRtn member of the
END_OBJ structure (see Providing Network Device Abstraction: END_OBJ, p.283).
Although your driver’s endLoad( ) entry point allocated this END_OBJ structure
and set the values of most of its members, it did not and could not set the value of
the receiveRtn member. The MUX does this for you upon completion of the
muxDevLoad( ) call that loaded your driver. However, there is a very brief interval
between the time the driver becomes active and the completion of muxDevLoad( ).
During that time, receiveRtn might not be set. Thus, it is a good practice always to
check receiveRtn for NULL before you try to execute the function referenced there.
H
Removing Etherhook Code in Ported Drivers
The BSD 4.3 model for a VxWorks network interface drivers support a set of input
and output hooks that you can use to intercept packets as they pass between the
driver and protocol. These input and output hooks are referred to as the etherhooks.
When porting a driver to the END model, you must remove the code (if any) that
implements etherhooks. ENDs have no need of etherhooks. That functionality is
built into the MUX. For more information, see the discussion of etherhooks in the
Tornado User’s Guide, 1.0.1.
3. See the sample driver in target/src/drv/end/ln7990End.c.
275