I am sponsoring the following fasttrack for myself. Micro/patch binding
is requested. I believe the case qualifies for self review (since all
the interfaces are Consolidation Private) and have filed it as Closed
Approved Automatic. If there is a request, I'd be happy to convert it
to a fasttrack and set the timer to enable further discussion.
-Chris
1. Introduction
1.1. Project/Component Working Name:
mdi_is_dev_supported
1.2. Name of Document Author/Supplier:
Author: Chris Horne
1.3. Date of This Document:
Tue Feb 17 19:48:03 MST 2009
4.0 Technical Description
For a given pHCI device unit-address, the current MPxIO [1] pHCI
devinfo.vs.pathinfo enumeration sequence must be:
1. For device at given unit-address, obtain device identity
information using pHCI private methods.
2. Assume that device will be supported by vHCI: create
pHCI-pathinfo/vHCI-client representation.
3. Online pHCI-pathinfo/vHCI-client. If above assumption was
incorrect, online will fail.
4. If pHCI-pathinfo/vHCI-client online above failed:
4a: Tear down pHCI-pathinfo/vHCI-client enumeration.
4b: Perform pHCI-devinfo enumeration.
A new, alternative, MPxIO enumeration sequence is proposed. The new
enumeration sequence has three goals:
1. Reuse: Obtain device identity information using existing pHCI
transport services.
In the current sequence, not being able to reuse existing pHCI
transport services complicates pHCI driver implementation
substantially.
2. Don't assume: Ask the vHCI if something is supported, and
enumerate based that answer.
In the existing sequence, having to unwind after making an
incorrect assumption complicates a pHCI driver implementation.
3. Don't break things: Support for the new sequence can't break
consumers using the current sequence.
The new sequence is an alternative, not a replacement of the
existing sequence - both sequences are supported.
For a given pHCI device unit-address, the new MPxIO pHCI enumeration
devinfo.vs.pathinfo enumeration sequence will be:
1. For device at given unit-address:
1a: Initialize a transitory "probe" pHCI-devinfo child (bound
to nulldriver [2] and hidden [3]).
1b: Obtain device identity information using existing
pHCI-devinfo transport methods.
2. Use the new mdi_is_dev_supported() interface to ask the vHCI
code if the device being "probed" by the pHCI code is
supported.
2a: YES: perform pHCI-pathinfo/vHCI-client enumeration.
2b: NO: perform pHCI-devinfo enumeration.
In the vHCI implementation of vo_is_dev_supported(), it is possible
(by agreement between the pHCI and vHCI) to have the vHCI code
issue additional commands, using the initialized "probe" node
transport, to determine device support
The new mdi_is_dev_supported() function returns MDI_SUCCESS to the
pHCI enumeration code if the vHCI supports the device, otherwise
MDI_FAILURE is returned.
In the case of scsi_vhci, the vo_is_dev_supported implementation
uses existing code to determine if there is a failover module
willing to accept responsibility for the path management of the
device.
4.5 Interfaces:
------------------------------------------------------------------
Interface Name Comm.Lev. Comments
------------------------------------------------------------------
mdi_is_dev_supported Cons.Private Does vHCI support a
device?
vo_is_dev_supported " new mdi_vhci_ops_t
ops_vector function
pointer.
Prototypes (common/sys/mdi_impldefs.h):
int mdi_is_dev_supported(char *class,
dev_info_t *pdip, void *cinfo);
int (*vo_is_dev_supported)(dev_info_t *vdip,
dev_info_t *pdip, void *cinfo);
What was defined as vhci_ops_t in [1] was delivered as
mdi_vhci_ops_t, and the details of what is represented in the PSARC
case (Consolidation Private) differer dramatically from the
delivered mdi_vhci_ops_t ops vector. The above interfaces extend
mdi_vhci_ops_t by adding vo_is_dev_supported. While mdi_vhci_ops_t
is a versioned interface, it is also consolidation private with no
contracts or known consumers outside ON. Given this, we opted to
not roll the version number - it is cleaner to just make the
required changes (while there is no exposure, avoid accumulating
version checking code that serves no real purpose).
While SCSAv3 work will use these interfaces, there is no intent to
ever promote the above interfaces - use will be well hidden from
HBA drivers by other new SCSA discovery and enumeration
interfaces.
4.6 Man page changes:
None.
4.7 Release Binding
Micro/patch binding is requested.
4.8 References
[1] PSARC/1999/647 Multiplexed I/O Framework
http://sac.eng/PSARC/1999/647
http://www.opensolaris.org/os/community/arc/caselog/1999/647
http://sac.eng/PSARC/1999/647/related_cases.html
[2] PSARC/2008/674 nulldriver
http://sac.eng/PSARC/2008/674
http://www.opensolaris.org/os/community/arc/caselog/2008/674
[3] PSARC/2009/103 ndi hidden nodes
http://sac.eng/PSARC/2009/103
http://www.opensolaris.org/os/community/arc/caselog/2009/103
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: Automatic
6.6. ARC Exposure: open
