PATH
Suppose you are shipping your PCI card and have discovered an obscure bug in your expansion ROM driver. This section describes the mechanism that Apple supplies to allow you to update your ROM-based driver with a newer disk-based version.
As described earlier in this chapter, the Name Registry is populated with device nodes that have driver,AAPL,MacOS,PowerPC properties and driver-descriptor properties. These properties are loaded from the expansion ROM and configuration space, installed by the Open Firmware code, and pruned by the Expansion Manager.
After the Registry is populated with device nodes, the Macintosh startup sequence initializes the devices. For every device node in the Registry there are two questions that require answers before the system can complete a client request to use the device. The client may be the system itself or an application. The questions are
If there is a driver in ROM for a device, the driver,AAPL,MacOS,PowerPC property is available in the Name Registry whenever a client request is made to use that device. However, after the operating system is running and the file system is available, the ROM driver may not be the driver of choice. In this case, the ROM-based driver is replaced with a newer version of the driver on disk by the following means.
In the system startup sequence, as soon as the file system is available Mac OS searches the Extensions folder and matches drivers in that folder with device nodes in the Name Registry. For a discussion of driver matching, see Matching Drivers With Devices. The driverInfoStr and version fields of the DriverType fields of the two driver description structures are compared, and the newer version of the driver is installed in the tree. When the driver is updated, the driver-descriptor property and all other properties associated with the node whose names begin with Driver are updated in the Name Registry.
If the driver associated with a node is open (that is, if it was used in the system startup sequence) and if the driver is to be replaced, the system must first close the open driver, using the driver-ref property in the Name Registry to locate it. The system must then update the Registry and reinstall and reopen the driver. If the close or finalize action fails, the driver will not be replaced.
The native driver model does not provide automatic replacement of 68K drivers. It is possible to replace a 68K driver, but it requires some work on your part. If you want to replace a 68K driver with a native driver dynamically, you must close the open 68K driver, extract its state information, and load and install the native driver using the Driver Loader Library. The native driver must occupy the same DCE slot as the 68K driver and use the same reference number. After being opened, it must start running with the state information that was extracted from the 68K driver.
Applications and other software can use the ReplaceDriverWithFragment function to replace one driver with another and RenameDriver to change a driver's name. These routines are described next.