--%<-- > Most previous usages of "soft state" consider one soft state structure > per device-instance (dip), whereas it appears that this project > considers the needs of a nexus driver to store state for each of > potentially multiple child devices.
To clarify - that is not where the need comes from, the ddi_[gs]et_parent_data interfaces solve that problem. When multiple levels of addressing are compressed into a single child unit-addresses "@<component-a>,<component-b>,<component-c>" the parent nexus driver may need to maintain separate state that relates to just one component of the child's unit-address: multiple children that share the same "<component-a>" string value resolve to the same soft_state. This is a nexus driver problem. SCSA HBA drivers are the only public form of nexus driver. At last count we had about 30 SCSA HBA drivers in ON (compared to about 40 NIC drivers). Most new SCSA HBA drivers will face the "<component-a>" string soft-state problem due to complexity of target-port addresses on most modern SCSI transports. I think the need for ddi_ssoft_state* exists, just like the need for the current indexed ddi_soft_state(9F) exists. The SCSA HBA driver writer does not need (or want) a full-blown generic hash table facility: the need is for simple, easy to understand, easy to document interfaces for "<component-a>" string soft_state. -Chris
