From kais@sac.sfbay.sun.com Tue Nov 11 11:57:19 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 mABJvJDR002731 for ; Tue, 11 Nov 2008 11:57:19 -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 mABJvHbx011659; Tue, 11 Nov 2008 11:57: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 <0KA60090RQ3I4M00@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Nov 2008 11:57:18 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KA6008NWQ3HR100@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Nov 2008 11:57:17 -0800 (PST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mABJvHsZ040599; Tue, 11 Nov 2008 11:57:17 -0800 (PST) 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 mABJvFlZ002726; Tue, 11 Nov 2008 11:57:15 -0800 (PST) Received: (from kais@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id mABJvFcJ002722; Tue, 11 Nov 2008 11:57:15 -0800 (PST) Date: Tue, 11 Nov 2008 11:57:15 -0800 (PST) From: Kais Belgaied Subject: Volo Interfaces Amendment [PSARC/2008/694 FastTrack timeout 11/18/2008] To: PSARC-ext@sun.com Cc: rao.shoaib@sun.com Message-id: <200811111957.mABJvFcJ002722@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2281 Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Volo Interfaces Amendment 1.2. Name of Document Author/Supplier: Author: Rao Shoaib 1.3 Date of This Document: 11 November, 2008 4. Technical Description I am sponsoring the following fast-track for Rao Shoaib and the Volo project team. This case is a collection of minor changes to the interfaces introduced by Project Volo PSARC/2007/587. This amendment does not affect the original minor release binding. All interfaces added by this amendment are Consolidation Private. The updated full Volo design document will be placed in the case directory. Below is a summary of the changes covered by this fasttrack. *) In the initial design a socket module writer was allowed to register it own sonodeops. This facility was deemed unnecessary and problematic. In the current design module writer registers only one create function that is called by the socket framework after allocating an sonode. *) Functions used in fallback are no longer part of the public upcalls and downcalls vector. Since fallback is supported only on native protocols it is handled via private function calls. There is no change in how fallback works. *) To support 3rd party socket modules two new downcalls sd_send_uio and sd_recv_uio have been introduced. These interfaces all protocol writer to control how data is copied to and from the user buffer. *) A new down call sd_poll has been introduced. This down call support polling when the protocol is doing it own buffering *) To support evolution the interface is versioned. Current versions are obtained via the macros SOCK_UC_VERSION (upcall interface) SOCK_DC_VERSION (downcall interface) *) /etc/sock2path now supports either a module name or a device name as the fourth member of the table. *) Two new socket options have been added SO_SNDTIMEO SO_RCVTIMEO both take a pointer to struct timeval and return EWOUBLOCK if the timer expires. 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 Tue Nov 11 12:31:24 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 mABKVNGI003416 for ; Tue, 11 Nov 2008 12:31:24 -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 mABKVFuV012982; Tue, 11 Nov 2008 20:31:21 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 <0KA600J0RRO6G600@brm-avmta-1.central.sun.com>; Tue, 11 Nov 2008 13:31:18 -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 <0KA6008I2RO5DUA0@brm-avmta-1.central.sun.com>; Tue, 11 Nov 2008 13:31:18 -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 mABKVGYv015815; Tue, 11 Nov 2008 15:31:16 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mABKVGFw015812; Tue, 11 Nov 2008 15:31:16 -0500 (EST) Date: Tue, 11 Nov 2008 15:31:16 -0500 From: James Carlson Subject: Re: Volo Interfaces Amendment [PSARC/2008/694 FastTrack timeout 11/18/2008] In-reply-to: <200811111957.mABJvFcJ002722@sac.sfbay.sun.com> To: Kais Belgaied Cc: PSARC-ext@sun.com, Rao.Shoaib@sun.com Message-id: <18713.60308.743747.90280@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: <200811111957.mABJvFcJ002722@sac.sfbay.sun.com> Status: RO Content-Length: 744 Kais Belgaied writes: > *) A new down call sd_poll has been introduced. This down call support > polling when the protocol is doing it own buffering Could we have a detail or two on that one? Does this work like poll(2), and how is it used? > *) Two new socket options have been added > SO_SNDTIMEO > SO_RCVTIMEO > both take a pointer to struct timeval and return EWOUBLOCK if the timer > expires. Setting the option doesn't return that error, but rather the corresponding read or write operation, right? -- 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 rao.shoaib@sun.com Tue Nov 11 12:40:46 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 mABKejjd003544 for ; Tue, 11 Nov 2008 12:40:46 -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 mABKedqb019292; Tue, 11 Nov 2008 20:40:44 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 <0KA600K03S3V5A00@brm-avmta-1.central.sun.com>; Tue, 11 Nov 2008 13:40:43 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KA600810S3UDYA0@brm-avmta-1.central.sun.com>; Tue, 11 Nov 2008 13:40:42 -0700 (MST) Received: from [129.146.106.54] (caduceus.SFBay.Sun.COM [129.146.106.54]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mABKegft353538; Tue, 11 Nov 2008 12:40:42 -0800 (PST) Date: Tue, 11 Nov 2008 12:42:53 -0800 From: Rao Shoaib Subject: Re: Volo Interfaces Amendment [PSARC/2008/694 FastTrack timeout 11/18/2008] In-reply-to: <18713.60308.743747.90280@gargle.gargle.HOWL> To: James Carlson Cc: Kais Belgaied , PSARC-ext@sun.com Message-id: <4919EE4D.4040307@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_KVlxBIN3rDj/ryLDd4doAw)" X-PMX-Version: 5.4.1.325704 References: <200811111957.mABJvFcJ002722@sac.sfbay.sun.com> <18713.60308.743747.90280@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 2663 This is a multi-part message in MIME format. --Boundary_(ID_KVlxBIN3rDj/ryLDd4doAw) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT James Carlson wrote: > Kais Belgaied writes: > >> *) A new down call sd_poll has been introduced. This down call support >> polling when the protocol is doing it own buffering >> > > Could we have a detail or two on that one? Does this work like > poll(2), and how is it used? > Yes from a user's perspective it works just like poll(2). Internally the socket framework calls the protocol registered function to get the poll events. >> *) Two new socket options have been added >> SO_SNDTIMEO >> SO_RCVTIMEO >> both take a pointer to struct timeval and return EWOUBLOCK if the timer >> expires. >> > > Setting the option doesn't return that error, but rather the > corresponding read or write operation, right? > Correct. Sorry about the wording. Let me know if you need more info. Thanks for the quick review. Rao. --Boundary_(ID_KVlxBIN3rDj/ryLDd4doAw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT James Carlson wrote: 
Kais Belgaied writes:
  
