From krishna@sac.sfbay.sun.com Fri Apr 2 14:58:20 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o32LwKNo014744 for ; Fri, 2 Apr 2010 14:58:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o32LwKuA000580; Fri, 2 Apr 2010 14:58:20 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0900H03RP8TQ00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 02 Apr 2010 14:58:20 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0900F8ARP8G610@nwk-avmta-1.sfbay.Sun.COM>; Fri, 02 Apr 2010 14:58:20 -0700 (PDT) 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.4) with ESMTP id o32LwIW9000992; Fri, 02 Apr 2010 14:58:18 -0700 (PDT) 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 o32LwHae014739; Fri, 02 Apr 2010 14:58:17 -0700 (PDT) Received: (from krishna@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o32LwHhu014735; Fri, 02 Apr 2010 14:58:17 -0700 (PDT) Date: Fri, 02 Apr 2010 14:58:17 -0700 (PDT) From: Krishna Yenduri Subject: MAC client API and VNIC API updates [PSARC/2010/112 Self Review] To: PSARC-ext@sun.com Cc: nicolas.droux@sun.com, ramshankar.venkataraman@sun.com Message-id: <201004022158.o32LwHhu014735@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2241 I am self-sponsoring the following case and marking it as "closed approved automatic". It only adds consolidation private interfaces and they have been reviewed by the Crossbow team. The motivation for documenting these interfaces is because VirtualBox will be using them along with other MAC client API. I will send the contract to be signed once it is ready. The Release Binding is Minor. Thanks, -Krishna Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: MAC client API and VNIC API updates 1.2. Name of Document Author/Supplier: Author: Krishna Yenduri 1.3 Date of This Document: 02 April, 2010 4. Technical Description The VirtualBox team would like to use the MAC client API in Solaris from a kernel module. They also need new kernel-level API for creating, modifying and deleting VNICs and setting link properties. The following interfaces are being added for that purpose: Consolidation Private MAC_VLAN Consolidation Private vnic_ioc_diag_t Consolidation Private vnic_mac_addr_type_t Consolidation Private vnic_create Consolidation Private vnic_modify_addr Consolidation Private vnic_delete Consolidation Private Consolidation Private MAC_CLIENT_PRI_LOW Consolidation Private MAC_CLIENT_PRI_MEDIUM Consolidation Private MAC_CLIENT_PRI_HIGH 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 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 From bhargava.yenduri@oracle.com Mon Apr 5 11:53:35 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o35IrZ9s023903 for ; Mon, 5 Apr 2010 11:53:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o35IrYSx028644 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 5 Apr 2010 13:53:35 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0F00M0535AC300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 05 Apr 2010 11:53:34 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0F00ET635AN080@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 05 Apr 2010 11:53:34 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o35IrX23000247 for ; Mon, 05 Apr 2010 18:53:33 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o35IrV3M031828 for ; Mon, 05 Apr 2010 18:53:32 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt353.oracle.com with ESMTP id 137858701270493608; Mon, 05 Apr 2010 11:53:28 -0700 Received: from [129.146.108.66] (/129.146.108.66) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Apr 2010 11:53:28 -0700 Date: Mon, 05 Apr 2010 11:47:31 -0700 From: Krishna Yenduri Subject: PSARC/2010/112 - MAC client API and VNIC API updates In-reply-to: <201004022158.o32LwHhu014735@sac.sfbay.sun.com> To: PSARC-ext@sun.com Message-id: <4BBA3043.2070101@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BBA31AD.00B1:SCFMA4539814,ss=1,fgs=0 References: <201004022158.o32LwHhu014735@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 180 It was pointed out to me that this needs to be a fast track since there is a contract. So, I am making this a fast track case with the timer set to 4/9/2010. Thanks, -Krishna From bhargava.yenduri@sun.com Mon Apr 5 11:55:48 2010 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 o35ItmmP024152 for ; Mon, 5 Apr 2010 11:55:48 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o35ItfdU020945; Mon, 5 Apr 2010 11:55:46 -0700 (PDT) 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 <0L0F0091J38Y7H00@brm-avmta-1.central.sun.com>; Mon, 05 Apr 2010 12:55:46 -0600 (MDT) Received: from jurassic.Eng.Sun.COM ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0F001OB38XGY90@brm-avmta-1.central.sun.com>; Mon, 05 Apr 2010 12:55:45 -0600 (MDT) Received: from [129.146.108.66] (bluesky.SFBay.Sun.COM [129.146.108.66]) by jurassic.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o35Iti0T371729; Mon, 05 Apr 2010 11:55:45 -0700 (PDT) Date: Mon, 05 Apr 2010 11:49:49 -0700 From: Krishna Yenduri Subject: PSARC/2010/112 Contract for VirtualBox to use ON Crossbow interfaces To: markus.flierl@oracle.com, achim.hasenmueller@sun.com Cc: psarc-ext@sun.com Message-id: <4BBA30CD.3090709@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_iYsuO2iJ6nI3pA534osyQg)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 7605 This is a multi-part message in MIME format. --Boundary_(ID_iYsuO2iJ6nI3pA534osyQg) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT 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 --Boundary_(ID_iYsuO2iJ6nI3pA534osyQg) Content-type: text/plain; name=contract-01 Content-transfer-encoding: 7BIT Content-disposition: inline; filename=contract-01 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: Consolidation Private Consolidation Private 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-" 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: --Boundary_(ID_iYsuO2iJ6nI3pA534osyQg)-- From markus.flierl@oracle.com Mon Apr 5 12:59:52 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o35JxqbO025549 for ; Mon, 5 Apr 2010 12:59:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o35JxoVV001450 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Mon, 5 Apr 2010 12:59:52 -0700 (PDT) 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 <0L0F00F1367RUW00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 05 Apr 2010 13:59:51 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0F00EEX67QMT20@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 05 Apr 2010 13:59:51 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o35Jxoi6022437 for ; Mon, 05 Apr 2010 12:59:50 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L0F000005YYVG00@fe-sfbay-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 05 Apr 2010 12:59:50 -0700 (PDT) Received: from [129.145.154.90] ([unknown] [129.145.154.90]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L0F0071Z67PP870@fe-sfbay-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 05 Apr 2010 12:59:50 -0700 (PDT) Date: Mon, 05 Apr 2010 12:59:49 -0700 From: Markus Flierl - Oracle US Subject: Re: PSARC/2010/112 Contract for VirtualBox to use ON Crossbow interfaces In-reply-to: <4BBA30CD.3090709@sun.com> Sender: Markus.Flierl@sun.com To: Krishna Yenduri Cc: Achim.Hasenmueller@sun.com, psarc-ext@sun.com Message-id: <4BBA4135.7080807@oracle.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4BBA30CD.3090709@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090910) Status: RO Content-Length: 395 I approve. Markus On 04/05/10 11:49, Krishna Yenduri wrote: > 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 From ramshankar@sun.com Tue Apr 6 02:07:23 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3697MLW024936 for ; Tue, 6 Apr 2010 02:07:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3697JrZ028824 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 6 Apr 2010 04:07:22 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0G00I096O9XL00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 06 Apr 2010 02:07:21 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0G008B16O7KF60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 06 Apr 2010 02:07:20 -0700 (PDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3697HpT018022 for ; Tue, 06 Apr 2010 09:07:18 +0000 (GMT) Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L0G00B006LF4S00@fe-emea-13.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 06 Apr 2010 10:07:02 +0100 (BST) Received: from [10.16.204.30] ([unknown] [10.16.204.30]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L0G00AOD6NPUEC0@fe-emea-13.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 06 Apr 2010 10:07:01 +0100 (BST) Date: Tue, 06 Apr 2010 11:07:01 +0200 From: Ramshankar Subject: Re: PSARC/2010/112 Contract for VirtualBox to use ON Crossbow interfaces In-reply-to: <4BBA30CD.3090709@sun.com> Sender: Ramshankar.Venkataraman@sun.com To: Krishna Yenduri Cc: markus.flierl@oracle.com, Achim.Hasenmueller@sun.com, PSARC-ext@sun.com Reply-to: ramshankar@sun.com Message-id: <1270544821.18313.1988.camel@u40m2> Organization: Sun Microsystems GmbH MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4BBA30CD.3090709@sun.com> Status: RO Content-Length: 8775 Hi Krishna, Thank you for formulating the contract. I had a look at it and compared it with my existing code to see if anything was missed. * mac_tx: mac_tx function (and mac_tx_cookie_t datatype) seems to be missing here. * dls_mgmt_get_linkid: vnic_modify_addr() takes a datalink_id_t, this assumes we've created the VNIC. But our implementation should also work for existing VNICs that a user can provide to VBox. In which case we'd do a mac_open_by_linkname() and mac_client_open() which would give us the mac_handle_t and mac_client_handle_t but not the datalink_id_t. I use dls_mgmt_get_linkid() to get a datalink_id_t so we can modify the MAC address of the user-created VNIC. * mac_unicast_primary_get: I currently use mac_unicast_primary_get() function to obtain the currently set MAC address for the VNIC. It would be good if this function were exported too. Since you've provided separate resource setter/getter functions I guess we would not ever need a mac_resource_handle_t type, so that's fine. Could you clarify the above points? Regards, Ram. On Mon, 2010-04-05 at 11:49 -0700, Krishna Yenduri wrote: > 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 > > plain text document attachment (contract-01) > 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: > Consolidation Private > Consolidation Private > 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-" 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: > From bhargava.yenduri@oracle.com Tue Apr 6 10:43:04 2010 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 o36Hh4iA002615 for ; Tue, 6 Apr 2010 10:43:04 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o36Hh1Wx013428; Tue, 6 Apr 2010 10:43:01 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0G00C3RUJP7500@nwk-avmta-1.sfbay.Sun.COM>; Tue, 06 Apr 2010 10:43:01 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0G0093SUJH69F0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 06 Apr 2010 10:42:53 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o36HgrA3022333; Tue, 06 Apr 2010 17:42:53 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o36EVKvb022094; Tue, 06 Apr 2010 17:42:49 +0000 (GMT) Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 140602921270575683; Tue, 06 Apr 2010 10:41:23 -0700 Received: from [129.146.108.66] (/129.146.108.66) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Apr 2010 10:41:22 -0700 Date: Tue, 06 Apr 2010 10:35:18 -0700 From: Krishna Yenduri Subject: Re: PSARC/2010/112 Contract for VirtualBox to use ON Crossbow interfaces In-reply-to: <1270544821.18313.1988.camel@u40m2> To: ramshankar@sun.com Cc: Krishna Yenduri , markus.flierl@oracle.com, Achim.Hasenmueller@sun.com, PSARC-ext@sun.com Message-id: <4BBB70D6.5020708@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BBB729C.00E9:SCFMA4539814,ss=1,fgs=0 References: <4BBA30CD.3090709@sun.com> <1270544821.18313.1988.camel@u40m2> User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 1192 On 04/ 6/10 02:07 AM, Ramshankar wrote: > ... > > * mac_tx: > mac_tx function (and mac_tx_cookie_t datatype) seems to be missing here. > > * dls_mgmt_get_linkid: > vnic_modify_addr() takes a datalink_id_t, this assumes we've created the > VNIC. But our implementation should also work for existing VNICs that a > user can provide to VBox. In which case we'd do a mac_open_by_linkname() > and mac_client_open() which would give us the mac_handle_t and > mac_client_handle_t but not the datalink_id_t. I use > dls_mgmt_get_linkid() to get a datalink_id_t so we can modify the MAC > address of the user-created VNIC. > > * mac_unicast_primary_get: > I currently use mac_unicast_primary_get() function to obtain the > currently set MAC address for the VNIC. It would be good if this > function were exported too. > Thanks. We missed these by oversight in our earlier draft. I am updating the contract with these routines. I will send out another email for the approval of the updated contract. > Since you've provided separate resource setter/getter functions I guess > we would not ever need a mac_resource_handle_t type, so that's fine. > Yes. That was the intent. -Krishna From bhargava.yenduri@oracle.com Tue Apr 6 10:55:41 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o36HtfLL003049 for ; Tue, 6 Apr 2010 10:55:41 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o36HtWsK010810; Tue, 6 Apr 2010 10:55:38 -0700 (PDT) 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 <0L0G00G29V4PAP00@brm-avmta-1.central.sun.com>; Tue, 06 Apr 2010 11:55:37 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0G00FW9V4O8U00@brm-avmta-1.central.sun.com>; Tue, 06 Apr 2010 11:55:36 -0600 (MDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o36HtZKC017518; Tue, 06 Apr 2010 17:55:35 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o35JVUTs018648; Tue, 06 Apr 2010 17:55:34 +0000 (GMT) Received: from abhmt012.oracle.com by acsmt355.oracle.com with ESMTP id 140627131270576468; Tue, 06 Apr 2010 10:54:28 -0700 Received: from [129.146.108.66] (/129.146.108.66) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Apr 2010 10:54:28 -0700 Date: Tue, 06 Apr 2010 10:48:30 -0700 From: Krishna Yenduri Subject: PSARC/2010/112 Contract for VirtualBox to use ON Crossbow interfaces To: markus.flierl@oracle.com, achim.hasenmueller@sun.com Cc: psarc-ext@sun.com, ramshankar.venkataraman@sun.com Message-id: <4BBB73EE.8080101@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Df9WIxvJpZtNXnYas0UUPA)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BBB7596.0157:SCFMA4539814,ss=1,fgs=0 User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 7895 This is a multi-part message in MIME format. --Boundary_(ID_Df9WIxvJpZtNXnYas0UUPA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT 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 --Boundary_(ID_Df9WIxvJpZtNXnYas0UUPA) Content-type: text/plain; name=contract-01 Content-transfer-encoding: 7BIT Content-disposition: inline; filename=contract-01 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: Consolidation Private Consolidation Private Consolidation Private 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-" 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: --Boundary_(ID_Df9WIxvJpZtNXnYas0UUPA)-- From markus.flierl@oracle.com Tue Apr 6 10:56:06 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o36Hu6ue003155 for ; Tue, 6 Apr 2010 10:56:06 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o36Hu3eY022634 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 6 Apr 2010 12:56:06 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0G00F21V5HOJ00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 06 Apr 2010 10:56:05 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0G00ERIV5G4U00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 06 Apr 2010 10:56:04 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o36Hu4ZS021233 for ; Tue, 06 Apr 2010 10:56:04 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L0G00100V0WLB00@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 06 Apr 2010 10:56:04 -0700 (PDT) Received: from [129.145.154.90] ([unknown] [129.145.154.90]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L0G008QIV5F2P70@fe-sfbay-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 06 Apr 2010 10:56:04 -0700 (PDT) Date: Tue, 06 Apr 2010 10:56:03 -0700 From: Markus Flierl - Oracle US Subject: Re: PSARC/2010/112 Contract for VirtualBox to use ON Crossbow interfaces In-reply-to: <4BBB73EE.8080101@oracle.com> Sender: Markus.Flierl@sun.com To: Krishna Yenduri Cc: Achim.Hasenmueller@sun.com, psarc-ext@sun.com, Ramshankar.Venkataraman@sun.com Message-id: <4BBB75B3.5060700@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_xKfMfYk0TlnyrpL5cIoRqw)" X-PMX-Version: 5.4.1.325704 References: <4BBB73EE.8080101@oracle.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090910) Status: RO Content-Length: 9346 This is a multi-part message in MIME format. --Boundary_(ID_xKfMfYk0TlnyrpL5cIoRqw) Content-type: multipart/alternative; boundary="Boundary_(ID_6+Oc6ThcWr3SeyU9P+M6Lw)" --Boundary_(ID_6+Oc6ThcWr3SeyU9P+M6Lw) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT 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 / / --Boundary_(ID_6+Oc6ThcWr3SeyU9P+M6Lw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT 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



--Boundary_(ID_6+Oc6ThcWr3SeyU9P+M6Lw)-- --Boundary_(ID_xKfMfYk0TlnyrpL5cIoRqw) Content-type: text/plain; name=contract-01 Content-transfer-encoding: 7BIT Content-disposition: inline; filename=contract-01 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: Consolidation Private Consolidation Private Consolidation Private 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-" 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: --Boundary_(ID_xKfMfYk0TlnyrpL5cIoRqw)-- From achim@sun.com Tue Apr 6 10:58:44 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o36Hwigp003270 for ; Tue, 6 Apr 2010 10:58:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o36HwhDb012476 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 6 Apr 2010 10:58:44 -0700 (PDT) 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 <0L0G00G03V9VOK00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 06 Apr 2010 11:58:43 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0G00FR9V9U8V00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 06 Apr 2010 11:58:43 -0600 (MDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o36Hwg3A010705 for ; Tue, 06 Apr 2010 17:58:42 +0000 (GMT) Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L0G00G00V1L1F00@fe-emea-13.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 06 Apr 2010 18:58:17 +0100 (BST) Received: from [192.168.11.215] (p5DE7868A.dip.t-dialin.net [93.231.134.138]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L0G00B17V93UJC0@fe-emea-13.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 06 Apr 2010 18:58:17 +0100 (BST) Date: Tue, 06 Apr 2010 19:58:15 +0200 From: Achim Hasenmueller Subject: Re: PSARC/2010/112 Contract for VirtualBox to use ON Crossbow interfaces In-reply-to: <4BBB75B3.5060700@oracle.com> Sender: Achim.Hasenmueller@sun.com To: Markus Flierl - Oracle US Cc: Krishna Yenduri , psarc-ext@sun.com, Ramshankar.Venkataraman@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.1078) Content-type: multipart/alternative; boundary="Boundary_(ID_u/qZ7ieCzVTz6aveGFLkdw)" X-PMX-Version: 5.4.1.325704 References: <4BBB73EE.8080101@oracle.com> <4BBB75B3.5060700@oracle.com> Status: RO Content-Length: 32722 --Boundary_(ID_u/qZ7ieCzVTz6aveGFLkdw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT 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: > Consolidation Private > Consolidation Private > Consolidation Private > 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-" 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: > --Boundary_(ID_u/qZ7ieCzVTz6aveGFLkdw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable 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:


= --Boundary_(ID_u/qZ7ieCzVTz6aveGFLkdw)-- From ramshankar@sun.com Tue Apr 6 11:30:27 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o36IURVE004385 for ; Tue, 6 Apr 2010 11:30:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o36IUOeH039874; Tue, 6 Apr 2010 12:30:26 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0G00K09WQPDE00@nwk-avmta-2.sfbay.sun.com>; Tue, 06 Apr 2010 11:30:25 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0G00B1OWQOK6B0@nwk-avmta-2.sfbay.sun.com>; Tue, 06 Apr 2010 11:30:25 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o36IUNT4025849; Tue, 06 Apr 2010 18:30:23 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L0G00300WEINT00@fe-emea-09.sun.com>; Tue, 06 Apr 2010 19:30:14 +0100 (BST) Received: from [10.16.204.30] ([unknown] [10.16.204.30]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L0G00GD8WQET750@fe-emea-09.sun.com>; Tue, 06 Apr 2010 19:30:14 +0100 (BST) Date: Tue, 06 Apr 2010 20:30:13 +0200 From: Ramshankar Subject: Re: PSARC/2010/112 Contract for VirtualBox to use ON Crossbow interfaces In-reply-to: Sender: Ramshankar.Venkataraman@sun.com To: Achim Hasenmueller Cc: Markus Flierl - Oracle US , Krishna Yenduri , psarc-ext@sun.com, Ramshankar.Venkataraman@sun.com Reply-to: ramshankar@sun.com Message-id: <1270578613.18313.1995.camel@u40m2> Organization: Sun Microsystems GmbH MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4BBB73EE.8080101@oracle.com> <4BBB75B3.5060700@oracle.com> Status: RO Content-Length: 8504 Looks fine to me too. Regards, Ram. On Tue, 2010-04-06 at 19:58 +0200, Achim Hasenmueller wrote: > 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: > > Consolidation Private > > Consolidation Private > > Consolidation Private > > 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-" 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: > > > > From sebastien.roy@oracle.com Wed Apr 7 08:38:20 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o37FcKiO011094 for ; Wed, 7 Apr 2010 08:38:20 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o37FcGGN064192; Wed, 7 Apr 2010 09:38:16 -0600 (MDT) 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 <0L0I00D11JFSEP00@brm-avmta-1.central.sun.com>; Wed, 07 Apr 2010 09:38:16 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0I00664JFROF50@brm-avmta-1.central.sun.com>; Wed, 07 Apr 2010 09:38:15 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o37FcELn017066; Wed, 07 Apr 2010 15:38:14 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o36MGvSD011275; Wed, 07 Apr 2010 15:38:13 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt353.oracle.com with ESMTP id 143274861270654595; Wed, 07 Apr 2010 08:36:35 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Apr 2010 08:36:34 -0700 Date: Wed, 07 Apr 2010 11:36:33 -0400 From: Sebastien Roy Subject: Re: PSARC/2010/112 - MAC client API and VNIC API updates In-reply-to: <4BBA3043.2070101@oracle.com> To: Krishna Yenduri Cc: PSARC-ext@sun.com, achim.hasenmueller@sun.com, ramshankar.venkataraman@sun.com, Markus Flierl Message-id: <4BBCA681.6060900@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BBCA6E6.0021:SCFMA4539814,ss=1,fgs=0 References: <201004022158.o32LwHhu014735@sac.sfbay.sun.com> <4BBA3043.2070101@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 1601 On 04/ 5/10 02:47 PM, Krishna Yenduri wrote: > It was pointed out to me that this needs to be a fast track since > there is a contract. So, I am making this a fast track case > with the timer set to 4/9/2010. ... > Header files: > Consolidation Private > Consolidation Private > Consolidation Private > Consolidation Private The latter three header files are not currently included in any package. I assume that this case delivers these header files as part of some package, presumably pkg:/system/header.(?) I am generally concerned about the viability of long term use of these contracted interfaces by another consolidation given that the interfaces are not centralized in any part of the ON source (there's no easy way to place a big warning in the code concerning their consumption by another consolidation), and that these interfaces have recently undergone numerous and drastic changes. Assuming that interfaces remain volatile, this could lead to either unintentional breakage of VirtualBox, or complex version dependencies between VirtualBox and the underlying host OS. This is less of a concern if the interfaces contracted have sedimented somewhat and are more stable than they have been in the recent past. This could be mitigated in a number of ways in the longer term. Committing to a Public MAC client API and VNIC API would be one solution. Another might be to integrate the Solaris kernel specific portion of VirtualBox into ON. Has either project team considered such options? -Seb From bhargava.yenduri@oracle.com Wed Apr 7 09:21:29 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o37GLTHx013127 for ; Wed, 7 Apr 2010 09:21:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o37GLQxE036068; Wed, 7 Apr 2010 10:21:26 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0I00B03LFQOP00@nwk-avmta-2.sfbay.sun.com>; Wed, 07 Apr 2010 09:21:26 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0I00643LFP9Y60@nwk-avmta-2.sfbay.sun.com>; Wed, 07 Apr 2010 09:21:26 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o37GLP6x025494; Wed, 07 Apr 2010 16:21:25 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o37GLNOO009498; Wed, 07 Apr 2010 16:21:23 +0000 (GMT) Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 143418651270657256; Wed, 07 Apr 2010 09:20:56 -0700 Received: from [129.150.13.56] (/129.150.13.56) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Apr 2010 09:20:55 -0700 Date: Wed, 07 Apr 2010 09:20:46 -0700 From: Krishna Yenduri Subject: Re: PSARC/2010/112 - MAC client API and VNIC API updates In-reply-to: <4BBCA681.6060900@oracle.com> To: Sebastien Roy Cc: PSARC-ext@sun.com, achim.hasenmueller@sun.com, ramshankar.venkataraman@sun.com, Markus Flierl , Nicolas Droux Message-id: <4BBCB0DE.7020800@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0209.4BBCB105.00B7:SCFMA4539814,ss=1,fgs=0 References: <201004022158.o32LwHhu014735@sac.sfbay.sun.com> <4BBA3043.2070101@oracle.com> <4BBCA681.6060900@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20091207 Lightning/1.0pre Thunderbird/3.0 Status: RO Content-Length: 2202 On 04/ 7/10 08:36 AM, Sebastien Roy wrote: > On 04/ 5/10 02:47 PM, Krishna Yenduri wrote: >> It was pointed out to me that this needs to be a fast track since >> there is a contract. So, I am making this a fast track case >> with the timer set to 4/9/2010. > ... >> Header files: >> Consolidation Private >> Consolidation Private >> Consolidation Private >> Consolidation Private > > The latter three header files are not currently included in any > package. I assume that this case delivers these header files as part > of some package, presumably pkg:/system/header.(?) Yes. They are delivered in pkg/manifests/system-header.mf. > I am generally concerned about the viability of long term use of these > contracted interfaces by another consolidation given that the > interfaces are not centralized in any part of the ON source (there's > no easy way to place a big warning in the code concerning their > consumption by another consolidation), and that these interfaces have > recently undergone numerous and drastic changes. Assuming that > interfaces remain volatile, this could lead to either unintentional > breakage of VirtualBox, or complex version dependencies between > VirtualBox and the underlying host OS. This is less of a concern if > the interfaces contracted have sedimented somewhat and are more stable > than they have been in the recent past. Agreed on the concern. It is for this reason that only a small subset of the interfaces in these header files are part of the contract. Also, we added new interfaces like mac_client_set_maxbw etc. to avoid exposing less stable (project private) interfaces. > This could be mitigated in a number of ways in the longer term. > Committing to a Public MAC client API and VNIC API would be one > solution. Another might be to integrate the Solaris kernel specific > portion of VirtualBox into ON. Has either project team considered > such options? The longer term solution is a public MAC client API. But, we would like to get more experience with clients before making them public. Thanks, -Krishna From sebastien.roy@oracle.com Wed Apr 7 10:25:55 2010 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 o37HPs9J016692 for ; Wed, 7 Apr 2010 10:25:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o37HPpKu010224; Wed, 7 Apr 2010 10:25:52 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0I00F2FOF3QV00@nwk-avmta-2.sfbay.sun.com>; Wed, 07 Apr 2010 10:25:51 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0I003EVOF2GKF0@nwk-avmta-2.sfbay.sun.com>; Wed, 07 Apr 2010 10:25:51 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o37HPoDt023826; Wed, 07 Apr 2010 17:25:50 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o37D64MC022426; Wed, 07 Apr 2010 17:25:49 +0000 (GMT) Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 154867171270661132; Wed, 07 Apr 2010 10:25:32 -0700 Received: from [129.148.174.103] (/129.148.174.103) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Apr 2010 10:25:31 -0700 Date: Wed, 07 Apr 2010 13:25:30 -0400 From: Sebastien Roy Subject: Re: PSARC/2010/112 - MAC client API and VNIC API updates In-reply-to: <4BBCB0DE.7020800@oracle.com> To: Krishna Yenduri Cc: PSARC-ext@sun.com, achim.hasenmueller@sun.com, ramshankar.venkataraman@sun.com, Markus Flierl , Nicolas Droux Message-id: <4BBCC00A.3070204@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BBCC01E.0019:SCFMA4539814,ss=1,fgs=0 References: <201004022158.o32LwHhu014735@sac.sfbay.sun.com> <4BBA3043.2070101@oracle.com> <4BBCA681.6060900@oracle.com> <4BBCB0DE.7020800@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 2242 On 04/ 7/10 12:20 PM, Krishna Yenduri wrote: > On 04/ 7/10 08:36 AM, Sebastien Roy wrote: >> On 04/ 5/10 02:47 PM, Krishna Yenduri wrote: >>> It was pointed out to me that this needs to be a fast track since >>> there is a contract. So, I am making this a fast track case >>> with the timer set to 4/9/2010. >> ... >>> Header files: >>> Consolidation Private >>> Consolidation Private >>> Consolidation Private >>> Consolidation Private >> >> The latter three header files are not currently included in any >> package. I assume that this case delivers these header files as part >> of some package, presumably pkg:/system/header.(?) > > Yes. They are delivered in pkg/manifests/system-header.mf. Okay. > >> I am generally concerned about the viability of long term use of these >> contracted interfaces by another consolidation given that the >> interfaces are not centralized in any part of the ON source (there's >> no easy way to place a big warning in the code concerning their >> consumption by another consolidation), and that these interfaces have >> recently undergone numerous and drastic changes. Assuming that >> interfaces remain volatile, this could lead to either unintentional >> breakage of VirtualBox, or complex version dependencies between >> VirtualBox and the underlying host OS. This is less of a concern if >> the interfaces contracted have sedimented somewhat and are more stable >> than they have been in the recent past. > > Agreed on the concern. > It is for this reason that only a small subset of the interfaces in these > header files are part of the contract. Also, we added new interfaces > like mac_client_set_maxbw etc. to avoid exposing less stable (project > private) interfaces. > >> This could be mitigated in a number of ways in the longer term. >> Committing to a Public MAC client API and VNIC API would be one >> solution. Another might be to integrate the Solaris kernel specific >> portion of VirtualBox into ON. Has either project team considered such >> options? > > The longer term solution is a public MAC client API. But, we would like > to get more experience with clients before making them public. Okay, +1 on the case. -Seb From achim@sun.com Wed Apr 7 10:40:48 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o37Hem87017044 for ; Wed, 7 Apr 2010 10:40:48 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o37HelwE036380 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 7 Apr 2010 11:40:47 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0I00G0FP3ZM300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Apr 2010 10:40:47 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0I006GYP3Y9YC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Apr 2010 10:40:47 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o37Hekdg022145 for ; Wed, 07 Apr 2010 17:40:46 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L0I00C00OXP6U00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Apr 2010 18:40:33 +0100 (BST) Received: from [192.168.11.215] (p5DE7866E.dip.t-dialin.net [93.231.134.110]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L0I00GGRP3JOHE0@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Apr 2010 18:40:33 +0100 (BST) Date: Wed, 07 Apr 2010 19:40:35 +0200 From: Achim Hasenmueller Subject: Re: PSARC/2010/112 - MAC client API and VNIC API updates In-reply-to: <4BBCA681.6060900@oracle.com> Sender: Achim.Hasenmueller@sun.com To: Sebastien Roy Cc: Krishna Yenduri , PSARC-ext@sun.com, Ramshankar.Venkataraman@sun.com, Markus Flierl Message-id: <786877BA-668C-4D32-90DE-FFA8F1EAD55D@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.1078) Content-type: multipart/alternative; boundary="Boundary_(ID_qfxeEtLPKhvfQK0/LKBkIQ)" X-PMX-Version: 5.4.1.325704 References: <201004022158.o32LwHhu014735@sac.sfbay.sun.com> <4BBA3043.2070101@oracle.com> <4BBCA681.6060900@oracle.com> Status: RO Content-Length: 10063 --Boundary_(ID_qfxeEtLPKhvfQK0/LKBkIQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE Sebastien, VirtualBox is available for about 25 flavors of Linux and all kind of= interfaces get broken in every possible way, in average we have one = interface breakage a week. So we are not concerned at all. If you wan= t to change the Crossbow APIs we use, just do it and if possible, let= us know in advance. -- Achim Hasenmueller Director Engineering, VirtualBox Sun Microsystems GmbH Werkstrasse 24 71384 Weinstadt, Germany phone: +49 7151 604050 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten=20 Amtsgericht Muenchen: HRB 161028 On Apr 7, 2010, at 17:36 , Sebastien Roy wrote: > On 04/ 5/10 02:47 PM, Krishna Yenduri wrote: >> It was pointed out to me that this needs to be a fast track since >> there is a contract. So, I am making this a fast track case >> with the timer set to 4/9/2010. > ... >> Header files: >> =09=09=09=09Consolidation Private >> =09=09=09Consolidation Private >> =09=09=09Consolidation Private >> =09=09=09=09Consolidation Private >=20 > The latter three header files are not currently included in any pac= kage. I assume that this case delivers these header files as part of= some package, presumably pkg:/system/header.(?) >=20 > I am generally concerned about the viability of long term use of th= ese contracted interfaces by another consolidation given that the int= erfaces are not centralized in any part of the ON source (there's no = easy way to place a big warning in the code concerning their consumpt= ion by another consolidation), and that these interfaces have recentl= y undergone numerous and drastic changes. Assuming that interfaces r= emain volatile, this could lead to either unintentional breakage of V= irtualBox, or complex version dependencies between VirtualBox and the= underlying host OS. This is less of a concern if the interfaces con= tracted have sedimented somewhat and are more stable than they have b= een in the recent past. >=20 > This could be mitigated in a number of ways in the longer term. Com= mitting to a Public MAC client API and VNIC API would be one solution= . Another might be to integrate the Solaris kernel specific portion = of VirtualBox into ON. Has either project team considered such optio= ns? >=20 > -Seb Geschaeftsfuehrer: J=FCrgen Kunz =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D --Boundary_(ID_qfxeEtLPKhvfQK0/LKBkIQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE Sebastien,
VirtualBox is available for about 25 flavors of Linux= and all kind of interfaces get broken in every possible way, in aver= age we have one interface breakage a week. So we are not concerned at= all. If you want to change the Crossbow APIs we use, just do it and = if possible, let us know in advance.

--Achim Hasenmueller
Director Engineering, VirtualBox
Sun Micros= ystems GmbH
Werkstrasse 24
71384 Weinstadt, Germany
pho= ne: +49 7151 604050


=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Sitz der Ge= sellschaft: Sun Microsystems GmbH,
Sonnenallee 1, 85551 Kirchheim-= Heimstetten 
Amtsgericht Muenchen: HRB 161028


On Apr 7, 2010, a= t 17:36 , Sebastien Roy wrote:

On 04/ 5/10 02:47 PM, Krishna Y= enduri wrote:
It was pointed out to me t= hat this needs to be a fast track since
there is a contract. So, I am making this a fast track c= ase
with the timer set to 4= /9/2010.
...
 &nbs= p; Header files:
=09<sys= /mac.h>= =09= =09= =09Consolidation Private
=09<sys/mac_client.h>=09=09Consolidation Private
=09<sys/vnic_mgmt.h>=09=09Consolidation Private
=09<sys/dls.h>=09=09=09Consolidation Private

The latter three header files are not currently includ= ed in any package.  I assume that this case delivers these heade= r files as part of some package, presumably pkg:/system/header.(?)
I am generally concerned about the viability of long term use of= these contracted interfaces by another consolidation given that the = interfaces are not centralized in any part of the ON source (there's = no easy way to place a big warning in the code concerning their consu= mption by another consolidation), and that these interfaces have rece= ntly undergone numerous and drastic changes.  Assuming that inte= rfaces remain volatile, this could lead to either unintentional break= age of VirtualBox, or complex version dependencies between VirtualBox= and the underlying host OS.  This is less of a concern if the i= nterfaces contracted have sedimented somewhat and are more stable tha= n they have been in the recent past.

This could be mitigated i= n a number of ways in the longer term. Committing to a Public MAC cli= ent API and VNIC API would be one solution.  Another might be to= integrate the Solaris kernel specific portion of VirtualBox into ON.=  Has either project team considered such options?

-Seb


G= eschaeftsfuehrer: J=FCrgen Kunz
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


--Boundary_(ID_qfxeEtLPKhvfQK0/LKBkIQ)-- From bhargava.yenduri@oracle.com Wed Apr 7 11:59:36 2010 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 o37IxaKF019862 for ; Wed, 7 Apr 2010 11:59:36 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o37IxZVM026166; Wed, 7 Apr 2010 11:59:35 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0I00L21SRB8T00@nwk-avmta-2.sfbay.sun.com>; Wed, 07 Apr 2010 11:59:35 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0I00IK0SRAQW50@nwk-avmta-2.sfbay.sun.com>; Wed, 07 Apr 2010 11:59:34 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o37IxXEO009245; Wed, 07 Apr 2010 18:59:34 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o37FmnLG017258; Wed, 07 Apr 2010 18:59:33 +0000 (GMT) Received: from abhmt010.oracle.com by acsmt355.oracle.com with ESMTP id 143847811270666765; Wed, 07 Apr 2010 11:59:25 -0700 Received: from [129.150.13.56] (/129.150.13.56) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Apr 2010 11:59:25 -0700 Date: Wed, 07 Apr 2010 11:59:18 -0700 From: Krishna Yenduri Subject: Re: PSARC/2010/112 - MAC client API and VNIC API updates In-reply-to: <4BBA3043.2070101@oracle.com> To: PSARC-ext@sun.com Cc: Markus Flierl , Achim Hasenmueller Message-id: <4BBCD606.1050005@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BBCD615.0148:SCFMA4539814,ss=1,fgs=0 References: <201004022158.o32LwHhu014735@sac.sfbay.sun.com> <4BBA3043.2070101@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20091207 Lightning/1.0pre Thunderbird/3.0 Status: RO Content-Length: 179 This case was approved in today's PSARC meeting. And both of the managers have signed the contract which is placed in the case directory as contract-01. Thanks, -Krishna