Hi,
The contract file is attached for you to review, and also located in
the case directory as contract-01.
Markus, please reply-all 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
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_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_unicast_add Consolidation Private
mac_unicast_remove 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
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]
