From cth@sac.sfbay.sun.com Tue Feb 17 19:07:50 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1I37okF008173 for ; Tue, 17 Feb 2009 19:07:50 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n1I37on6008050; Tue, 17 Feb 2009 19:07:50 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KF800I03RD1KA00@brm-avmta-1.central.sun.com>; Tue, 17 Feb 2009 20:07:49 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KF800I8QRD1YAF0@brm-avmta-1.central.sun.com>; Tue, 17 Feb 2009 20:07:49 -0700 (MST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1I37mo8007267; Tue, 17 Feb 2009 19:07:48 -0800 (PST) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1I37lng008168; Tue, 17 Feb 2009 19:07:47 -0800 (PST) Received: (from cth@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n1I37lOs008164; Tue, 17 Feb 2009 19:07:47 -0800 (PST) Date: Tue, 17 Feb 2009 19:07:47 -0800 (PST) From: Christopher Horne Subject: mdi_is_dev_supported [PSARC/2009/114 Self Review] To: PSARC-ext@sun.com Cc: scsav3-eng@sun.com Message-id: <200902180307.n1I37lOs008164@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 5419 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