Subject: Re: contract for PSARC 2006/372 From: Vincent Eberhard Date: Thu, 01 Jun 2006 18:43:56 -0600 To: Hyon Kim CC: Peter.Luk@Sun.COM, Paul von Behren , Carla Mowers Hyon, I approve this agreement. Thanks, Vince Hyon Kim wrote: > > Hi Vince and Peter, > > As part of PSARC 2006/372, the contract for mdi_pi_enable/disable_path needs to > be provided for NWS use of the interfaces. Please review the contract and let me know > if you have any issues. Otherwise please send me an approval email. Your prompt review > will be appreciated. > > I have also attached the fastrack email. > > --Hyon > > > ------------------------------------------------------------------------ > > @(#)contract 1.6 @(#) /shared/sac/arcARC-Templates/contract [1.6 02/03/27] > > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: > | PSARC/2006/372/contract-01 > | > | (amends and supersedes PSARC/2003/322/contract-01 to include > | new mdi_* interfaces introduced by PSARC/2006/103; changes > | indicated by left-margin change-bars.) > > 1. This contract is between > a SUPPLIER of INTERFACES and > a CONSUMER of those INTERFACES, > both of whom are entities within Sun Microsystems, Incorporated. > > 2. The SUPPLIER (definer and/or implementor) is identified by the following: > Product or Bundle: Solaris > Consolidation: ON (OS/Networking) > Department or Group: Solaris I/O Framework > Bugtraq Category/SubCategory: kernel/io-multipath > | Responsible Manager: Peter Luk > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris > Consolidation: NWS (Network Storage) > Department or Group: SAN Engineering, Network Storage > Bugtraq Category/SubCategory: kernel/kernel_driver_fc_ulp_fcp > | Responsible Manager: Vince Eberhard > > 4. The INTERFACES are: > > FLAG_NOQUEUE Consolidation Private > DRIVER_DISABLE Consolidation Private > DRIVER_DISABLE_TRANSIENT Consolidation Private > mdi_pi_find Consolidation Private > mdi_pi_get_client Consolidation Private > mdi_pi_disable Consolidation Private > mdi_pi_enable Consolidation Private > mdi_pi_get_phci Consolidation Private > mdi_pi_alloc Consolidation Private > mdi_pi_set_phci_private Consolidation Private > mdi_pi_online Consolidation Private > mdi_pi_free Consolidation Private > mdi_pi_offline Consolidation Private > mdi_phci_register Consolidation Private > mdi_phci_unregister Consolidation Private > mdi_prop_free Consolidation Private > mdi_prop_remove Consolidation Private > mdi_prop_lookup_xxx Consolidation Private > mdi_prop_update_xxx Consolidation Private > mdi_pi_fault Consolidation Private > mdi_component_is_vhci Consolidation Private > mdi_component_is_phci Consolidation Private > mdi_component_is_client Consolidation Private > > | mdi_pi_enable_path Consolidation Private > | mdi_pi_disable_path Consolidation Private > > | The SUPPLIER and CONSUMER mutually agree to terminate the contract > | the following interfaces from Solaris 11 release and later. | mdi_pi_enable_path Consolidation Private > | mdi_pi_disable_path Consolidation Private > > 5. The ARC controlling these INTERFACES is: > PSARC > > 6. The CASE describing these INTERFACES is: > PSARC/1999/647 > PSARC 2002/362 > PSARC/2003/157 > | PSARC/2006/103 > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > imposed by the stability levels listed in section 4 above: > > _N_ 7a. Although the stability level doesn't normally restrict it, > SUPPLIER promises to only modify INTERFACES in an incompatible > way as follows: > > _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER will > expose INTERFACES to a PARTNER, which is external to Sun, namely: > Name of Company: > Name of Department or Group within Company: > Responsible Manager: > > _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER will > import INTERFACES from a separate consolidation. > > _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any > portion of the INTERFACES, SUPPLIER will notify CONSUMER of the > proposed new version, no later than the application for ARC > approval of the new version. > If SUPPLIER and CONSUMER are contained in the same consolidation, > they have the option of arranging for simultaneous conversion > to the new interfaces. If this is not possible, or if they are > not in the same consolidation, then SUPPLIER will either make best > effort to work with CONSUMER so that CONSUMER can detect which > version of INTERFACES is being supplied, or else SUPPLIER will > make best effort to supply both old and new versions of > INTERFACES. > If SUPPLIER cannot make both versions of INTERFACES available, > and SUPPLIER and CONSUMER cannot devise a method whereby > CONSUMER can detect which version of INTERFACES is being > supplied, and the old version of CONSUMER will not run with the > new version of SUPPLIER, then either the EOL process must be > followed by SUPPLIER, or else a major release of SUPPLIER will > be required, or the change will not be allowed. > > 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make > best effort to accommodate such changes, which shall then be > treated in accordance with paragraph 7 above. > > 9. Notwithstanding paragraphs 7 and 8, a change to any portion > of the INTERFACES shall be regarded as a completely new set of > INTERFACES which require both ARC approval and execution of > a new contract. > > 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be > handled as follows: > The interfaces will evolve in accordance with paragraph 7d above. > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > The SUPPLIER agrees to support the interfaces as specified in > the PSARC case. > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > The interfaces are documented as part of the PSARC > case materials. > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > Changes to the interface will be tested by the SUPPLIER > in addition to the exposure provided by ON. > > The CONSUMER will be responsible for testing the use of interfaces > as described in the PSARC case material which will introduce > changes to the interfaces. > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated as > follows: > When any interface listed in this contract is rendered obsolete > this contract may be terminated as to that interface, subject to > the conditions of paragraph 7d above. > > Otherwise, by mutual agreement. > > 15. This contract is not valid until "signed" via agreement from the > SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by > this contract. E-mail agreement to the contract should be archived > in the mail archive of CASE; verbal agreement to the contract > should be noted in the meeting minutes. This contract remains > valid until superseded or invalidated. > > | For SUPPLIER: Peter Luk Date: > | For CONSUMER: Vince Eberhard Date: > | For ARC: Paul von Behren Date: > > A copy of this contract shall be deposited in the CASE directory as > "contract-" or in a "contracts" subdirectory. > > 16. (Not to be filled in until superseded or invalidated.) > This contract was superseded or invalidated by CASE: > For ARC: Date: > > > > ------------------------------------------------------------------------ > > Subject: > mdi_pi_enable/disable_path [PSARC/2006/372 Timeout: 06/08/2006] > From: > Paul Von Behren > Date: > Thu, 01 Jun 2006 15:06:36 -0700 (PDT) > To: > PSARC@sac.sfbay.sun.com > > To: > PSARC@sac.sfbay.sun.com > CC: > Hyon.Kim@Sun.COM > > > Subject: PSARC FastTrack [06/08/2006]: mdi_pi_enable/disable_path > > > Template Version: @(#)sac_nextcase 1.56 10/26/05 SMI > This information is Copyright 2006 Sun Microsystems, Inc. > 1. Introduction > 1.1. Project/Component Working Name: > mdi_pi_enable/disable_path > 1.2. Name of Document Author/Supplier: > Author: Hyon Kim > 1.3 Date of This Document: > 01 June, 2006 > 4. Technical Description > > Name: Porting mdi_pi_enable/disable_path > > 1. Proposal Summary > > PSARC/2006/103 introduced new MDI interfaces to allow a vhci driver to > enable/disable a specific path while requesting to deprecate the existing MDI interfaces which lack the components necessary to select the full path to a > client device. It also stated that associated libg_fc APIs for enabling/disabling a path to a scsi_vhci device will be deprecated since > the original requester never used the interfaces. > > This fasttrack is to request micro/patch release binding for the MDI > new interfaces from PSARC/2006/103. Note that the interfaces that are > described to be deprecated in PSARC/2006/103 will be removed on next minor release. > > > 2 Interfaces > > > Exported Interfaces: > ---------------- > ______________________________________________________________________ > | Interface Name | Classification | Comments | > ______________________________________________________________________ > | | | | > | mdi_pi_disable_path | Cons. Private | Disable MPxIO Path | > | | | Introduced in | > | | | PSARC 2006/103 | > | | | | > | mdi_pi_enable_path | Cons. Private | Enable MPxIO Path | > | | | Introduced in | > | | | PSARC 2006/103 | > | | | | > ______________________________________________________________________ > > 3 Proposed contract: > http://sac.sfbay.sun.com/PSARC/2006/XXX/contract-01.txt > > (amends and supersedes PSARC/2003/322/contract-01; > changes indicated by left-margin change-bars in new version) > > Earlier contract: > http://sac.sfbay.sun.com/PSARC/2003/322/contract-01 > 4. Reference Documents: > > 1. PSARC 1999/647 Multiplexed I/O Framework > > 2. PSARC 2002/362 MPxIO/scsi_vhci path enable/disable > > 3. PSARC 2004/626 SNIA Multipath Management API > > 4. http://sac.sfbay.sun.com/PSARC/1999/647/related_cases.html > > 5. PSARC 2003/322 Move SAN drivers from ON to NWS > 6. PSARC 2006/103 MDI enable/disable of a path > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack