|
|
DDI 8 provides an infrastructure that supports ``hotplug'' devices, which are devices that can be added to and removed from the configuration without rebooting the system or reloading the driver. MDI version 2 network adapter drivers and SDI version 4 HBA drivers that conform to DDI 8 and run on a PCI bus are hotplug-capable; the only additional requirements are:
In order to perform controller hotplug, the platform must provide a hotplug controller driver and concommitant circuitry. OEMs should use the HPCI interface to implement hotplug controller drivers.
The rest of this article provides background information about hotplug devices and how they function on SVR5 operating systems:
See also:
The SVR5 hotplug architecture includes several components:
The DDI 8/8mp versioned interfaces include the driver interface features required to support hotplug of devices. Primarily, this means implementing drivers that have ``instance independence''. This means that the driver state for each device instance is independent of all other instances, so that a new instance can be added at any time, or an instance can be removed and the remaining instances will continue independently. It is also critical that, when a driver is entered on behalf of a particular device instance, it does not access any hardware of another device instance; this allows the driver instances to be independently bound to different CPUs (or, on ccNUMA configurations CPU groups) in case of asymmetric I/O with different device instances constrained to different locations.
In DDI 8, instance independence is implemented with the config(D2) entry point, which is called once for each driver instance that is added or removed. The initialization loop to discover devices through the init(D2) and start(D2) entry point routines is obsoleted in DDI 8. Once the driver is initialized, it receives config( ) calls, at any time, and initializes each device independently. Each device instance is identified by its resource manager key.
With hotplug support, resource manager information is changed more dynamically. To prevent race conditions and ensure consistency, any access to a resource manager entry must be made as part of a resource manager transaction. The transaction is begun with a call to cm_begin_trans(D3) or cm_newkey(D3). Modifications are made with the cm_addval(D3) or cm_delval(D3) functions, and then the transaction is completed with a call to the cm_end_trans(D3) function. Changes made are not visible to the system until after the cm_end_trans( ) function executes. Only one transaction can be in progress at a time (except for read-only transactions). Requests to begin new transactions while a transaction is in progress will block until the previous transaction completes.