Summary: An overview of the Production Quality Driver (PQD) initiative. General guidelines and checklists from Microsoft for Windows CE device driver development.

---

The Production Quality Driver (PQD) initiative is an effort to reduce OEM time-to-market by providing drivers that are easier to configure and of higher quality.

Each driver that meets the PQD standards has an associated "PQD" document. For example, there is a "Keyboard PQD" document and a "USB Function PQD" document.

A PQD document template can be downloaded from here

PDQ documents define:
* Goals
* Functional coverage
* List of individual components
* Mapping from requirements specification to components
* Architectural diagrams
* High-level process flow
* Organizational illustration
* Relationships with other system components
* Security issues
* Architecturally relevant threat models
* Security features specifically utilized
* Description of review process and procedures in context
* Risk factors
* Identification of general factors
* Outside dependencies
* Special schedule targets that must be met
* Acceptance criteria
* Exit criteria for completed implementation
* Critical features/scenarios that must be completed to guage success
* Expected performance profile
* Specifically expected or known limitations
* Deliverables
* Services,UI,utilities,setup,update,database
* Resources
* Documentation to (re)create the component
* Documentation to support future porting
* Dependencies
* Unresolved issues
* Assumptions
* Extenal dependencies
* Testing information and resources
* Unit testing
* Scenarios for test
* General testing guidance for high-risk areas

Technically, the document enumerates many default questions that must be asked of any driver which is developed. These questions must be answered effectively in order for the PQD review to pass. If the answer to these questions is "no" or "not applicable", the driver implementer must explain what will be done to address the issue at hand or explain why it does not affect their driver. The questions include but are not limited to:

* Power management:
* Does the driver work under both the stub and full versions of the power manager?
* What are the power states supported by the device?
* Does the driver expose calling of the power manager stream driver ""IOCTLs""?
* Does the driver ignore the deprecated IOCTLPOWERQUERY?
* Does the driver handle XXXPowerUp() and XXXPowerDown() appropriately?
* Does the driver call its bus parent for power management as appropriate?
* Does the driver properly handle interleaved PM ""IOCTLs"" and I/O operations?

* Business roles/flow:
* What are the rules/models for the feature?
* What are the critical scenarios for the component?
* What does a diagram of the flow look like?

* Implementation details:
* Are algorithms used specifically by the driver specified?
* Are code changes required due to the use of the driver specified?
* Is the specialization of the driver handled through a registry setting, or (for a driver which cannot use the registry) a header file?

* External interface and portability
* If the driver is a required component, can it be easily replaced?
* Have registry settings been used to simplify porting?
* Have appropriate header files been designed to simplify porting?
* Has all applicable functionality been abstracted to a library to simplify porting?
* Has all applicable functionality been abstracted to a source file to simplify porting?
* If the driver is bus agnostic, does it try to use an IISR but have an appropriate fallback if one does not exist?
* Does the driver use the ""DDKReg_xxx()"" functions where applicable?
* Does the driver get all of its physical addresses from the registry?
* Are thread priorities configurable from the registry?

PQD code should not be confusing for customers. PQD code should do things the right way because developers will mimic bad examples as readily as good examples. The PQD document writer must describe any parts of the driver that are particularly bad, or will require a significant amount of work. Confirmations needed here are:

* Have all “driver globals” been removed from the driver?
* Do the SOURCES files specifically avoid the invalid DOSYSGEN logic?
* Are all source and header files used?
* Is there any code in headers or source files that is not used?
* Does the driver initialize all module-level global variables in the rtl initialization or in the DllEntry’s DLLPROCESSATTACH processing?
* Does the driver initialize all instance-level global variables in the Init() function?
* Does the DllEntry’s DLLPROCESSATTACH call ""DisableThreadLibraryCalls()"" for each DLL? (Note that ISR ""DLLs"" cannot call this routine)
* Has the implementer avoided duplicated code in the driver that should be made into a function?
* Has the implementer avoided duplicated code between separate drivers that should be made into a shared library or added to CEDDK?
* Are there no unnecessary critical sections?
* Have all the source files been indented using four spaces for tabs?
* Is the code well-commented?
* Is the code readable and understandable?
* Does new code follow the WDC coding conventions?
* Does the code follow the law of least astonishment when esoteric language or OS features are used?
* Does this driver use the bus parent function calls instead of the ""HalXxx"" calls?
* If you expect a C++ clase to have subclasses, is the destructor declared virtual?

PQD code should not crash unexpectedly or elevate privileges. This is especially important moving forward using the CE 6+ kernel, since many drivers should execute in user mode. The PQD document writer must describe any parts of the driver that have special security risks. Questions to be answered affirmatively are:

* Does the driver _try/_except when accessing an externally provided buffer from an internal thread?
* Does the driver unnecessarily check access permissions on top-level pointers in IOCTL calls?
* Does the driver unnecessarily _try/_except around accesses to top-level pointers in IOCTL calls?
* Does the driver check access permissions on nested pointers in IOCTL calls?
* Does the driver need to use XXX_PreDeinit to handle concurrent driver I/O requests and deactivation?
* Does the driver _try/_except hardware accesses as appropriate?
* Does the driver use CEDDK functions for hardware access, not macros in wdm.h?
* Does the driver check return values for calls that can legitimately fail?
* Has this driver been security threat modeled?
* For circumstances that can legitimately occur, does the driver avoid use of ""DEBUGCHKs"" or ""ASSERTs""?

PQD code should be self-validating through the use of validation functions and assertions. Debug zones should be granular enough to be useful. These items are optional for the developer with respect to coding, but they must still be filled out in this specification. If this driver does not meet expectations in any issue, a bug should be filed against the driver so that there is a record of each deficiency. Validation questions are:

* Are all assumptions explicit through the use of ""DEBUGCHKs""?
* Are there validation functions that are used to validate important structures, global data, device state, etc?
* Are the debug zones granular enough to be useful?

Finally, after the implementer is finished making changes to bring the driver up to PQD standards and answers "yes" or "not applicable" to all the questions above, there is a final checklist to for verification:

* Does new code follow coding standards?
* Have unit tests been created and successfully built and run by a code reviewer?
* Did ""AppVerifier"" find no leaks or other bad behavior?
* Is this driver ""PREFast"" clean?

By following the above guidelines it is hoped that any new PQD drivers created meet a standard of quality which our customers expect and deserve.

We encourage all driver writers to investigate the questions posed above when writing a new driver. While most drivers writers measure 'completeness' based on having a working driver, but to get an A+ you must also think about things like abstraction and portability, security, power management, etc.

---

Go up to Features of a BSP
Go up to Big Book of BSP

PS – We value your feedback, but please DO NOT directly edit this page. Instead, submit your feedback and topical suggestions to bspwiki""@""microsoft""."" com.

---