I approve. Achim On Apr 6, 2010, at 19:56 , Markus Flierl - Oracle US wrote:
> I approve. > Markus > > On 04/06/10 10:48, Krishna Yenduri wrote: >> >> Hi, >> >> I have updated the contract file to add the routines >> that Ram found were missing. >> The contract file is attached for you to review, and also located in >> the case directory as contract-01. >> >> Markus, please reply-all again to this email to indicate that you approve >> of this contract as supplier. Achim, please reply-all to this email >> to indicate that you approve of this contract as consumer. >> >> -Krishna > > > > > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: PSARC 2010/112-01 > > 1. This contract is between > a SUPPLIER of INTERFACES and > a CONSUMER of those INTERFACES, > both of whom are entities within Oracle and/or its affiliates. > > 2. The SUPPLIER (definer and/or implementor) is identified by the following: > Product or Bundle: Solaris > Consolidation: ON > Department or Group: Solaris Networking > Bugster Product/Category/SubCategory: solaris/kernel/gld > Responsible Manager: Markus Flierl > > 3. The CONSUMER is identified by the following: > Product or Bundle: VirtualBox > Consolidation: N/A > Department or Group: VirtualBox Software > Bugster Product/Category/SubCategory: virtualbox/virtualbox/other > Responsible Manager: Achim Hasenmueller > > 4. The INTERFACES are: > > Header files: > <sys/mac.h> Consolidation Private > <sys/mac_client.h> Consolidation Private > <sys/vnic_mgmt.h> Consolidation Private > <sys/dls.h> Consolidation Private > > Macros: > MAC_VLAN Consolidation Private > MAC_CLIENT_PRI_LOW Consolidation Private > MAC_CLIENT_PRI_MEDIUM Consolidation Private > MAC_CLIENT_PRI_HIGH Consolidation Private > > Datatypes: > vnic_ioc_diag_t Consolidation Private > vnic_mac_addr_type_t Consolidation Private > mac_handle_t Consolidation Private > mac_rx_t Consolidation Private > mac_tx_cookie_t Consolidation Private > mac_client_handle_t Consolidation Private > mac_unicast_handle_t Consolidation Private > mac_promisc_handle_t Consolidation Private > > Functions: > vnic_create Consolidation Private > vnic_modify_addr Consolidation Private > vnic_delete Consolidation Private > mac_open_by_linkname Consolidation Private > mac_open_by_linkid Consolidation Private > mac_open Consolidation Private > mac_close Consolidation Private > mac_client_open Consolidation Private > mac_client_close Consolidation Private > mac_rx_set Consolidation Private > mac_rx_clear Consolidation Private > mac_tx Consolidation Private > mac_unicast_add Consolidation Private > mac_unicast_remove Consolidation Private > mac_unicast_primary_get Consolidation Private > mac_promisc_add Consolidation Private > mac_promisc_remove Consolidation Private > mac_multicast_add Consolidation Private > mac_multicast_remove Consolidation Private > mac_client_stat_get Consolidation Private > mac_is_vnic Consolidation Private > mac_client_set_maxbw Consolidation Private > mac_client_get_maxbw Consolidation Private > mac_client_reset_maxbw Consolidation Private > mac_client_set_priority Consolidation Private > mac_client_get_priority Consolidation Private > mac_client_reset_priority Consolidation Private > dls_mgmt_get_linkid Consolidation Private > > > 5. The ARC controlling these INTERFACES is: PSARC > > 6. The CASE describing (Exporting) these INTERFACES is: > PSARC/2006/357 Crossbow - Network Virtualization and Resource Management > PSARC/2010/112 MAC client API and VNIC API updates > > 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: > > SUPPLIER will notify CONSUMER of any proposed changes to the > interface. > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > > CONSUMER shall file bugster change requests against the interfaces > under solaris/kernel/gld. SUPPLIER agrees to respond to these > change requests according to the usual sustaining process. > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > > The interfaces will be documented by the source code and > header files in the ON consolidation. > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > > SUPPLIER agrees to test any changes to the interface as part of > existing or updated test suites. Test suites will be enhanced > specifically to validate these interfaces. > > CONSUMER agrees to test their use of these interfaces at the usual > release intervals and when any changes are made to the implementation > of the contracted interface. > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated as > follows: > > Contract will be terminated by mutual agreement between the > SUPPLIER and CONSUMER. > > 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: Date: > For CONSUMER: Date: > For ARC: Date: > > A copy of this contract shall be deposited in the CASE directory as > "contract-<digits>" 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: > _______________________________________________ opensolaris-arc mailing list [email protected]
