I am sponsoring the following fasttrack for Javen Wu with a timeout of
05/28/2008. It introduces a new 'add_drv -c' driver class for scsi(4)
SCSA HBA drivers that support self-identifying children. The proposed
release binding is micro/patch. Additional referenced material is in
the case directory.
-Chris
Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
scsi-self-identifying
1.2. Name of Document Author/Supplier:
Author: Javen Wu
1.3 Date of This Document:
20 May, 2008
4. Technical Description
4.1 Summary
To perform devid discovery from scratch, the IO framework needs to
be able to identify 'sticks' of the device tree where the
configuration of the stick might result in the registration of
devids. The 'ddi-devid-registrant' [1] property names the leaf
drivers that might generate devids, and stub nodes defined in the
leaf driver.conf file identify HBAs that might have children that
bind to the driver. These two things together allow the IO
framework to identify 'all sticks' to configure when trying to
discover the paths to a device with a particular devid. Accurate
'all sticks' information is important when more efficient
devid-path discovery methods, like [2], fail.
Recently, there are more and more self-identifying SCSI HBA
drivers, as defined by [3], which are not of class=scsi. Currently,
we have to add parent="<driver-name>" to the leaf driver.conf files
(sd/ssd) for every self-identifying HBA driver. This
parent="<driver-name>" technique causes cross-driver pollution in
the .conf files of leaf drivers (causing issues with things like
driver class-action scripts). Also, people are forgetting that they
need to do this to ensure proper devid discovery.
So far, we have a lot of HBA drivers that add specific 'stub'
configuration nodes (with parent="<driver_name>") to the leaf
driver.conf files. The examples are the following 'stub' nodes in
sd.conf file and ssd.conf file:
sd.conf:(i386)
name="sd" parent="nv_sata";
name="sd" parent="ahci";
name="sd" parent="si3124";
name="sd" parent="marvell88sx";
ssd.conf:(sparc)
name="ssd" parent="sf" target=0;
name="ssd" parent="fp" target=0;
name="ssd" parent="scsi_vhci" target=0;
Currently, more pollution occurs each time we add a
self-identifying HBA driver to Solaris.
As a solution, this case proposes the introduction of a new class
(ala /etc/driver_classes) called 'scsi-self-identifying'. With this
change, all SCSA self-identifying HBA drivers will be part of the
new class, with a single generic "parent=scsi-self-identifying"
stub node in the leaf .conf files.
4.2 Proposal
The proposed new driver class 'scsi-self-identifying' can be
resisted by self-identifying SCSI HBA drivers during add_drv(1M) or
BFU/upgrade.
At the same time, a generic 'stub' node will be added into
sd.conf/ssd.conf instead of the 'stub' nodes only with parent
property like below:
sd.conf (both x86 and sparc)
name="sd" class="scsi-self-identifying";
ssd.conf
name="ssd" class="scsi-self-identifying";
4.3 Interface Summary
Interface Level Comments
-------------------------------------------------------------------------
scsi-self-identifying Committed driver class to indicate a
SCSA compliant nexus driver
which is not of class=scsi and
is able to dynamically create
self-identifying scsi(4) device
children.
4.4 References
[1] PSARC/2007/477 Drivers Registering Devids
<http://sac.sfbay/PSARC/2007/477>
<http://www.opensolaris.org/os/community/arc/caselog/2007/447>
[2] PSARC/2004/064 Devid Cache
<http://sac.sfbay/PSARC/2004/064/>
<http://www.opensolaris.org/os/community/arc/caselog/2004/064>
[3] PSARC/2004/116 SCSI target compatible property
<http://sac.sfbay/PSARC/2004/116/>
<http://www.opensolaris.org/os/community/arc/caselog/2004/116>
[4] Manpage of scsi(4)
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