*) A new down call sd_poll has been introduced. This down call support
   polling when the protocol is doing it own buffering
    

Could we have a detail or two on that one?  Does this work like
poll(2), and how is it used?
Yes from a user's perspective it works just like poll(2). Internally the socket framework calls the protocol registered function to get the poll events.


*) Two new socket options have been added
	SO_SNDTIMEO
	SO_RCVTIMEO
   both take a pointer to struct timeval and return EWOUBLOCK if the timer
   expires.
    

Setting the option doesn't return that error, but rather the
corresponding read or write operation, right?
Correct. Sorry about the wording.

Let me know if you need more info.

Thanks for the quick review.

Rao.



--Boundary_(ID_KVlxBIN3rDj/ryLDd4doAw)-- From carlsonj@phorcys.east.sun.com Tue Nov 11 13:07:31 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 mABL7VvE004598 for ; Tue, 11 Nov 2008 13:07:31 -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 mABL7Ub8012271; Tue, 11 Nov 2008 13:07:30 -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 <0KA600M0DTCIEA00@brm-avmta-1.central.sun.com>; Tue, 11 Nov 2008 14:07:30 -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 <0KA6008IUTCHE1C0@brm-avmta-1.central.sun.com>; Tue, 11 Nov 2008 14:07:29 -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 mABL7SI9016129; Tue, 11 Nov 2008 16:07:28 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mABL7SGj016126; Tue, 11 Nov 2008 16:07:28 -0500 (EST) Date: Tue, 11 Nov 2008 16:07:28 -0500 From: James Carlson Subject: Re: Volo Interfaces Amendment [PSARC/2008/694 FastTrack timeout 11/18/2008] In-reply-to: <4919EE4D.4040307@sun.com> To: Rao Shoaib Cc: Kais Belgaied , PSARC-ext@sun.com Message-id: <18713.62480.484760.337471@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: <200811111957.mABJvFcJ002722@sac.sfbay.sun.com> <18713.60308.743747.90280@gargle.gargle.HOWL> <4919EE4D.4040307@sun.com> Status: RO Content-Length: 337 Rao Shoaib writes: > Let me know if you need more info. Nope; that's it. Just a couple of nits. +1 otherwise. -- 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 Darren.Reed@sun.com Tue Nov 11 13:44:34 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 mABLiXaY005779 for ; Tue, 11 Nov 2008 13:44:34 -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 mABLiIif019287 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Nov 2008 05:44:32 +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 <0KA600203V25PC00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Nov 2008 13:44:29 -0800 (PST) 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 <0KA600I1JV241570@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Nov 2008 13:44:28 -0800 (PST) Received: from fe-emea-10.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 mABLiRNG000119 for ; Tue, 11 Nov 2008 21:44:27 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KA600H01UWG0700@fe-emea-10.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Nov 2008 21:44:27 +0000 (GMT) Received: from [129.146.106.55] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KA6008YNV22J940@fe-emea-10.sun.com>; Tue, 11 Nov 2008 21:44:27 +0000 (GMT) Date: Tue, 11 Nov 2008 13:52:17 -0800 From: Darren Reed Subject: Re: Volo Interfaces Amendment [PSARC/2008/694 FastTrack timeout 11/18/2008] In-reply-to: <200811111957.mABJvFcJ002722@sac.sfbay.sun.com> Sender: Darren.Reed@sun.com To: Kais Belgaied Cc: PSARC-ext@sun.com, Rao.Shoaib@sun.com Message-id: <4919FE91.2050307@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: <200811111957.mABJvFcJ002722@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 992 On 11/11/08 11:57, Kais Belgaied wrote: > ... > *) In the initial design a socket module writer was allowed to register it own > sonodeops. This facility was deemed unnecessary and problematic. In the > current design module writer registers only one create function that is > called by the socket framework after allocating an sonode. > I'm used to seeing any API that offers a create hook/function also allow for a destroy (or similar.) Why isn't that necessary here? > *) To support 3rd party socket modules two new downcalls sd_send_uio and > sd_recv_uio have been introduced. These interfaces all protocol writer > to control how data is copied to and from the user buffer. > I'm not sure I understand the 2nd sentence there? > > *) To support evolution the interface is versioned. > Current versions are obtained via the macros > SOCK_UC_VERSION (upcall interface) > SOCK_DC_VERSION (downcall interface) > How do you expect these to be used? Darren From rao.shoaib@sun.com Tue Nov 11 14:12:03 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 mABMC2R9007493 for ; Tue, 11 Nov 2008 14:12:02 -0800 (PST) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mABMC163012193; Tue, 11 Nov 2008 14:12:01 -0800 (PST) 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 <0KA600501WC1P300@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Nov 2008 14:12:01 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KA600IASWC017B0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Nov 2008 14:12:00 -0800 (PST) Received: from [129.146.106.54] (caduceus.SFBay.Sun.COM [129.146.106.54]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mABMBaL7369242; Tue, 11 Nov 2008 14:11:42 -0800 (PST) Date: Tue, 11 Nov 2008 14:13:47 -0800 From: Rao Shoaib Subject: Re: Volo Interfaces Amendment [PSARC/2008/694 FastTrack timeout 11/18/2008] In-reply-to: <4919FE91.2050307@Sun.COM> To: Darren Reed Cc: Kais Belgaied , PSARC-ext@sun.com Message-id: <491A039B.2020705@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: <200811111957.mABJvFcJ002722@sac.sfbay.sun.com> <4919FE91.2050307@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 2117 Darren Reed wrote: > On 11/11/08 11:57, Kais Belgaied wrote: >> ... >> *) In the initial design a socket module writer was allowed to >> register it own >> sonodeops. This facility was deemed unnecessary and problematic. >> In the >> current design module writer registers only one create function >> that is >> called by the socket framework after allocating an sonode. >> > > I'm used to seeing any API that offers a create hook/function also > allow for a destroy (or similar.) Why isn't that necessary here? This is the entry point that is registered by the protocol. This call results in exchanging up and down calls. When a close occurs the close down call is called. > > >> *) To support 3rd party socket modules two new downcalls sd_send_uio and >> sd_recv_uio have been introduced. These interfaces all protocol >> writer >> to control how data is copied to and from the user buffer. >> > > I'm not sure I understand the 2nd sentence there? 3rd party implementations require control of copying in/out data as they may use special techniques unique to their HW. > >> >> *) To support evolution the interface is versioned. >> Current versions are obtained via the macros >> SOCK_UC_VERSION (upcall interface) >> SOCK_DC_VERSION (downcall interface) >> > > How do you expect these to be used? As the document says we are only providing hooks, we have not implemented the code to deal with backward compatibility. So this is how we envision it to work. When the socket module is loaded it registers with the socket framework, the create function, these two versions and an over all version number. These versions uniquely identify the up and downcalls on the system where the module was compiled (assuming that is what the module can support). The socket frame work can than verify if it supports these versions and if so those versions/implementation is used with the socket else the registration is failed. The over all version number will only be changed in the event of a major change that makes it impossible to support legacy modules. Rao. > > Darren From Darren.Reed@sun.com Tue Nov 11 14:51:32 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 mABMpWkF008832 for ; Tue, 11 Nov 2008 14:51:32 -0800 (PST) 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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id mABMpUhH029978 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 11 Nov 2008 14:51:32 -0800 (PST) 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 <0KA600A03Y5V1S00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Nov 2008 14:51:32 -0800 (PST) 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 <0KA600IQMY5V18D0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Nov 2008 14:51:31 -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 mABMpUVX005832 for ; Tue, 11 Nov 2008 22:51:30 +0000 (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 <0KA600401Y4XUQ00@fe-emea-09.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 11 Nov 2008 22:51:30 +0000 (GMT) Received: from [129.146.106.55] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KA600IGJY5NJ370@fe-emea-09.sun.com>; Tue, 11 Nov 2008 22:51:30 +0000 (GMT) Date: Tue, 11 Nov 2008 14:59:15 -0800 From: Darren Reed Subject: Re: Volo Interfaces Amendment [PSARC/2008/694 FastTrack timeout 11/18/2008] In-reply-to: <491A039B.2020705@sun.com> Sender: Darren.Reed@sun.com To: Rao Shoaib Cc: Kais Belgaied , PSARC-ext@sun.com Message-id: <491A0E43.1020306@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: <200811111957.mABJvFcJ002722@sac.sfbay.sun.com> <4919FE91.2050307@Sun.COM> <491A039B.2020705@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 1705 On 11/11/08 02:13 PM, Rao Shoaib wrote: >>> >>> *) To support evolution the interface is versioned. >>> Current versions are obtained via the macros >>> SOCK_UC_VERSION (upcall interface) >>> SOCK_DC_VERSION (downcall interface) >>> >> >> How do you expect these to be used? > As the document says we are only providing hooks, we have not > implemented the code to deal with backward compatibility. So this is > how we envision it to work. When the socket module is loaded it > registers with the socket framework, the create function, these two > versions and an over all version number. These versions uniquely > identify the up and downcalls on the system where the module was > compiled (assuming that is what the module can support). The socket > frame work can than verify if it supports these versions and if so > those versions/implementation is used with the socket else the > registration is failed. The over all version number will only be > changed in the event of a major change that makes it impossible to > support legacy modules. The only lingering question I have is whether or not the version is better where you've put it or in the structures for up/down calls themselves. In the new pdf, there appear to be other changes, such as those to su_newconn. Are those changes related to this case (and not mentioned) or are they relevant to some other feedback, in which case, can I ask for a PDF that is marked up with just changes related to this case? I suppose what I'm wondering is whether the list of changes in the email for the case was complete or whether we should consider that to be just the highlights and read the PDF for full discovery? Darren From rao.shoaib@sun.com Tue Nov 11 15:06:40 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 mABN6d76009450 for ; Tue, 11 Nov 2008 15:06:40 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mABN6ZqN022714; Tue, 11 Nov 2008 23:06:37 GMT 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 <0KA600B05YV0R200@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Nov 2008 15:06:36 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KA600BEAYUZ4500@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Nov 2008 15:06:35 -0800 (PST) Received: from [129.146.106.54] (caduceus.SFBay.Sun.COM [129.146.106.54]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mABN6218382485; Tue, 11 Nov 2008 15:06:08 -0800 (PST) Date: Tue, 11 Nov 2008 15:08:13 -0800 From: Rao Shoaib Subject: Re: Volo Interfaces Amendment [PSARC/2008/694 FastTrack timeout 11/18/2008] In-reply-to: <491A0E43.1020306@Sun.COM> To: Darren Reed Cc: Kais Belgaied , PSARC-ext@sun.com Message-id: <491A105D.6050405@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: <200811111957.mABJvFcJ002722@sac.sfbay.sun.com> <4919FE91.2050307@Sun.COM> <491A039B.2020705@sun.com> <491A0E43.1020306@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080630) Status: RO Content-Length: 2170 Darren Reed wrote: > On 11/11/08 02:13 PM, Rao Shoaib wrote: >>>> >>>> *) To support evolution the interface is versioned. >>>> Current versions are obtained via the macros >>>> SOCK_UC_VERSION (upcall interface) >>>> SOCK_DC_VERSION (downcall interface) >>>> >>> >>> How do you expect these to be used? >> As the document says we are only providing hooks, we have not >> implemented the code to deal with backward compatibility. So this is >> how we envision it to work. When the socket module is loaded it >> registers with the socket framework, the create function, these two >> versions and an over all version number. These versions uniquely >> identify the up and downcalls on the system where the module was >> compiled (assuming that is what the module can support). The socket >> frame work can than verify if it supports these versions and if so >> those versions/implementation is used with the socket else the >> registration is failed. The over all version number will only be >> changed in the event of a major change that makes it impossible to >> support legacy modules. > > The only lingering question I have is whether or not the version is > better where > you've put it or in the structures for up/down calls themselves. We want to fail the loading/registration of the module if it can not be supported. So the version numbers are needed at the time of registration. > > In the new pdf, there appear to be other changes, such as those to > su_newconn. > Are those changes related to this case (and not mentioned) or are they > relevant > to some other feedback, in which case, can I ask for a PDF that is > marked up > with just changes related to this case? > > I suppose what I'm wondering is whether the list of changes in the email > for the case was complete or whether we should consider that to be just > the highlights and read the PDF for full discovery? I have highlighted the architectural changes. If you want to look at changes such as a change to an argument to a call you need to look at the document. The document does have change bars and all the changes are related to this case. Rao. > > Darren From Kais.Belgaied@Sun.COM Wed Nov 12 11:14:26 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 mACJEQv2025665 for ; Wed, 12 Nov 2008 11:14:26 -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 mACJENTL026754; Wed, 12 Nov 2008 11:14:25 -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 <0KA80050FIRZ4Q00@brm-avmta-1.central.sun.com>; Wed, 12 Nov 2008 12:14:23 -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 <0KA8000FDIRY8F70@brm-avmta-1.central.sun.com>; Wed, 12 Nov 2008 12:14:23 -0700 (MST) Received: from [129.146.11.145] (sr1-jurassic-02.SFBay.Sun.COM [129.146.11.145]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mACJEMa4541750; Wed, 12 Nov 2008 11:14:22 -0800 (PST) Date: Wed, 12 Nov 2008 11:14:22 -0800 From: Kais Belgaied Subject: Re: Volo Interfaces Amendment [PSARC/2008/694 FastTrack timeout 11/18/2008] In-reply-to: <491A105D.6050405@sun.com> To: Rao Shoaib , PSARC-ext@Sun.COM Reply-to: Kais.Belgaied@Sun.COM Message-id: <491B2B0E.5020509@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: <200811111957.mABJvFcJ002722@sac.sfbay.sun.com> <4919FE91.2050307@Sun.COM> <491A039B.2020705@sun.com> <491A0E43.1020306@Sun.COM> <491A105D.6050405@sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 49 This case was approved in today's PSARC meeting.