BSP Developer's Guide

VxWorks 5.5
BSP Developer’s Guide
addresses, and so on. The information stored in the control structure is typically
essential to just about every driver entry point. The DEV_OBJ structure is defined
in end.h as follows:
typedef struct dev_obj
{
char name[END_NAME_MAX]; /* device name */
int unit; /* to support multiple units */
char description[END_DESC_MAX]; /* text description */
void* pDevice; /* pointer back to the device data. */
} DEV_OBJ;
name
A pointer to a string of up to eight characters. This string specifies the name for
this network device.
pDevice
A pointer to your driver’s internal control structure. To preserve the
separation of the protocol and data link layers, the MUX treats the pDevice
pointer as opaque. Thus, the MUX never needs know anything about your
control structure. However, when calling your driver’s entry points, the MUX
passes in a cookie (in all calls except the endLoad( ) call). This cookie is a
pointer to the END_OBJ that you allocated in endLoad( ). Through this cookie,
your entry point can get to its device control structure in
pCookie.devObject.pDevice.
unit
This is the unit number for the particular named device. Unit numbers start at
0 and increase for every device controlled by the same driver. For example, if
a system has two Lance Ethernet devices (named ln) then the first one is ln0
and the second is ln1. If the same system also has a DEC 21x40 Ethernet then
that device (whose name is dc) is dc0.
description
This is a text description of the device driver. For example, the Lance Ethernet
driver puts the string, “AMD 7990 Lance Ethernet Enhanced Network Driver”
into this location. This string is displayed if muxShow( ) is called.
Identifying the Entry Points into Your Network Driver: NET_FUNCS
The MUX uses the NET_FUNCS structure to maintain a table of entry points into
your END. The NET_FUNCS structure is defined as follows:
286