BSP Developer's Guide

5
Driver Guidelines
5.4 Design Guidelines
This section discusses guidelines you should follow when designing a driver for
use with Wind River products. Included are discussions of function naming
conventions, documentation standards, per-device and per-driver data structures,
interrupt service routines, and access macros for chip registers.
5
Names and Locations
Follow the Wind River driver naming convention. Be very careful about routine
and variable names. Each module should have a distinctive prefix and every
routine and variable declared must start with that prefix. The coding conventions
document suggests the module-noun-verb method of name construction. You can
also consider it as being proceeding from generic to specific going from left to
right. Related routines must have a common root and be distinct from each other
by their suffixes.
A poor example:
STATUS fooStartPoll (void);
STATUS fooStopPoll (Void);
Should be (assuming they both are related to a polling operation):
STATUS fooPollStart (void);
STATUS fooPollStop (void);
Only Wind River generic drivers are stored in target/src/drv/xxx. This implies that
all drivers are used by more than one BSP, or are expected to be used by more than
one BSP. Third party BSP writers frequently assume that these directories are for
all drivers, including theirs. Because the future is unpredictable, Wind River
reserves all rights with respect to these directories. Third parties must place their
drivers in the same directory as the BSP.
Even Wind River special drivers are placed in the BSP directory. Usually these are
modified versions of a generic driver. Sometimes they are just wrappers that
declare a specialized set of macros and then #include the generic driver.
95