is recommended over:

    struct device_reg {
         uint8_t csr;
         uint8_t data;
     };
     volatile struct device_reg *regp;

Although the two examples are functionally equivalent, the second one requires the writer to ensure that volatile is used in every declaration of type struct device_reg. The first example results in the data being treated as volatile in all declarations and is therefore preferred. Note as mentioned above, that the use of the DDI data access functions to access device registers makes it unnecessary to qualify variables as volatile.

Serviceability

To ensure serviceability, the driver must be enabled to do the following:

• Detect faulty devices and report the fault

• Remove a device (as supported by the Solaris hot-plug model)

• Add a new device (as supported by the Solaris hot-plug model)

• Perform periodic health checks to enable the detection of latent faults

Periodic Health Checks

A latent fault is one that does not show itself until some other action occurs. For example, a hardware failure occurring in a device that is a cold stand-by could remain undetected until a fault occurs on the master device. At this point, the system now contains two defective devices and might be unable to continue operation.

As a general rule, latent faults that are allowed to remain undetected will eventually cause system failure. Without latent fault checking, the overall availability of a redundant system is jeopardized. To avoid this, a device driver must detect latent faults and report them in the same way as other faults.

The driver should ensure that it has a mechanism for making periodic health checks on the device. In a fault-tolerant situation where the device can be the secondary or fail-over device, early detection of a failed secondary device is essential to ensure that it can be repaired or replaced before any failure in the primary device occurs.

Periodic health checks can:

• Check a register or memory location on the device whose value the driver expects to have been deterministically altered since the last poll.

  Features of a device that typically exhibit deterministic behavior include heartbeat semaphores, device timers (for example, local lbolt used by download), and event counters. Reading an updated predictable value from the device gives a degree of confidence that things are proceeding satisfactorily.

• Time-stamp outgoing requests (transmit blocks or commands) when issued by the driver.

  The periodic health check can look for any over-age requests that have not completed.

• Initiate an action on the device that should be completed before the next scheduled check.

  If this action is an interrupt, this is an ideal way of ensuring that the device's circuitry is still capable of delivering an interrupt.