4.4.2 Choosing Names for NT Driver Routines

Except for the DriverEntry routine, the names used for the standard driver routines in this documentation were chosen to describe the functionality of each type of standard routine, and, in some cases, to provide hints about which types of NT objects a driver with particular standard routines must use. You can name most standard driver routines anything you like in your driver.

However, any NT driver is easier to develop, debug, and test when the driver writer uses a naming scheme that distinguishes that driver's routines from those of other drivers. An NT driver is also easier to debug and test if the driver writer uses names that distinguish between the driver's standard routines and its internal routines.

Consequently, most system-supplied NT drivers have routine names that follow these guidelines:

·Prepend a driver-specific prefix to each routine, preferably one prefix for all standard routines and another for all internal routines.

·Create a name for each routine that indicates its functionality and, when debugging and testing, where in the driver a given IRP is being processed.

For example, the system keyboard class driver prepends KeyboardClass to its standard driver routines, and Kbd to its internal routines. Other system drivers use a single identifying prefix on every routine, but prepend the lower-case letter "p" (for private) to this prefix for their internal routines.

Each routine in the system keyboard class driver also has a name that indicates the routine's functionality. This driver's Dispatch routines are named according to the IRP_MJ_XXX that each routine handles: KeyboardClassOpenClose, KeyboardClassRead, KeyboardClassDeviceControl, and so forth. Other standard routines in this driver have names such as KeyboardClassStartIo and KeyboardClassCancel to aid the driver's developer in tracing the path of IRPs through the driver.

The keyboard class driver's naming conventions also aid system test engineers in evaluating the performance of this driver, in finding out whether any particular driver routine is a performance bottleneck, and in finding the exact location of any bug if problems occur in this driver during regression testing.