BSP Developer's Guide

VxWorks 5.5
BSP Developer’s Guide
H.3.2 Swapping Buffers Between Protocol and Driver
To pass a buffer up to the MUX, a driver calls muxReceive( ), which, in turn, calls
the protocol’s stackRcvRtn( ) routine (see Passing a Packet Up to the Protocol:
stackRcvRtn( ), p.307). When control returns from muxReceive( ), the driver can
consider the data delivered and can forget about the buffers it handed up to the
MUX. When the upper layers are done with the data, they free the buffers back to
the driver’s memory pool.
This system is implicitly a buffer loaning system. If a device cannot receive data
directly into clusters, it must first allocate its own memory (apart from a network
buffer pool) and explicitly copy the data from its private memory into a cluster
before passing it in an mBlk up to the MUX.
H.3.3 Using Private Memory Management Routines
If your device does not allow you to use the MUX memory-management utilities,
you can write replacements for the ones provided by netBufLib. However, your
replacements must conform to the API for these routines.
H.3.4 Supporting Scatter-Gather in Your Driver
Some devices support breaking up a single network packet into separate chunks
of memory. This makes it possible to pass a packet (such as a list of mbufs from a
Berkeley-type TCP/IP protocol) as a chain of mBlk/clBlk/cluster constructs.
When a driver gets a chain of mBlks, it can decide at that point to transmit the
clusters in the chain in any way it likes. If it can do a gather-write, then it need not
do any data copying. If it cannot, then it has to put all of the data from the chain
into a single memory area before transmitting it. This decision is driven by the type
of network device for which the driver is implemented.
H.4 Indicating Error Conditions
Sometimes an END encounters errors or other events that are of interest to the
protocols using that END. For example, the device could have gone down, or the
280