From sacadmin Mon Nov 10 05:54:45 2008 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 mAADsjj0010500; Mon, 10 Nov 2008 05:54:45 -0800 (PST) Received: (from carlsonj@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id mAADsjkZ010492; Mon, 10 Nov 2008 05:54:45 -0800 (PST) Date: Mon, 10 Nov 2008 05:54:45 -0800 (PST) From: James Carlson Message-Id: <200811101354.mAADsjkZ010492@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Sun Cluster TCP/IP Hooks Update [PSARC/2008/688 FastTrack timeout 11/17/2008] Status: RO Content-Length: 560 Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Sun Cluster TCP/IP Hooks Update 1.2. Name of Document Author/Supplier: Author: Huafeng Lu 1.3 Date of This Document: 10 November, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From carlsonj@phorcys.east.sun.com Mon Nov 10 06:25:02 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAAEP1H6011826 for ; Mon, 10 Nov 2008 06:25:01 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mAAEP1n4006315; Mon, 10 Nov 2008 09:25:01 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mAAEP14V006312; Mon, 10 Nov 2008 09:25:01 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18712.17469.201850.507877@gargle.gargle.HOWL> Date: Mon, 10 Nov 2008 09:25:01 -0500 From: James Carlson To: psarc-ext@sac.sfbay.sun.com cc: Huafeng Lu Subject: 2008/688 Sun Cluster TCP/IP Hooks Update X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 5472 I'm sponsoring this fast-track for Huafeng Lu and the Sun Cluster team. The timer is set to 11/17/2008, and a draft of the contract is available in the case directory as "contract-01". Note: the fast-track materials were presented to me as "open," though many of the cases related to these hooks are currently closed. The change in the system that is the subject of this case, though, should be reviewable independently, so this shouldn't cause problems. Introduction "TCP/IP hooks for clustering" (PSARC 1997/314) introduced several TCP/IP hooks for the Sun Cluster product, and the contract is 1997/314:contract-1.new. These hooks are called by the Solaris TCP/IP code at certain places. Now, to support client-side shared address (RFE 6717519), we need to modify one of these hooks, cl_inet_connect(). Release Binding A patch/micro release binding is asserted. This will require the release of coordinated patches for Solaris and Sun Cluster. Interfaces Exported Interface Stability Comments ================== ========= ======== cl_inet_connect Removed (was Contracted) PSARC 1997/314 cl_inet_connect2 Contr. Project Private function pointer cluster_version_supported Contr. Project Private cluster version supported by Solaris udp_t.udp_cl_v6lastdst Project Private most recent dest addr udp_t.udp_cl_lastdstport Project Private most recent dest port Detailed Description Currently, a shared address is used only at the server side. Server applications are started on Cluster nodes, which reply to requests coming from external clients. This proposal (RFE 6717519) aims to allow Cluster nodes to use shared addresses as client addresses to talk to external servers. Note: this proposal only handles TCP and UDP; SCTP is beyond its scope. For TCP, several Cluster nodes bind to the same shared address, then connect to external applications. The cl_inet_connect() hook is called at connect time (for both outgoing and incoming connection requests) to check if the 5-tuple is unique. The hook is added with a return value to indicate whether the check is passed, and an input parameter to indicate whether the connection is outgoing or incoming. The situation for UDP is a bit different. Since there is no real connection in UDP and the same socket can be used to send to multiple destinations, the major task is to register the five-tuple at the cluster level. Such registration is performed at connect(), sendto() and sendmsg(), which call the cl_inet_connect() hook at proper time. For performance reasons, sendto()/sendmsg() calls the hook only when the destination is new. To facilitate this, two new fields are added to the udp_t struct to store the most recent destination address and port: in6_addr_t udp_cl_v6lastdst; in_port_t udp_cl_lastdstport; In a sendto() or sendmsg(), the cl_inet_connect() hook is called only when the destination is different from most recent one. Versioning In addition to the hook signature changes listed above, the hook name will also be changed for versioning reasons. Thus, overall the new signature of the hook is: int (*cl_inet_connect2)(uint8_t protocol, boolean_t is_outgoing, sa_family_t addr_family, uint8_t *laddrp, in_port_t lport, uint8_t *faddrp, in_port_t fport); Here's the old signature for comparison. Note: after renaming, the old name cl_inet_connect is obsolete and will no longer be called from Solaris. void (*cl_inet_connect)(uint8_t protocol, sa_family_t addr_family, uint8_t *laddrp, in_port_t lport, uint8_t *faddrp, in_port_t fport); With changes at both Solaris and Cluster sides, there is a "version matching" issue. There is no mechanism to check if the Cluster version matches the Solaris release; the Cluster simply associate the hook with an implementation, if the hook is defined in Solaris. Thus, if the Cluster product is not running with the correct Solaris release, the hook will be associated with the wrong implementation, and may cause serious problems or even panic. To solve this problem, the function pointer is renamed as above. To help with future versioning, a new version string is introduced in Solaris code: const char *cluster_version_supported = "1.1"; The new Cluster code checks which Cluster version Solaris supports, and associates the corresponding hook implementation with the hook. This is a generic mechanism, but doesn't work for the currently released Cluster code, which doesn't check the version. As a workaround, we rename the hook in Solaris so that the current Cluster version won't be loaded after upgrading ON. This prevents the user from damaging his system, and release notes will indicate what the errors mean. Out of Scope Note the actual implementation of these hooks are in the Cluster code, not in the Solaris code. Solaris TCP/IP code only declares and calls them. For this project, the Cluster team is responsible for changing the implementation of the cl_inet_connect2() hook in the Sun Cluster code. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From carlsonj@phorcys.east.sun.com Tue Nov 11 03:28:57 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mABBSvIY015492 for ; Tue, 11 Nov 2008 03:28:57 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mABBSu8U009910; Tue, 11 Nov 2008 06:28:56 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mABBSuWp009907; Tue, 11 Nov 2008 06:28:56 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18713.27768.826421.472097@gargle.gargle.HOWL> Date: Tue, 11 Nov 2008 06:28:56 -0500 From: James Carlson To: psarc-ext@sac.sfbay.sun.com cc: Huafeng Lu Subject: 2008/688 Sun Cluster TCP/IP Hooks Update X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 372 The project team has asked me to place this fast-track request in "waiting need spec" state. I'll restart it when they've worked out their issues. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From erik.nordmark@sun.com Tue Nov 11 22:49:07 2008 Received: from jurassic.eng.sun.com (jurassic-226-b.SFBay.Sun.COM [129.146.226.130]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAC6n7bx023624 for ; Tue, 11 Nov 2008 22:49:07 -0800 (PST) Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAC6n65s837344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Nov 2008 22:49:06 -0800 (PST) Message-ID: <491A7C5F.3040106@sun.com> Date: Tue, 11 Nov 2008 22:49:03 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: James Carlson CC: psarc-ext@sac.sfbay.sun.com, Huafeng Lu Subject: Re: 2008/688 Sun Cluster TCP/IP Hooks Update References: <18712.17469.201850.507877@gargle.gargle.HOWL> In-Reply-To: <18712.17469.201850.507877@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1358 James Carlson wrote: > The situation for UDP is a bit different. Since there is no real > connection in UDP and the same socket can be used to send to > multiple destinations, the major task is to register the five-tuple > at the cluster level. Such registration is performed at connect(), > sendto() and sendmsg(), which call the cl_inet_connect() hook at > proper time. For performance reasons, sendto()/sendmsg() calls the > hook only when the destination is new. To facilitate this, two new > fields are added to the udp_t struct to store the most recent > destination address and port: in6_addr_t udp_cl_v6lastdst; in_port_t > udp_cl_lastdstport; In a sendto() or sendmsg(), the > cl_inet_connect() hook is called only when the destination is > different from most recent one. Since UDP currently does not call cl_inet_connect, I assume the above paragraph refers to the proposed new behavior. Does the reference to sendmsg/sendto imply that this will be implemented in sockfs? Or will it be implemented in TCP? I don't understand why a new udp_cl_v6lastdst is needed since udp already has a udp_v6lastdst field. Is the intent that Cluster be useful with exclusive-IP zones in the future? If so it might make sense to take this opportunity to introduce an instance identifier to the function signatures. Erik From Huafeng.Lv@Sun.COM Wed Nov 12 00:30:48 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAC8UmJN027439 for ; Wed, 12 Nov 2008 00:30:48 -0800 (PST) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.EU.Sun.COM [192.18.6.21]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAC8Ultu023307 for ; Wed, 12 Nov 2008 00:30:47 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAC8UfrE006698 for ; Wed, 12 Nov 2008 08:30:42 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KA700D01O4ZYR00@fe-emea-09.sun.com> (original mail from Huafeng.Lv@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Wed, 12 Nov 2008 08:30:41 +0000 (GMT) Received: from [129.158.215.196] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KA700IBUOYVJ3C0@fe-emea-09.sun.com>; Wed, 12 Nov 2008 08:30:36 +0000 (GMT) Date: Wed, 12 Nov 2008 16:28:53 +0800 From: Huafeng Lu Subject: Re: 2008/688 Sun Cluster TCP/IP Hooks Update In-reply-to: <491A7C5F.3040106@sun.com> Sender: Huafeng.Lv@Sun.COM To: Erik Nordmark Cc: James Carlson , psarc-ext@sac.sfbay.sun.com, Honsing Cheng Message-id: <491A93C5.7030300@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT References: <18712.17469.201850.507877@gargle.gargle.HOWL> <491A7C5F.3040106@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 2187 于 2008年11月12日 14:49, Erik Nordmark 写道: > James Carlson wrote: > >> The situation for UDP is a bit different. Since there is no real >> connection in UDP and the same socket can be used to send to >> multiple destinations, the major task is to register the five-tuple >> at the cluster level. Such registration is performed at connect(), >> sendto() and sendmsg(), which call the cl_inet_connect() hook at >> proper time. For performance reasons, sendto()/sendmsg() calls the >> hook only when the destination is new. To facilitate this, two new >> fields are added to the udp_t struct to store the most recent >> destination address and port: in6_addr_t udp_cl_v6lastdst; in_port_t >> udp_cl_lastdstport; In a sendto() or sendmsg(), the >> cl_inet_connect() hook is called only when the destination is >> different from most recent one. [ cc Honsing from the Cluster team.] Hi Erik, Thanks for reviewing it. > Since UDP currently does not call cl_inet_connect, I assume the above > paragraph refers to the proposed new behavior. Yes, for the new behavior. > > Does the reference to sendmsg/sendto imply that this will be implemented > in sockfs? Or will it be implemented in TCP? When sendmsg/sendto are called from an application, the registrations are finally implemented in udp_wput(). You can refer to the webrev at http://greatwall.prc/~hl157128/tmp.cluster/webrev.stonedog.1111/ > > I don't understand why a new udp_cl_v6lastdst is needed since udp > already has a udp_v6lastdst field. The udp_v6lastdst field is used for Trusted Extension. To be safe, I don't want to reuse it, so the two new fields are introduced. > > > Is the intent that Cluster be useful with exclusive-IP zones in the future? > If so it might make sense to take this opportunity to introduce an > instance identifier to the function signatures. The requirement for this project (RFE 6717519) comes from a customer (Siemens). Using Cluster with exclusive zones is not in the requirement. I don't know if this will happen in the future. Honsing is from the Cluster team, so he may provide such information. Thanks. -- Huafeng > > Erik > From Honsing.Cheng@Sun.COM Wed Nov 12 17:12:27 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAD1CRDm011870 for ; Wed, 12 Nov 2008 17:12:27 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAD1CRd5053179 for ; Wed, 12 Nov 2008 17:12:27 -0800 (PST) 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 mAD1CM6D004534 for ; Wed, 12 Nov 2008 17:12:22 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KA800401ZBT5U00@fe-sfbay-10.sun.com> (original mail from Honsing.Cheng@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Wed, 12 Nov 2008 17:12:22 -0800 (PST) Received: from [129.146.105.38] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KA800GAZZCLXN30@fe-sfbay-10.sun.com>; Wed, 12 Nov 2008 17:12:21 -0800 (PST) Date: Wed, 12 Nov 2008 17:20:29 -0800 From: Honsing Cheng Subject: Re: 2008/688 Sun Cluster TCP/IP Hooks Update In-reply-to: <491A93C5.7030300@sun.com> Sender: Honsing.Cheng@Sun.COM To: Huafeng Lu Cc: Erik Nordmark , James Carlson , psarc-ext@sac.sfbay.sun.com Message-id: <491B80DD.5000201@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT References: <18712.17469.201850.507877@gargle.gargle.HOWL> <491A7C5F.3040106@sun.com> <491A93C5.7030300@sun.com> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 2572 Huafeng Lu wrote: > 于 2008年11月12日 14:49, Erik Nordmark 写道: >> James Carlson wrote: >> >>> The situation for UDP is a bit different. Since there is no real >>> connection in UDP and the same socket can be used to send to >>> multiple destinations, the major task is to register the five-tuple >>> at the cluster level. Such registration is performed at connect(), >>> sendto() and sendmsg(), which call the cl_inet_connect() hook at >>> proper time. For performance reasons, sendto()/sendmsg() calls the >>> hook only when the destination is new. To facilitate this, two new >>> fields are added to the udp_t struct to store the most recent >>> destination address and port: in6_addr_t udp_cl_v6lastdst; in_port_t >>> udp_cl_lastdstport; In a sendto() or sendmsg(), the >>> cl_inet_connect() hook is called only when the destination is >>> different from most recent one. > > [ cc Honsing from the Cluster team.] > > > Hi Erik, > > Thanks for reviewing it. > >> Since UDP currently does not call cl_inet_connect, I assume the above >> paragraph refers to the proposed new behavior. > > Yes, for the new behavior. >> >> Does the reference to sendmsg/sendto imply that this will be >> implemented in sockfs? Or will it be implemented in TCP? > > When sendmsg/sendto are called from an application, the registrations > are finally implemented in udp_wput(). You can refer to the webrev at > http://greatwall.prc/~hl157128/tmp.cluster/webrev.stonedog.1111/ >> >> I don't understand why a new udp_cl_v6lastdst is needed since udp >> already has a udp_v6lastdst field. > > The udp_v6lastdst field is used for Trusted Extension. To be safe, I > don't want to reuse it, so the two new fields are introduced. >> >> >> Is the intent that Cluster be useful with exclusive-IP zones in the >> future? >> If so it might make sense to take this opportunity to introduce an >> instance identifier to the function signatures. Currently the load balancing feature is limited to shared-IP zones. But we do believe that at some future point we would like to expand it to include exclusive-IP zones. So if it is relatively straight-forward to include the instance ID, we should pursue it. Honsing > > The requirement for this project (RFE 6717519) comes from a customer > (Siemens). Using Cluster with exclusive zones is not in the requirement. > I don't know if this will happen in the future. > > Honsing is from the Cluster team, so he may provide such information. > > Thanks. > -- > Huafeng > > >> >> Erik >> > From erik.nordmark@sun.com Wed Nov 12 21:23:01 2008 Received: from jurassic.eng.sun.com (jurassic-226-b.SFBay.Sun.COM [129.146.226.130]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAD5N1dd019424 for ; Wed, 12 Nov 2008 21:23:01 -0800 (PST) Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAD5MwtU868853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2008 21:22:59 -0800 (PST) Message-ID: <491BB9B2.9070306@sun.com> Date: Wed, 12 Nov 2008 21:22:58 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Huafeng Lu CC: James Carlson , psarc-ext@sac.sfbay.sun.com, Honsing Cheng Subject: Re: 2008/688 Sun Cluster TCP/IP Hooks Update References: <18712.17469.201850.507877@gargle.gargle.HOWL> <491A7C5F.3040106@sun.com> <491A93C5.7030300@sun.com> In-Reply-To: <491A93C5.7030300@sun.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 800 Huafeng Lu wrote: >> I don't understand why a new udp_cl_v6lastdst is needed since udp >> already has a udp_v6lastdst field. > > The udp_v6lastdst field is used for Trusted Extension. To be safe, I > don't want to reuse it, so the two new fields are introduced. That approach leads to exponentially increasing complexity over time. If you understand udp.c then you should be able to convince yourself that your use of udp_v6lastdst doesn't interfere with its use in TX. If you don't understand udp.c sufficiently well to do that, then it might be that you shouldn't touch udp.c in the first place. Sorry to be so hard-nosed, but I'm trying to dig ourselves out of 15+ years of this attitude of changing code without fully understanding it which has resulted in a bit of a mess. Erik From erik.nordmark@sun.com Wed Nov 12 21:25:50 2008 Received: from jurassic.eng.sun.com (jurassic-226-b.SFBay.Sun.COM [129.146.226.130]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAD5PorZ019484 for ; Wed, 12 Nov 2008 21:25:50 -0800 (PST) Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAD5PaxZ868915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2008 21:25:50 -0800 (PST) Message-ID: <491BBA50.4030708@sun.com> Date: Wed, 12 Nov 2008 21:25:36 -0800 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.17 (X11/20081023) MIME-Version: 1.0 To: Honsing Cheng CC: Huafeng Lu , James Carlson , psarc-ext@sac.sfbay.sun.com Subject: Re: 2008/688 Sun Cluster TCP/IP Hooks Update References: <18712.17469.201850.507877@gargle.gargle.HOWL> <491A7C5F.3040106@sun.com> <491A93C5.7030300@sun.com> <491B80DD.5000201@sun.com> In-Reply-To: <491B80DD.5000201@sun.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 701 Honsing Cheng wrote: > Currently the load balancing feature is limited to shared-IP zones. But > we do believe that at some future point we would like to expand it to > include exclusive-IP zones. So if it is relatively straight-forward to > include the instance ID, we should pursue it. All you'd need is to include a extra argument to all the cl callbacks (in the form of a netstackid_t or something similar.) I don't know if that would cause more incompatibilities than you are already causing with this project. If it doesn't it might make sense to include that argument now even though clustering would never inspect its value until you decide to support exclusive-IP zones. Erik From carlsonj@phorcys.east.sun.com Thu Nov 13 06:19:18 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mADEJIRA005861 for ; Thu, 13 Nov 2008 06:19:18 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mADEJHh3023765; Thu, 13 Nov 2008 09:19:17 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mADEJHW6023762; Thu, 13 Nov 2008 09:19:17 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18716.14181.801816.501120@gargle.gargle.HOWL> Date: Thu, 13 Nov 2008 09:19:17 -0500 From: James Carlson To: Erik Nordmark Cc: Huafeng Lu , psarc-ext@sac.sfbay.sun.com, Honsing Cheng Subject: Re: 2008/688 Sun Cluster TCP/IP Hooks Update In-Reply-To: <491BB9B2.9070306@sun.com> References: <18712.17469.201850.507877@gargle.gargle.HOWL> <491A7C5F.3040106@sun.com> <491A93C5.7030300@sun.com> <491BB9B2.9070306@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1160 Erik Nordmark writes: > If you understand udp.c then you should be able to convince yourself > that your use of udp_v6lastdst doesn't interfere with its use in TX. > If you don't understand udp.c sufficiently well to do that, then it > might be that you shouldn't touch udp.c in the first place. I agree with Erik on this point, but I don't think this is actually an architectural issue, but rather a matter of design. I'd encourage the folks involved to handle it off of the ARC mailing list. The other issue -- lack of IP Instances information -- is architectural, as it involves the support of one project by another. As long as we're suffering a pair of linked patches to get to the new API here, it does seem reasonable to say that we could include the required arguments to make stack instances work in the future. As long as we're paying the patching complexity price now, is there a specific reason to _avoid_ doing that? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Huafeng.Lv@Sun.COM Thu Nov 13 06:31:25 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mADEVP72005930 for ; Thu, 13 Nov 2008 06:31:25 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mADEVOTd001879 for ; Thu, 13 Nov 2008 06:31:25 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mADEVJRT015941 for ; Thu, 13 Nov 2008 14:31:19 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0KAA00J01054A300@mail-apac.sun.com> (original mail from Huafeng.Lv@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Thu, 13 Nov 2008 22:31:19 +0800 (SGT) Received: from [129.150.146.95] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0KAA001PK0C4GRW7@mail-apac.sun.com>; Thu, 13 Nov 2008 22:31:18 +0800 (SGT) Date: Thu, 13 Nov 2008 22:31:15 +0800 From: Huafeng Lu Subject: Re: 2008/688 Sun Cluster TCP/IP Hooks Update In-reply-to: <18716.14181.801816.501120@gargle.gargle.HOWL> Sender: Huafeng.Lv@Sun.COM To: James Carlson Cc: Erik Nordmark , psarc-ext@sac.sfbay.sun.com, Honsing Cheng , Huafeng.Lv@Sun.COM Message-id: <491C3A33.6080708@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT References: <18712.17469.201850.507877@gargle.gargle.HOWL> <491A7C5F.3040106@sun.com> <491A93C5.7030300@sun.com> <491BB9B2.9070306@sun.com> <18716.14181.801816.501120@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) Status: RO Content-Length: 1445 James Carlson 写道: > Erik Nordmark writes: >> If you understand udp.c then you should be able to convince yourself >> that your use of udp_v6lastdst doesn't interfere with its use in TX. >> If you don't understand udp.c sufficiently well to do that, then it >> might be that you shouldn't touch udp.c in the first place. > > I agree with Erik on this point, but I don't think this is actually an > architectural issue, but rather a matter of design. I'd encourage the > folks involved to handle it off of the ARC mailing list. > > The other issue -- lack of IP Instances information -- is > architectural, as it involves the support of one project by another. > As long as we're suffering a pair of linked patches to get to the new > API here, it does seem reasonable to say that we could include the > required arguments to make stack instances work in the future. > > As long as we're paying the patching complexity price now, is there a > specific reason to _avoid_ doing that? To support the IP instance information, and to support future changes, we could change the API to use a TLV (type, length, value). We can put all paramters in a structure like: typedef cl_hook_param { int cl_type; size_t cl_len; uint8_t cl_value[]; } cl_hook_param_t; Thus, all future changes can be handled. This will of course change the signature of the hook; but since we're already here, we think it's ok to make the change. -- Huafeng From carlsonj@phorcys.east.sun.com Thu Nov 13 06:33:33 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mADEXX8j005977 for ; Thu, 13 Nov 2008 06:33:33 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mADEXWKP023871; Thu, 13 Nov 2008 09:33:32 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mADEXWnB023868; Thu, 13 Nov 2008 09:33:32 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18716.15036.896899.404896@gargle.gargle.HOWL> Date: Thu, 13 Nov 2008 09:33:32 -0500 From: James Carlson To: Huafeng Lu Cc: Erik Nordmark , psarc-ext@sac.sfbay.sun.com, Honsing Cheng Subject: Re: 2008/688 Sun Cluster TCP/IP Hooks Update In-Reply-To: <491C3A33.6080708@sun.com> References: <18712.17469.201850.507877@gargle.gargle.HOWL> <491A7C5F.3040106@sun.com> <491A93C5.7030300@sun.com> <491BB9B2.9070306@sun.com> <18716.14181.801816.501120@gargle.gargle.HOWL> <491C3A33.6080708@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 905 Huafeng Lu writes: > To support the IP instance information, and to support future changes, > we could change the API to use a TLV (type, length, value). We can put > all paramters in a structure like: > typedef cl_hook_param { > int cl_type; > size_t cl_len; > uint8_t cl_value[]; > } cl_hook_param_t; > Thus, all future changes can be handled. Not sure how that'd work, but I suggest discussing the issue with the other folks involved in the project and then bringing the completed proposal back for ARC review. (My guess is that the 'types' defined effectively become part of the API itself, so the support for future changes given by that may be a little limited.) -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Huafeng.Lv@Sun.COM Thu Nov 13 18:37:51 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mAE2bp08014712 for ; Thu, 13 Nov 2008 18:37:51 -0800 (PST) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.EU.Sun.COM [192.18.6.21]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mAE2behP035163 for ; Thu, 13 Nov 2008 18:37:41 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mAE2bZPl002593 for ; Fri, 14 Nov 2008 02:37:35 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KAA00H01XSU0T00@fe-emea-09.sun.com> (original mail from Huafeng.Lv@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Fri, 14 Nov 2008 02:37:35 +0000 (GMT) Received: from [129.158.215.196] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KAA008NMXYH5230@fe-emea-09.sun.com>; Fri, 14 Nov 2008 02:37:34 +0000 (GMT) Date: Fri, 14 Nov 2008 10:35:54 +0800 From: Huafeng Lu Subject: Re: 2008/688 Sun Cluster TCP/IP Hooks Update In-reply-to: <18716.15036.896899.404896@gargle.gargle.HOWL> Sender: Huafeng.Lv@Sun.COM To: James Carlson Cc: Erik Nordmark , psarc-ext@sac.sfbay.sun.com, Honsing Cheng , Kacheong Poon , Huafeng.Lv@Sun.COM Message-id: <491CE40A.1070404@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <18712.17469.201850.507877@gargle.gargle.HOWL> <491A7C5F.3040106@sun.com> <491A93C5.7030300@sun.com> <491BB9B2.9070306@sun.com> <18716.14181.801816.501120@gargle.gargle.HOWL> <491C3A33.6080708@sun.com> <18716.15036.896899.404896@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 2631 ? 2008?11?13? 22:33, James Carlson ??: > Huafeng Lu writes: >> To support the IP instance information, and to support future changes, >> we could change the API to use a TLV (type, length, value). We can put >> all paramters in a structure like: >> typedef cl_hook_param { >> int cl_type; >> size_t cl_len; >> uint8_t cl_value[]; >> } cl_hook_param_t; >> Thus, all future changes can be handled. > > Not sure how that'd work, but I suggest discussing the issue with the > other folks involved in the project and then bringing the completed > proposal back for ARC review. > > (My guess is that the 'types' defined effectively become part of the > API itself, so the support for future changes given by that may be a > little limited.) Let me state it more clearly. The whole idea is illustrated below. We first define the following: typedef struct cl_hook_param { int cl_type; uint8_t cl_value[]; } cl_hook_param_t; int (*cl_inet_connect2)(cl_hook_param_t *chp); typedef struct cl_hook_conn_param { int type; netstackid_t stack_id; uint8_t protocol; boolean_t is_outgoing; sa_family_t family; uint8_t *laddrp; in_port_t lport; uint8_t *faddrp; in_port_t fport; } cl_hook_conn_param_t; To call the hook, at Solaris side, we do: cl_hook_conn_param_t hp; hp.type = CL_HOOK_TYPE_CONN; hp.stack_id = id; hp.protocol = IPPROTO_TCP; ... if ((err = cl_inet_connect2(&hp)) != 0) ... At Cluster side, the hook implementation looks like: int cl_inet_connect_impl(cl_hook_param_t *chp) { if (chp->cl_type == CL_HOOK_TYPE_CONN) { //get all arguments from chp->cl_value } ... } In the future, if we want to add or change some arguments, we only need to change cl_hook_conn_param_t, while the hook signature will remain unchanged. One issue with this approach is that, all existing Solaris that calls the hook need big code change - each needs to switch to the cl_hook_xxx_param_t structure. An alternative is to keep all existing arguments and the netstackid_t outside cl_hook_xxx_param_t, so that this time all the hook only need to add a "NULL" argument. Signature: int (*cl_inet_connect2)(netstackid_t stack_id, uint8_t protocol, boolean_t is_outgoing, sa_family_t addr_family, uint8_t *laddrp, in_port_t lport, uint8_t *faddrp, in_port_t fport, cl_hook_param_t *chp) = NULL; How to call it for now (the last argument is NULL): err = (*cl_inet_connect2)(id, IPPROTO_TCP, ..., fport, NULL); In the future, when something changes, they can be put into cl_hook_xxx_param_t and passed into the hook. How do you think? -- Huafeng From Huafeng.Lv@Sun.COM Mon Dec 1 22:09:03 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB26932M024610 for ; Mon, 1 Dec 2008 22:09:03 -0800 (PST) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.EU.Sun.COM [192.18.6.21]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mB2692KV057069 for ; Mon, 1 Dec 2008 22:09:02 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mB268u7i008794 for ; Tue, 2 Dec 2008 06:08:56 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KB800901JFZJ300@fe-emea-09.sun.com> (original mail from Huafeng.Lv@Sun.COM) for psarc-ext@sac.sfbay.sun.com; Tue, 02 Dec 2008 06:08:56 +0000 (GMT) Received: from [129.158.215.196] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KB8005HCJQRPM10@fe-emea-09.sun.com>; Tue, 02 Dec 2008 06:08:56 +0000 (GMT) Date: Tue, 02 Dec 2008 14:07:06 +0800 From: Huafeng Lu Subject: Re: 2008/688 Sun Cluster TCP/IP Hooks Update In-reply-to: <491BB9B2.9070306@sun.com> Sender: Huafeng.Lv@Sun.COM To: Erik Nordmark Cc: James Carlson , psarc-ext@sac.sfbay.sun.com, Honsing Cheng , Jarrett Lu , Ken Powell Message-id: <4934D08A.2040609@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT References: <18712.17469.201850.507877@gargle.gargle.HOWL> <491A7C5F.3040106@sun.com> <491A93C5.7030300@sun.com> <491BB9B2.9070306@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1584 于 2008年11月13日 13:22, Erik Nordmark 写道: > Huafeng Lu wrote: > >>> I don't understand why a new udp_cl_v6lastdst is needed since udp >>> already has a udp_v6lastdst field. >> >> The udp_v6lastdst field is used for Trusted Extension. To be safe, I >> don't want to reuse it, so the two new fields are introduced. > > That approach leads to exponentially increasing complexity over time. After discussing with TX guys (cc'ed), we're re-using the udp_v6lastdst field. Only udp_lastdstport is added to udp_t. They're not mentioned in the updated PSARC material, though. 于 2008年11月13日 13:25, Erik Nordmark 写道: > Honsing Cheng wrote: >> Currently the load balancing feature is limited to shared-IP zones. >> But we do believe that at some future point we would like to expand it >> to include exclusive-IP zones. So if it is relatively straight-forward >> to include the instance ID, we should pursue it. > > All you'd need is to include a extra argument to all the cl callbacks > (in the form of a netstackid_t or something similar.) > > I don't know if that would cause more incompatibilities than you are > already causing with this project. If it doesn't it might make sense to > include that argument now even though clustering would never inspect its > value until you decide to support exclusive-IP zones. Now all hooks are added with two arguments, 'netstackid_t stack_id' and 'void *args'. The latter can accommodate future changes to avoid changing the signatures again. We'll resubmit the PSARC materials soon. Thanks. -- Huafeng From carlsonj@phorcys.east.sun.com Wed Dec 3 08:06:56 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mB3G6t4D008287 for ; Wed, 3 Dec 2008 08:06:55 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mB3G6kKb011920; Wed, 3 Dec 2008 16:06:51 GMT 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 <0KBB00A0X63D5X00@brm-avmta-1.central.sun.com>; Wed, 03 Dec 2008 09:06:49 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBB006LV63B0X30@brm-avmta-1.central.sun.com>; Wed, 03 Dec 2008 09:06:47 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB3G6lCn012936; Wed, 03 Dec 2008 11:06:47 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mB3G6lXE012933; Wed, 03 Dec 2008 11:06:47 -0500 (EST) Date: Wed, 03 Dec 2008 11:06:47 -0500 From: James Carlson Subject: 2008/688 Sun Cluster TCP/IP Hooks Update To: psarc-ext@sun.com Cc: Huafeng Lu Message-id: <18742.44695.306474.37642@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 6531 I'm restarting the timer on this fast-track for Huafeng Lu and the Sun Cluster team. The changes from the last go-around include removing the version number string and adding a netstack ID and a flexible void * argument for future expansion, and the contract (contract-01) has been updated. The timer is set to 12/10/2008. Introduction "TCP/IP hooks for Clustering" (PSARC 1997/314) introduced several TCP/IP hooks for the Sun Cluster product, and the contract is 1997/314:contract-1.new. These hooks are called by the Solaris TCP/IP code at certain places. Now, to support client-side shared address (RFE 6717519), we need to modify one of these hooks, cl_inet_connect(). In addition, two more arguments (netstackid_t, void *) are added to the signatures of all hooks to allow Cluster to support exclusive-IP zones and to accommodate future signature changes. Release Binding A patch/micro release binding is asserted. This will require the release of coordinated patches for Solaris and Sun Cluster. Interfaces Exported Interface Stability Comments ================== ========= ======== cl_inet_connect Removed (was Contracted) PSARC 1997/314 cl_inet_connect2 Contr. Project Private function pointer cl_inet_isclusterwide Contr. Project Private function pointer cl_inet_ipident Contr. Project Private function pointer cl_inet_getspi Contr. Project Private function pointer cl_inet_checkspi Contr. Project Private function pointer cl_inet_deletespi Contr. Project Private function pointer cl_inet_idlesa Contr. Project Private function pointer cl_inet_listen Contr. Project Private function pointer cl_inet_unlisten Contr. Project Private function pointer cl_inet_disconnect Contr. Project Private function pointer cl_tcp_walk_list Contr. Project Private function pointer cl_inet_bind Contr. Project Private function pointer cl_inet_unbind Contr. Project Private function pointer Detailed Description Currently, a shared address is used only at the server side. Server applications are started on Cluster nodes, which reply to requests coming from external clients. This proposal (RFE 6717519) aims to allow Cluster nodes to use shared addresses as client addresses to talk to external servers. Note: this proposal only handles TCP and UDP; SCTP is beyond its scope. For TCP, several Cluster nodes bind to the same shared address, then connect to external applications. The cl_inet_connect() hook is called at connect time (for both outgoing and incoming connection requests) to let the Cluster software handle the packets for these connections to be dispatched to the right Cluster code. The hook is added with a return value to indicate whether the Cluster software succeeded in handling the connection, and an input parameter to indicate whether the connection is outgoing or incoming that is needed by the Cluster software. The situation for UDP is a bit different. Since there is no real connection in UDP and the same socket can be used to send to multiple destinations, the major task is to register the association with the Cluster software. Such registration is performed at connect(), sendto() and sendmsg(), which call the cl_inet_connect() hook at proper time. For performance reasons, sendto()/sendmsg() calls the hook only when the destination is new. The cl_inet_connect() hook will also be renamed to cl_inet_connect2() to avoid confusing old version of Cluster. After renaming, the old name cl_inet_connect is obsolete and will no longer be called from Solaris. Currently the Cluster product is limited to shared-IP zones, but in the future Cluster will also be useful with exclusive-IP zones. To support this, the signatures of all Cluster hooks are added an instance identifier (netstackid_t). In addition, to avoid further signature changes, a void* argument is also added to accommodate all other possible parametners. So the new signatures of the hooks are listed below. The first argument (netstackid_t stack_id) and the last (void *args) are added by this case. cl_inet_connect2 has one new more "boolean_t is_outgoing" argument. int (*cl_inet_isclusterwide)(netstackid_t stack_id, uint8_t protocol, sa_family_t addr_family, uint8_t *laddrp, void *args); uint32_t (*cl_inet_ipident)(netstackid_t stack_id, uint8_t protocol, sa_family_t addr_family, uint8_t *laddrp, uint8_t *faddrp, void *args); void (*cl_inet_getspi)(netstackid_t, uint8_t, uint8_t *, size_t, void *args); int (*cl_inet_checkspi)(netstackid_t, uint8_t, uint32_t, void *args); void (*cl_inet_deletespi)(netstackid_t, uint8_t, uint32_t, void *args); void (*cl_inet_idlesa)(netstackid_t, uint8_t, uint32_t, sa_family_t, in6_addr_t, in6_addr_t, void *args); void (*cl_inet_listen)(netstackid_t stack_id, uint8_t protocol, sa_family_t addr_family, uint8_t *laddrp, in_port_t lport, void *args); void (*cl_inet_unlisten)(netstackid_t stack_id, uint8_t protocol, sa_family_t addr_family, uint8_t *laddrp, in_port_t lport, void *args); int (*cl_inet_connect2)(netstackid_t stack_id, uint8_t protocol, boolean_t is_outgoing, sa_family_t addr_family, uint8_t *laddrp, in_port_t lport, uint8_t *faddrp, in_port_t fport, void *args); void (*cl_inet_disconnect)(netstackid_t stack_id, uint8_t protocol, sa_family_t addr_family, uint8_t *laddrp, in_port_t lport, uint8_t *faddrp, in_port_t fport, void *args); int cl_tcp_walk_list(netstackid_t stack_id, int (*callback)(cl_tcp_info_t *, void *), void *arg); void (*cl_inet_bind)(netstackid_t stack_id, uchar_t protocol, sa_family_t addr_family, uint8_t *laddrp, in_port_t lport, void *args); void (*cl_inet_unbind)(netstackid_t stack_id, uint8_t protocol, sa_family_t addr_family, uint8_t *laddrp, in_port_t lport, void *args); Out of Scope Note the actual implementation of these hooks are in the Cluster code, not in the Solaris code. Solaris TCP/IP code only declares and calls them. For this project, the Cluster team is responsible for changing the implementation of the cl_inet_connect2() hook in the Sun Cluster code. From sacadmin Wed Dec 10 07:17:03 2008 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 mBAFH38R024848 for ; Wed, 10 Dec 2008 07:17:03 -0800 (PST) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBAFH29D026173 for <@sunmail2sca.sfbay.sun.com:psarc-members@sun.com>; Wed, 10 Dec 2008 07:17:03 -0800 (PST) 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 <0KBO00C1L2GFES00@nwk-avmta-2.sfbay.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Wed, 10 Dec 2008 07:17:03 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBO001VG2GDMCE0@nwk-avmta-2.sfbay.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Wed, 10 Dec 2008 07:17:01 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mBAFH1hb014350 for ; Wed, 10 Dec 2008 10:17:01 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mBAFH1HI014347; Wed, 10 Dec 2008 10:17:01 -0500 (EST) Date: Wed, 10 Dec 2008 10:17:01 -0500 From: James Carlson Subject: Re: 2008/688 Sun Cluster TCP/IP Hooks Update In-reply-to: <18742.44695.306474.37642@gargle.gargle.HOWL> To: psarc-members@sun.com Message-id: <18751.56685.120363.276484@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18742.44695.306474.37642@gargle.gargle.HOWL> Status: RO Content-Length: 665 > I'm restarting the timer on this fast-track for Huafeng Lu and the Sun > Cluster team. The changes from the last go-around include removing > the version number string and adding a netstack ID and a flexible void > * argument for future expansion, and the contract (contract-01) has > been updated. The timer is set to 12/10/2008. I need a member to take a look at this proposal, so that I can meet the "+1" threshold. Any volunteers? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Richard.Matthews@sun.com Wed Dec 10 08:02:14 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBAG2DU5014426 for ; Wed, 10 Dec 2008 08:02:14 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id mBAFtYHc012516 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 11 Dec 2008 00:02:11 +0800 (SGT) 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 <0KBO00E074J9NM00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 10 Dec 2008 08:01:57 -0800 (PST) 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 <0KBO00DP54J7DN20@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 10 Dec 2008 08:01:55 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBAG1t1X011464 for ; Wed, 10 Dec 2008 16:01:55 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBO0090116V4Z00@mail-amer.sun.com> (original mail from Richard.Matthews@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 10 Dec 2008 09:01:55 -0700 (MST) Received: from [129.152.9.14] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBO009D44HOAYD0@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 10 Dec 2008 09:01:01 -0700 (MST) Date: Wed, 10 Dec 2008 10:01:00 -0600 From: Rick Matthews Subject: Re: 2008/688 Sun Cluster TCP/IP Hooks Update In-reply-to: <18742.44695.306474.37642@gargle.gargle.HOWL> Sender: Richard.Matthews@sun.com To: James Carlson Cc: PSARC-ext@sun.com, Huafeng Lu Reply-to: Richard.Matthews@sun.com Message-id: <493FE7BC.20407@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18742.44695.306474.37642@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 484 Looks good +1 -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- From sacadmin Wed Dec 10 08:22:19 2008 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 mBAGMJ41013327 for ; Wed, 10 Dec 2008 08:22:19 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBAGMEPp021267 for <@sunmail2sca.sfbay.sun.com:psarc-members@sun.com>; Wed, 10 Dec 2008 08:22:19 -0800 (PST) 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 <0KBO00F1N5H5OQ00@nwk-avmta-2.sfbay.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Wed, 10 Dec 2008 08:22:17 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBO00DM65H2DK40@nwk-avmta-2.sfbay.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Wed, 10 Dec 2008 08:22:14 -0800 (PST) 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 mBAGME5Z022294 for ; Wed, 10 Dec 2008 08:22:14 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBO0080158HLE00@fe-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for psarc-members@sun.com (ORCPT psarc-members@sun.com); Wed, 10 Dec 2008 08:22:14 -0800 (PST) Received: from [129.153.2.14] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBO004RE5GQUE40@fe-sfbay-09.sun.com> for psarc-members@sun.com (ORCPT psarc-members@sun.com); Wed, 10 Dec 2008 08:22:07 -0800 (PST) Date: Wed, 10 Dec 2008 08:22:02 -0800 From: "Garrett D'Amore" Subject: Re: 2008/688 Sun Cluster TCP/IP Hooks Update In-reply-to: <18751.56685.120363.276484@gargle.gargle.HOWL> Sender: Garrett.Damore@sun.com To: James Carlson Cc: psarc-members@sun.com Message-id: <493FECAA.6020001@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_drPlUEiS1QBhWMb8P8kt9Q)" X-PMX-Version: 5.4.1.325704 References: <18742.44695.306474.37642@gargle.gargle.HOWL> <18751.56685.120363.276484@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 2267 This is a multi-part message in MIME format. --Boundary_(ID_drPlUEiS1QBhWMb8P8kt9Q) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT On 12/10/08 07:17, James Carlson wrote: >> I'm restarting the timer on this fast-track for Huafeng Lu and the Sun >> Cluster team. The changes from the last go-around include removing >> the version number string and adding a netstack ID and a flexible void >> * argument for future expansion, and the contract (contract-01) has >> been updated. The timer is set to 12/10/2008. >> > > I need a member to take a look at this proposal, so that I can meet > the "+1" threshold. Any volunteers? > > I believe the newly annointed member probably has the best expertise besides yourself in this area. But if nobody else steps up to the plate, I'll try to review it thoroughly. But I won't get to it before today's meeting. -- Garrett --Boundary_(ID_drPlUEiS1QBhWMb8P8kt9Q) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT On 12/10/08 07:17, James Carlson wrote: 
I'm restarting the timer on this fast-track for Huafeng Lu and the Sun
Cluster team.  The changes from the last go-around include removing
the version number string and adding a netstack ID and a flexible void
* argument for future expansion, and the contract (contract-01) has
been updated.  The timer is set to 12/10/2008.
    

I need a member to take a look at this proposal, so that I can meet
the "+1" threshold.  Any volunteers?
I believe the newly annointed member probably has the best expertise besides yourself in this area.  But if nobody else steps up to the plate, I'll try to review it thoroughly.  But I won't get to it before today's meeting.

    -- Garrett
--Boundary_(ID_drPlUEiS1QBhWMb8P8kt9Q)-- From Burt.Clouse@sun.com Wed Dec 10 08:35:41 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBAGZeHh013854 for ; Wed, 10 Dec 2008 08:35:41 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id mBAGZWTx006332 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 11 Dec 2008 00:35:39 +0800 (SGT) 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 <0KBO0028863EP300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Dec 2008 08:35:38 -0800 (PST) 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 <0KBO00BL463D9SA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Dec 2008 08:35:37 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBAGZb3T026028 for ; Wed, 10 Dec 2008 08:35:37 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KBO0080158HLE00@fe-sfbay-09.sun.com> (original mail from Burt.Clouse@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Dec 2008 08:35:37 -0800 (PST) Received: from bernard-clouses-macbook.local ([67.188.114.52]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KBO00FEY63AL710@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Dec 2008 08:35:34 -0800 (PST) Date: Wed, 10 Dec 2008 08:35:34 -0800 From: B R Clouse Subject: Re: contract signatures for 2008/688 Sun Cluster TCP/IP Hooks Update In-reply-to: <18751.61179.411455.746343@gargle.gargle.HOWL> Sender: Burt.Clouse@sun.com To: PSARC-ext@sun.com Cc: Zhaozhou.Li@sun.com, Huafeng Lu , Burt Clouse , Honsing Cheng Message-id: <493FEFD6.7090906@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18742.44695.306474.37642@gargle.gargle.HOWL> <18751.61179.411455.746343@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) Status: RO Content-Length: 5718 I agree. -Burt Clouse Solaris Cluster James Carlson wrote: > In order to finish out this case, I'll need archived "signatures" from > each of the two managers on the 'to' line above. A "signature" is > just an email message saying "I agree," and the "reply-to" for this > message has been set to psarc-ext@sun.com, which is where they need to > go for archiving. > > A copy of the contract (for your review) is below. > > > > @(#)contract 1.8 @(#) /shared/sac/arc/ARC-Templates/contract [1.8 06/12/06] > > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: PSARC/2008/688-01 > > 1. This contract is between > a SUPPLIER of INTERFACES and > a CONSUMER of those INTERFACES, > both of whom are entities within Sun Microsystems, Incorporated. > > 2. The SUPPLIER (definer and/or implementor) is identified by the following: > Product or Bundle: Solaris > Consolidation: OS/Net > Department or Group: Networking > Bugster Product/Category/SubCategory: kernel/tcp-ip > Responsible Manager: Zhaozhou Li > > 3. The CONSUMER is identified by the following: > Product or Bundle: Sun Cluster > Consolidation: Sun Cluster > Department or Group: Sun Cluster > Bugster Product/Category/SubCategory: suncluster/suncluster/networking > Responsible Manager: Burt Clouse > > 4. The INTERFACES are: > > cl_inet_connect2 Project Private > cl_inet_isclusterwide Project Private > cl_inet_ipident Project Private > cl_inet_getspi Project Private > cl_inet_checkspi Project Private > cl_inet_deletespi Project Private > cl_inet_idlesa Project Private > cl_inet_listen Project Private > cl_inet_unlisten Project Private > cl_inet_disconnect Project Private > cl_tcp_walk_list Project Private > cl_inet_bind Project Private > cl_inet_unbind Project Private > > All are described in PSARC 2008/688. > > 5. The ARC controlling these INTERFACES is: PSARC > > 6. The CASE describing (Exporting) these INTERFACES is: 2008/688 > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > imposed by the stability levels listed in section 4 above: > > _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: > > Interfaces will be changed only on Minor release boundaries, > except for mutually agreed-on bug fixes. Changes can be > requested by either party, with the understanding that the > SUPPLIER can request resources from CONSUMER to implement > the changes. > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > > CONSUMER will perform regression tests and file bugs as > appropriate. > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > > The materials for this case are the only documentation supplied. > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > > CONSUMER shall perform integration testing. > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated as > follows: > > By mutual consent. > > 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 Kais.Belgaied@sun.com Wed Dec 10 09:22:17 2008 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 mBAHMHtG015524 for ; Wed, 10 Dec 2008 09:22:17 -0800 (PST) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBAHMBYC010527; Wed, 10 Dec 2008 09:22:14 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBO00B07892NM00@brm-avmta-1.central.sun.com>; Wed, 10 Dec 2008 10:22:14 -0700 (MST) Received: from jurassic-x4600.sfbay.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 <0KBO00934891RF20@brm-avmta-1.central.sun.com>; Wed, 10 Dec 2008 10:22:13 -0700 (MST) Received: from [129.146.11.146] (sr1-jurassic-03.SFBay.Sun.COM [129.146.11.146]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mBAHMCNr407211; Wed, 10 Dec 2008 09:22:13 -0800 (PST) Date: Wed, 10 Dec 2008 09:22:12 -0800 From: Kais Belgaied Subject: Re: 2008/688 Sun Cluster TCP/IP Hooks Update In-reply-to: <18742.44695.306474.37642@gargle.gargle.HOWL> To: James Carlson Cc: PSARC-ext@sun.com, Huafeng Lu Reply-to: Kais.Belgaied@sun.com Message-id: <493FFAC4.1040109@Sun.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 References: <18742.44695.306474.37642@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 441 On 12/03/08 08:06, James Carlson wrote: > I'm restarting the timer on this fast-track for Huafeng Lu and the Sun > Cluster team. The changes from the last go-around include removing > the version number string and adding a netstack ID and a flexible void > * argument for future expansion, and the contract (contract-01) has > been updated. The timer is set to 12/10/2008. > > > what about the Sun Cluster hooks for SCTP ? Kais. From carlsonj@phorcys.east.sun.com Wed Dec 10 09:32:20 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id mBAHWJdd015962 for ; Wed, 10 Dec 2008 09:32:20 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id mBAHWDCk008105; Thu, 11 Dec 2008 01:32:17 +0800 (SGT) 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 <0KBO00J1D8PRRY00@nwk-avmta-2.sfbay.sun.com>; Wed, 10 Dec 2008 09:32:15 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBO00DXA8PRDVB0@nwk-avmta-2.sfbay.sun.com>; Wed, 10 Dec 2008 09:32:15 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mBAHWEmF015549; Wed, 10 Dec 2008 12:32:14 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mBAHWEgO015546; Wed, 10 Dec 2008 12:32:14 -0500 (EST) Date: Wed, 10 Dec 2008 12:32:14 -0500 From: James Carlson Subject: Re: 2008/688 Sun Cluster TCP/IP Hooks Update In-reply-to: <493FFAC4.1040109@Sun.COM> To: Kais.Belgaied@sun.com Cc: PSARC-ext@sun.com Message-id: <18751.64798.857954.694742@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18742.44695.306474.37642@gargle.gargle.HOWL> <493FFAC4.1040109@Sun.COM> Status: RO Content-Length: 1032 Kais Belgaied writes: > On 12/03/08 08:06, James Carlson wrote: > > I'm restarting the timer on this fast-track for Huafeng Lu and the Sun > > Cluster team. The changes from the last go-around include removing > > the version number string and adding a netstack ID and a flexible void > > * argument for future expansion, and the contract (contract-01) has > > been updated. The timer is set to 12/10/2008. > > > > > > > > what about the Sun Cluster hooks for SCTP ? The specification sent out for review says this: talk to external servers. Note: this proposal only handles TCP and UDP; SCTP is beyond its scope. I assume that's a future project, if SCTP is to be supported within Sun Cluster at all. (Just like IPv6, it'd likely require non-trivial changes to the Sun Cluster code to do it.) -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Kais.Belgaied@sun.com Wed Dec 10 09:36:56 2008 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 mBAHauY7015989 for ; Wed, 10 Dec 2008 09:36:56 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBAHarSR025786; Wed, 10 Dec 2008 09:36:54 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KBO00C0J8XHZ600@brm-avmta-1.central.sun.com>; Wed, 10 Dec 2008 10:36:53 -0700 (MST) Received: from jurassic-x4600.sfbay.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 <0KBO009F98XFRS30@brm-avmta-1.central.sun.com>; Wed, 10 Dec 2008 10:36:51 -0700 (MST) Received: from [129.146.11.146] (sr1-jurassic-03.SFBay.Sun.COM [129.146.11.146]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mBAHapGT411646; Wed, 10 Dec 2008 09:36:51 -0800 (PST) Date: Wed, 10 Dec 2008 09:36:51 -0800 From: Kais Belgaied Subject: Re: 2008/688 Sun Cluster TCP/IP Hooks Update In-reply-to: <18751.64798.857954.694742@gargle.gargle.HOWL> To: James Carlson Cc: PSARC-ext@sun.com Reply-to: Kais.Belgaied@sun.com Message-id: <493FFE33.2080009@Sun.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 References: <18742.44695.306474.37642@gargle.gargle.HOWL> <493FFAC4.1040109@Sun.COM> <18751.64798.857954.694742@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.16 (X11/20080807) Status: RO Content-Length: 412 On 12/10/08 09:32, James Carlson wrote: > The specification sent out for review says this: > > talk to external servers. Note: this proposal only handles TCP and > UDP; SCTP is beyond its scope. > > I assume that's a future project, if SCTP is to be supported within > Sun Cluster at all. (Just like IPv6, it'd likely require non-trivial > changes to the Sun Cluster code to do it.) > OK. +1 Kais From carlsonj@phorcys.east.sun.com Wed Dec 10 10:08:44 2008 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 mBAI8iT6018419 for ; Wed, 10 Dec 2008 10:08:44 -0800 (PST) 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.2) with ESMTP id mBAI8f4u013653; Wed, 10 Dec 2008 11:08:42 -0700 (MST) 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 <0KBO00G07AEG9Z00@brm-avmta-1.central.sun.com>; Wed, 10 Dec 2008 11:08:40 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBO009GLAEFRT60@brm-avmta-1.central.sun.com>; Wed, 10 Dec 2008 11:08:39 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mBAI8dJl015856; Wed, 10 Dec 2008 13:08:39 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mBAI8diK015853; Wed, 10 Dec 2008 13:08:39 -0500 (EST) Date: Wed, 10 Dec 2008 13:08:39 -0500 From: James Carlson Subject: Re: 2008/688 Sun Cluster TCP/IP Hooks Update In-reply-to: <18742.44695.306474.37642@gargle.gargle.HOWL> To: PSARC-ext@sun.com Cc: Huafeng Lu Message-id: <18752.1447.53954.698217@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <18742.44695.306474.37642@gargle.gargle.HOWL> Status: RO Content-Length: 726 James Carlson writes: > I'm restarting the timer on this fast-track for Huafeng Lu and the Sun > Cluster team. The changes from the last go-around include removing > the version number string and adding a netstack ID and a flexible void > * argument for future expansion, and the contract (contract-01) has > been updated. The timer is set to 12/10/2008. This fast-track request was approved during ARC business at today's PSARC meeting. I'm leaving it open until I can gather contract signatures. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Zhaozhou.Li@sun.com Wed Dec 10 16:45:47 2008 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 mBB0jluU000005 for ; Wed, 10 Dec 2008 16:45:47 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mBB0jjRk034540 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 10 Dec 2008 17:45:46 -0700 (MST) 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 <0KBO00I0LSS9GW00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Dec 2008 16:45:45 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KBO00D3PSS7B420@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 10 Dec 2008 16:45:44 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBB0jhV6004290 for ; Thu, 11 Dec 2008 00:45:43 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0KBO00L01SOV6X00@mail-apac.sun.com> (original mail from Zhaozhou.Li@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 11 Dec 2008 08:45:43 +0800 (SGT) Received: from [10.13.21.10] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0KBO00MF7SS4VZ61@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 11 Dec 2008 08:45:42 +0800 (SGT) Date: Thu, 11 Dec 2008 08:42:23 +0800 From: Zhaozhou Li Subject: Re: contract signatures for 2008/688 Sun Cluster TCP/IP Hooks Update In-reply-to: <493FEFD6.7090906@sun.com> Sender: Zhaozhou.Li@sun.com To: B R Clouse Cc: PSARC-ext@sun.com, Huafeng Lu , Honsing Cheng Message-id: <494061EF.4030500@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <18742.44695.306474.37642@gargle.gargle.HOWL> <18751.61179.411455.746343@gargle.gargle.HOWL> <493FEFD6.7090906@sun.com> User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) Status: RO Content-Length: 5577 I agree, too. Zhaozhou Li Solaris Networking B R Clouse 写道: > > I agree. > > -Burt Clouse > Solaris Cluster > > > James Carlson wrote: >> In order to finish out this case, I'll need archived "signatures" from >> each of the two managers on the 'to' line above. A "signature" is >> just an email message saying "I agree," and the "reply-to" for this >> message has been set to psarc-ext@sun.com, which is where they need to >> go for archiving. >> >> A copy of the contract (for your review) is below. >> >> >> >> @(#)contract 1.8 @(#) /shared/sac/arc/ARC-Templates/contract [1.8 >> 06/12/06] >> >> CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES >> >> 0. Number: PSARC/2008/688-01 >> >> 1. This contract is between >> a SUPPLIER of INTERFACES and >> a CONSUMER of those INTERFACES, >> both of whom are entities within Sun Microsystems, Incorporated. >> >> 2. The SUPPLIER (definer and/or implementor) is identified by the >> following: >> Product or Bundle: Solaris >> Consolidation: OS/Net >> Department or Group: Networking >> Bugster Product/Category/SubCategory: kernel/tcp-ip >> Responsible Manager: Zhaozhou Li >> >> 3. The CONSUMER is identified by the following: >> Product or Bundle: Sun Cluster >> Consolidation: Sun Cluster >> Department or Group: Sun Cluster >> Bugster Product/Category/SubCategory: suncluster/suncluster/networking >> Responsible Manager: Burt Clouse >> >> 4. The INTERFACES are: >> >> cl_inet_connect2 Project Private >> cl_inet_isclusterwide Project Private >> cl_inet_ipident Project Private >> cl_inet_getspi Project Private >> cl_inet_checkspi Project Private >> cl_inet_deletespi Project Private >> cl_inet_idlesa Project Private >> cl_inet_listen Project Private >> cl_inet_unlisten Project Private >> cl_inet_disconnect Project Private >> cl_tcp_walk_list Project Private >> cl_inet_bind Project Private >> cl_inet_unbind Project Private >> >> All are described in PSARC 2008/688. >> >> 5. The ARC controlling these INTERFACES is: PSARC >> >> 6. The CASE describing (Exporting) these INTERFACES is: 2008/688 >> >> 7. The following SPECIAL ARRANGEMENTS are made which modify the rules >> imposed by the stability levels listed in section 4 above: >> >> _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: >> >> Interfaces will be changed only on Minor release boundaries, >> except for mutually agreed-on bug fixes. Changes can be >> requested by either party, with the understanding that the >> SUPPLIER can request resources from CONSUMER to implement >> the changes. >> >> 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as >> follows: >> >> CONSUMER will perform regression tests and file bugs as >> appropriate. >> >> 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as >> follows: >> >> The materials for this case are the only documentation supplied. >> >> 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be >> tested as follows: >> >> CONSUMER shall perform integration testing. >> >> 14. SUPPLIER and CONSUMER agree that this contract can be terminated as >> follows: >> >> By mutual consent. >> >> 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: >>