I recently asked the owner of a device driver what type of information about the hardware settings does the device driver return to the application after each job. I was asking about one particular piece of information, a setting that the application tells the device driver to configure in the hardware.

I wanted to know in order to create a unit test that would verify that the hardware was configured properly. By having the device driver return the settings that it used in the hardware, the test harness could verify proper operation. The device driver owner divided information that the device driver uses into three categories.

1. Application-generated – Hardware settings that the application tells the device driver to write directly to registers (with little or no assembly required).
2. Driver-generated – Hardware settings that the device driver has to determine based on external information, and then write to hardware registers. These values might be derived from last-minute events or data obtained from elsewhere in the system.
3. Hardware-generated – Data that the hardware generates while processing the job. The device driver can retrieve this information during or after the job is completed.

Since application-generated information is given to the device driver by the application, in many cases it is of little value for the device driver to turn around and echo that same information back to the application. The test harness can simply look at what the application specified at the beginning of the job.

On the other hand, driver-generated and hardware-generated information is not known by the application. The device driver should return that information to the application which can then make it available to the test harness. The test harness can then independently verify that the device driver generated the appropriate data for the hardware based on the external information and that the hardware-generated results of the job are correct.

I learned that the information needed for the test case was application-supplied, so the device driver did not return it. Given that the device driver did nothing with the information except write it to hardware, I saw that there was no need to enhance the device driver to echo back that data.

For this particular embedded product, this testing approach is appropriate. Other products, such as safety-critical devices, may warrant more in-depth test hooks, such as a separate testing device driver that independently reads all the hardware registers to make sure the device driver under test loaded the registers properly. However, such sophisticated test hooks would likely require a more complex testing infrastructure, requiring more time to develop, and having its own set of challenges, issues, and defects.

• Best Practice: Provide hooks appropriate to the level of testing required to fully exercise hardware/firmware interactions.

Until the next application-generated newsletter…