Drivers used for diagnostic purposes

There are different scenarios for configuring a resource to test. Depending on the relationship of the resource to be tested with other resources, it may be desirable to use one method over another.

For instance, to unconfigure a resource in order to load a separate diagnostic driver or kernel extension, it is necessary to unconfigure all of the children resources connected to the particular resource, if any. This could cause a problem if the child resources are in use. In this case, it is desirable to use the production driver for diagnostic purposes. In all cases, it is important to restore the resource (and child resources) to their original state after testing.

Production Driver Used for Diagnostic Purposes

If the resource is in the DEFINED state, the resource must be configured before testing. After the resource is configured, tests can be performed on the resource, and then the resource must be put back into its original state.

Separate Diagnostic Driver Used for Diagnostic Purposes

If the resource is in the DEFINED state, the diagnostic driver may be loaded for testing, then unloaded after testing. If the resource is in the AVAILABLE state because the production driver is loaded, it is necessary to unload the production driver, load the diagnostic driver, perform the tests, unload the diagnostic driver, and then reload the production driver. Any child resources must be unconfigured before the resource under test can be unconfigured.

Diagnostic Kernel Extension Used for Diagnostic Purposes

If the resource is in the DEFINED state, the resource must be put into the DIAGNOSE state for testing. If the resource is in the AVAILABLE state because the production driver is loaded, it is necessary to unconfigure the resource and all its children, reconfigure the resource into the DIAGNOSE state, test it, and then reconfigure the resource and all its children back to their original states.