From sacadmin Tue Feb 3 21:40:47 2009 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 n145el4n013126 for ; Tue, 3 Feb 2009 21:40:47 -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 n145elw7016205 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Tue, 3 Feb 2009 21:40:47 -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 <0KEJ0080F13XPX00@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 03 Feb 2009 21:40:45 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEJ006ZF13XKY10@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 03 Feb 2009 21:40:45 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n145ejb3007453 for ; Wed, 04 Feb 2009 05:40:45 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEJ00L000ZLX700@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 03 Feb 2009 22:40:45 -0700 (MST) Received: from aarti-pais-macbook-pro.local ([unknown] [76.21.4.117]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEJ00G2X13RN730@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 03 Feb 2009 22:40:41 -0700 (MST) Date: Tue, 03 Feb 2009 21:40:39 -0800 From: Aarti Pai Subject: [Fwd: Re: Hypervisor API Improvements for VPCI DMA Sync assigned to FWARC 2009/050] Sender: Aarti.Pai@sun.com To: fwarc@sun.com Cc: Charles.Kunzman@sun.com Message-id: <49892A57.9010100@Sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_CLpO6ljmZk8u6wL3s2OKIw)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 9114 This is a multi-part message in MIME format. --Boundary_(ID_CLpO6ljmZk8u6wL3s2OKIw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT FWARC Members, We are looking for a case owner. Any volunteers? Thanks, Aarti --Boundary_(ID_CLpO6ljmZk8u6wL3s2OKIw) Content-type: message/rfc822; name="Re: Hypervisor API Improvements for VPCI DMA Sync assigned to FWARC 2009/050.eml" Return-path: Received: from fe-amer-10.sun.com ([unknown] [192.18.109.80]) by amer4-mail1.central.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTP id <0KEI00A9VVJF4Q20@amer4-mail1.central.sun.com> for apai@amer4-mail1.Central.sun.com; Tue, 03 Feb 2009 20:40:27 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEI00700V7WSF00@mail-amer.sun.com> for apai@amer4-mail1.Central.sun.com (ORCPT apai@amer4-mail1.Central.sun.com); Tue, 03 Feb 2009 20:40:27 -0700 (MST) Received: from phys-amer4-2.central.sun.com ([unknown] [129.147.157.51]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTP id <0KEI00LR0VJFMED0@mail-amer.sun.com> for apai@amer4-mail1.Central.sun.com (ORCPT apai@amer4-mail1.Central.sun.com) ; Tue, 03 Feb 2009 20:40:27 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([unknown] [129.145.155.118]) by amer4-mail1.central.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTP id <0KEI00A9TVJF4Q20@amer4-mail1.central.sun.com> for apai@amer4-mail1.Central.sun.com; Tue, 03 Feb 2009 20:40:27 -0700 (MST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n143eRTr046179 for ; Tue, 03 Feb 2009 19:40:27 -0800 (PST) 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 n143eQ61018427 for ; Tue, 03 Feb 2009 19:40:26 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n143eQbS046174 for ; Tue, 03 Feb 2009 19:40:26 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n143eQTB005152 for ; Wed, 04 Feb 2009 03:40:26 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEI00A00VH5IB00@mail-amer.sun.com> for apai@sac.sfbay.sun.com; Tue, 03 Feb 2009 20:40:26 -0700 (MST) Received: from Macintosh-100.local ([unknown] [129.150.16.80]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEI005WHVJDKVA0@mail-amer.sun.com> for apai@sac.sfbay.sun.com; Tue, 03 Feb 2009 20:40:26 -0700 (MST) Date: Tue, 03 Feb 2009 19:40:27 -0800 From: Charles Kunzman Subject: Re: Hypervisor API Improvements for VPCI DMA Sync assigned to FWARC 2009/050 In-reply-to: <200901302201.n0UM1jYx009792@sac.sfbay.sun.com> Sender: Charles.Kunzman@Sun.COM To: Aarti Pai Message-id: <49890E2B.6070401@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200901302201.n0UM1jYx009792@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Original-recipient: rfc822;apai@amer4-mail1.Central.sun.com Hi Aarti, This is my first time going through the FWARC process. Does this mean we have a case owner assigned now or are we still waiting for the next FWARC meeting to occur for that to happen? We're trying to make a Solaris integration target soon, and I'd like to over the materials with the case owner as soon as possible. Charles Aarti Pai wrote, On 1/30/09 2:01 PM: > Invitation to Project Review (v1.41) Systems Architecture Council > > > Your project proposal one-pager has been assigned to FWARC. > > If your project requires a review, you should arrange to get > on the ARC's meeting schedule at your earliest convenience. > This review lets you present and discuss your project proposal. > SEE BELOW FOR IMPORTANT INSTRUCTIONS on how to do this. > > If your project is targeted at OpenSolaris, GNOME or any other > "open source" effort, and it does not contain materials that > would force it to remain proprietary, all the case materials > and related artifacts (including any email discussions) will > be exposed to people outside of Sun. Please discuss this > with your case owner or ARC Chair if you have questions. > > To remind you: > > Your One Pager proposal: 20090127_charles.kunzman > was archived as: http://sac.sfbay/Archives/Projects/2009/20090127_charles.kunzman > > ARC Case number is: FWARC/2009/050 > Your case's web page: http://sac.sfbay/arc/FWARC/2009/050/ > ARC members alias: FWARC@Sun.COM > ARC agenda alias: FWARC-agenda@Sun.COM > > As a result of this assignment, your project will be moved from the > "Recent Additions" project catalog to SAC's main project list: > > Recent Additions: http://sac.sfbay/cgi-bin/newprojects.pl > SAC Project list: http://sac.sfbay/Reports/proj_date.html > > Your case number and project proposal-id are important: They identify your > project, and allow SAC's tools to file information relating to your project > automatically. Use one of these in the Subject field of any e-mail > correspondence you send to any ARC member or mailing list. > > IMPORTANT INSTRUCTIONS: > The next steps for your project are: > > 1. Review the information about ARC Reviews found at > http://sac.sfbay/arc and http://sac.sfbay/arc/ARC-Review.html > > 2. If your project requires a review, get on the ARC's > schedule. This procedure varies based on the ARC you > are assigned to: > > PSARC: PSARC prefers that you get on their (relatively > full, but flexible) agenda first, and then > provide materials one week before the date. > LSARC: LSARC prefers that you submit materials first, > and then get on their (relatively open) > agenda. The final materials are due to LSARC 10 > days before the review date. > FWARC: FWARC prefers that you work with the case owner/intern > prior submitting your materials. ONLY case owner/intern > can request the agenda slot. Materials are due > a week before the review time. > WSARC: You can request an agenda time for WSARC to wsarc-agenda@sun, > then submit the materials 7 days before the review time. > SHARC: You can request an agenda time for SHARC to sharc-agenda@sun, > then submit the materials 7 days before the review time. > > All other ARCs: Ask your case owner. If you don't yet have > one, ask the ARC chair (FWARC-chair@eng). > > 3. Have your project's senior engineer(s) attend the > review meetings. > > A Preinception review is recommended for project teams > that have little or no experience with the ARC process, > or that used a one-pager to submit a fasttrack. The > only materials needed are the proposal you already > submitted, and consists of a 15 minute informal discussion > with the ARC. Please contact FWARC-coord@sun.com if > you would like to schedule a preinception review. > > An inception review (also called a prototype review) should > be scheduled after you have fleshed out your project but > before any substantive development work has started on it. > Its intent is to give direction, probe for problems, and > suggest areas for improvement. > > The inception review will identify needed changes, > specifications, and clarifications; it will also identify > the next ARC steps for the project, which range from > easy (approval on the spot), to usual (come back for an > additional commitment review when you have addressed open > issues), to hard (go back and start over: a rejection of > your proposed architecture). > > > Questions? > ---------- > If you have any questions, please contact the chairperson of the > ARC to which your project is assigned, or one of us: > > aarti.pai@sun.com UMPK16-250 x32945/(510) 315-5964 > -or- > sac-questions@sac.sfbay > > Remember to include your project-id (20090127_charles.kunzman) or > case number (FWARC/2009/050) in the subject field of *all* > e-mail you send to the ARC aliases relating to your project. This > allows our tools to file your correspondence in your case directory > automatically. > > Best Regards, > The Systems Architecture Council > http://sac.sfbay/ > > > --Boundary_(ID_CLpO6ljmZk8u6wL3s2OKIw)-- From sacadmin Tue Feb 3 22:28:43 2009 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 n146Sh3l015910 for ; Tue, 3 Feb 2009 22:28:43 -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 n146ShDa013499 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Tue, 3 Feb 2009 22:28:43 -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 <0KEJ00F013BVC400@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 03 Feb 2009 22:28:43 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEJ006WI3BVKW80@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 03 Feb 2009 22:28:43 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n146SgPE002342; Tue, 03 Feb 2009 22:28:42 -0800 (PST) Received: from [192.168.0.39] (noho.SFBay.Sun.COM [10.6.92.101]) by dtmail.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n146Sf1i017507; Tue, 03 Feb 2009 22:28:41 -0800 (PST) Date: Tue, 03 Feb 2009 22:28:47 -0800 From: David Kahn Subject: Re: [Fwd: Re: Hypervisor API Improvements for VPCI DMA Sync assigned to FWARC 2009/050] To: Aarti Pai , Charles.Kunzman@sun.com Cc: fwarc@sun.com Message-id: <4989359F.1020705@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 User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 130 I think this is just a fast-track. Charles, do you have an interface spec yet, or do you need assistance creating one? -David From sacadmin Tue Feb 3 22:58:56 2009 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 n146wtts017923 for ; Tue, 3 Feb 2009 22:58:55 -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 n146wshC003406 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Wed, 4 Feb 2009 06:58:54 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 <0KEJ00J034Q5K000@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 03 Feb 2009 22:58:53 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEJ006J24Q5L0D0@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 03 Feb 2009 22:58:53 -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 n146wrM2004447 for ; Wed, 04 Feb 2009 06:58:53 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEJ009004MLXT00@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 03 Feb 2009 23:58:53 -0700 (MST) Received: from Macintosh-100.local ([unknown] [129.150.18.147]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEJ00MFJ4Q4SI40@mail-amer.sun.com>; Tue, 03 Feb 2009 23:58:53 -0700 (MST) Date: Tue, 03 Feb 2009 22:58:53 -0800 From: Charles Kunzman Subject: Re: [Fwd: Re: Hypervisor API Improvements for VPCI DMA Sync assigned to FWARC 2009/050] In-reply-to: <4989359F.1020705@sun.com> Sender: Charles.Kunzman@sun.com To: David Kahn Cc: Aarti Pai , fwarc@sun.com Message-id: <49893CAD.7010407@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: <4989359F.1020705@sun.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 450 David Kahn wrote, On 2/3/09 10:28 PM: > > I think this is just a fast-track. > > Charles, do you have an interface spec yet, or do you > need assistance creating one? Yes, I had intended to do this as a fast-track request. I have a interface spec ready, but I was under the impression from the web pages that I was to go over it with a case owner prior to submitting it to the case materials. How should I proceed? Charles > > -David > From sacadmin Tue Feb 3 23:02:14 2009 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 n1472DYS018137 for ; Tue, 3 Feb 2009 23:02:13 -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 n1472B4Y005882 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Wed, 4 Feb 2009 07:02:12 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 <0KEJ00K034VO0Z00@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 03 Feb 2009 23:02:12 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEJ0069U4VOKWE0@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 03 Feb 2009 23:02:12 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n1472BUV020824; Tue, 03 Feb 2009 23:02:11 -0800 (PST) Received: from [192.168.0.39] (noho.SFBay.Sun.COM [10.6.92.101]) by dtmail.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1472ANA024247; Tue, 03 Feb 2009 23:02:10 -0800 (PST) Date: Tue, 03 Feb 2009 23:02:16 -0800 From: David Kahn Subject: Re: [Fwd: Re: Hypervisor API Improvements for VPCI DMA Sync assigned to FWARC 2009/050] In-reply-to: <49893CAD.7010407@sun.com> To: Charles Kunzman Cc: Aarti Pai , fwarc@sun.com Message-id: <49893D78.8010102@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: <4989359F.1020705@sun.com> <49893CAD.7010407@sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 590 > Yes, I had intended to do this as a fast-track request. I have a > interface spec ready, but I was under the impression from the web pages > that I was to go over > it with a case owner prior to submitting it to the case materials. How > should I proceed? Yes, you are correct. We will find you a case owner/sponsor and they will work with you to get your fast-track through the process. That's what Aarti is doing now. I just wanted to clarify that it was a fast-track, because that's less work for the case owner/sponsor than a full case. Thanks for the clarification. -David From sacadmin Thu Feb 5 08:53:59 2009 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 n15GrxP3001054 for ; Thu, 5 Feb 2009 08:53:59 -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 n15GrvIb050877 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 5 Feb 2009 09:53:59 -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 <0KEL00B0RQXYZL00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 05 Feb 2009 09:53:58 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KEL004IQQXXGYB0@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 05 Feb 2009 09:53:57 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n15GrvhE014660 for ; Thu, 05 Feb 2009 16:53:57 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KEL00D00QV2SB00@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 05 Feb 2009 09:53:57 -0700 (MST) Received: from aarti-pais-macbook-pro.local ([unknown] [129.150.35.151]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KEL00A4XQXTBP20@mail-amer.sun.com>; Thu, 05 Feb 2009 09:53:54 -0700 (MST) Date: Thu, 05 Feb 2009 08:53:55 -0800 From: Aarti Pai Subject: Re: [Fwd: Re: Hypervisor API Improvements for VPCI DMA Sync assigned to FWARC 2009/050] In-reply-to: <49893D78.8010102@sun.com> Sender: Aarti.Pai@sun.com To: David Kahn Cc: Charles Kunzman , fwarc@sun.com Message-id: <498B19A3.3070009@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: <4989359F.1020705@sun.com> <49893CAD.7010407@sun.com> <49893D78.8010102@sun.com> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) Status: RO Content-Length: 726 David Kahn wrote: > >> Yes, I had intended to do this as a fast-track request. I have a >> interface spec ready, but I was under the impression from the web >> pages that I was to go over >> it with a case owner prior to submitting it to the case materials. >> How should I proceed? > > Yes, you are correct. We will find you a case owner/sponsor > and they will work with you to get your fast-track through > the process. That's what Aarti is doing now. > > I just wanted to clarify that it was a fast-track, because > that's less work for the case owner/sponsor than a full > case. Thanks for the clarification. > > -David Folks - still waiting on a volunteer for this fast-track. Who will sponsor this case? Aarti From sacadmin Mon Feb 9 12:15:13 2009 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 n19KFDJu019966 for ; Mon, 9 Feb 2009 12:15:13 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n19KF3vh056575 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Mon, 9 Feb 2009 13:15:13 -0700 (MST) 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 <0KET00A0PEXBYK00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 09 Feb 2009 12:15:11 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KET007WWEX96M50@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 09 Feb 2009 12:15:09 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n19KF9CM018069 for ; Mon, 09 Feb 2009 20:15:09 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KET00C00C7LES00@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 09 Feb 2009 13:15:09 -0700 (MST) Received: from burl-legion-0 ([unknown] [10.8.28.177]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KET004ZYEX4CJ50@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Mon, 09 Feb 2009 13:15:04 -0700 (MST) Date: Mon, 09 Feb 2009 15:14:59 -0500 (EST) From: Tycho Nightingale Subject: Fast track FWARC/2009/050 - VPCI DMA sync flag Sender: Tycho.Nightingale@Sun.COM X-X-Sender: tychon@burl-legion-0 To: fwarc@Sun.COM Cc: Charles Kunzman Reply-to: Tycho Nightingale Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_RL4kmZ457QtowkA2RvEkIg)" X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 7491 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --Boundary_(ID_RL4kmZ457QtowkA2RvEkIg) Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT I am sponsoring this fast-track case for Charles.Kunzman. This case defines an HV API to add a flag to the existing VPCI DMA sync interface to support optomized cache flushing. See details in the attached one-pager. This case will be approved for minor/micro/patch OS binding and minor/micro binding for the firmware. The case timer is set to expire on February 17, 2009. Thanks. Tycho --Boundary_(ID_RL4kmZ457QtowkA2RvEkIg) Content-id: Content-type: TEXT/PLAIN; name=vpci_dma_sync-onepager.txt; charset=US-ASCII Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=vpci_dma_sync-onepager.txt Content-description: Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Hypervisor API Improvements for VPCI DMA Sync 1.2. Name of Document Author/Supplier: Charles Kunzman (Charles.Kunzman@sun.com) 1.3. Date of This Document: 01/31/09 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: N/A 1.4.2. The ARC(s) you expect to review your project: FWARC 1.4.3. The Director/VP who is "Sponsoring" this project: Ravi Subbarao (Ravi.Subbaro@sun.com) 1.4.4. The name of your business unit: Systems - Enterprise Software 1.5. Email Aliases: 1.5.1. Responsible Manager: Umesh.Sharma@sun.com 1.5.2. Responsible Engineer: Charles.Kunzman@sun.com 1.5.3. Marketing Manager: N/A 1.5.4. Interest List: hvrock-dev@sun.com 2. Project Summary 2.1. Project Description: This project adds a new flag to the existing VPCI DMA sync interface to support optimized cache flushing. 2.2. Risks and Assumptions: None. 3. Business Summary 3.1. Problem Area: Most data loaded through DMA I/O is not intended for execution by the guest Operating System. Flushing the instruction cache for most DMA operations is therefore an unnecessary hit on the cache efficiency. The PCI DMA sync interface needs to be updated to allow for optimized exclusion of instruction cache flushing. 3.2. Market/Requester: Enterprise Systems 3.3. Business Justification: This new API function is required in order to provide the best possible system performance on upcoming UltraSPARC based system products. 3.4. Competitive Analysis: N/A. 3.5. Opportunity Window/Exposure: N/A. 3.6. How will you know when you are done?: The project is complete when the API is implemented and tested according to the spec in this document on hardware supporting the underlying capability. 4. Technical Description: 4.1. Details: The sun4v PCI hypercall interfaces include a function that is required to be called after the completion of any DMA access to memory before the data there can be safely used. The purpose of this interface is to allow sun4v processors with non-coherent caches the opportunity to flush any required caches prior to accessing the data. Since most data loaded via DMA is not intended to be executed, it is inefficient to flush the instruction cache for every DMA transaction. However, since only the guest has knowledge of which regions are intended to contain executable data, the pci_dma_sync interface must be updated to allow the guest to indicate this to the hypervisor. 4.1.1. API specification: The project proposes to change the io_sync_direction argument of the pci_dma_sync hypercall to a sync_flags argument. The sync_flags argument includes the following single bit flag values: 0x01 - For device (device read from memory) 0x02 - For cpu (device write to memory) 0x04 - No instruction cache synchronization required The change will be implemented as a new minor version to the PCI function group. The new minor version number must be negotiated by the guest to use the new flags assignments. 4.1.2. API function call summary: #Name Group# Trap# Func# Major# Minor# #==== ====== ===== ===== ====== ====== PCI_DMA_SYNC 0x100 0x80 0xb8 1 1 4.1.3. trap: FAST_TRAP function: PCI_DMA_SYNC arg0: devhandle arg1: r_adddr arg2: size arg3: sync_flags ret0: status Synchronize a memory region described by the arguments r_addr, size for the device defined by the argument devhandle using the direction(s) defined by the argument sync_flags. The argument size is the size of the memory region in bytes. If the region does not contain data which will be executed, the guest may optionally include a flag to indicate that no instruction cache flushing is required. Using this flag and later executing instructions from the region has undefined results. Return the actual number of bytes synchronized in the return value #synced, which may be less than or equal to the argument size. If the return value #synced is less than size, the caller must continue to call this function with updated r_addr and size arguments until the entire memory region is synchronized. Errors: EINVAL invalid devhandle or sync_flags ENORADDR bad r_addr 4.2. Bug/RFE Number(s): N/A 4.3. In Scope: N/A 4.4. Out of Scope: N/A 4.5. Interfaces: 4.5.1. Imported Interfaces: Interface Classification Comments ==================================================================== sun4v I/O API Sun Private I/O APIs defined by FWARC/2005/112 4.5.2. Exported Interfaces: Interface Classification Comments ==================================================================== PCI_DMA_SYNC Commmitted API call 4.6. Doc Impact: The UltraSPARC Virtual Machine Specification must be updated to reflect this addition. 4.7. Admin/Config Impact: No impact. 4.8. HA Impact: No impact. 4.9. I18N/L10N Impact: No impact. 4.10. Packaging & Delivery: No impact. 4.11. Security Impact: No impact. 4.12. Dependencies: No benefit will be seen on platforms which do not have non-coherent instruction cache or which do not have a separate instruction cache. 5. Reference Documents: UltraSPARC Architecture 2007 Specification http://opensparc-t2.sunsource.net/specs/UA2007-current-draft-HP-EXT.pdf UltraSPARC Virtual Machine Specification http://opensparc-t1.sunsource.net/specs/Hypervisor-api-current-draft.pdf 6. Resources and Schedule: 6.1. Projected Availability: (redacted) 6.2. Cost of Effort: (redacted) 6.3. Cost of Capital Resources: (redacted) 6.4. Product Approval Committee requested information: N/A. 6.4.1. Consolidation or Component Name: 6.4.3. Type of CPT Review and Approval expected: 6.4.4. Project Boundary Conditions: 6.4.5. Is this a necessary project for OEM agreements: 6.4.6. Notes: 6.4.7. Target RTI Date/Release: 6.4.8. Target Code Design Review Date: 6.4.9. Update approval addition: 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 6.6.1. Rationale: 7. Prototype Availability: 7.1. Prototype Availability: The changes have been prototyped and tested in the bringup lab releases for Solaris and HV. 7.2. Prototype Cost: N/A. Prototype is already completed. --Boundary_(ID_RL4kmZ457QtowkA2RvEkIg)-- From sacadmin Wed Feb 18 18:25:39 2009 Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n1J2Pdse028194 for ; Wed, 18 Feb 2009 18:25:39 -0800 (PST) Received: from [192.168.0.39] (noho.SFBay.Sun.COM [10.6.92.101]) by dtmail.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n1J2PYKU027477; Wed, 18 Feb 2009 18:25:34 -0800 (PST) Message-ID: <499CC324.2020902@sun.com> Date: Wed, 18 Feb 2009 18:25:40 -0800 From: David Kahn User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Tycho Nightingale , Charles Kunzman CC: FWARC@sac.sfbay.sun.com Subject: 2009/050 - derail Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 535 I'm derailing this case. The io_sync_direction is defined as a value, not a flag. That, in itself, may be a mistake in the initial spec, and if it is, this case can fix it. The version numbers are messed up also. api version 1.1 already exists for group 0x100. There's no update to the io api spec. This case needs more work. Sorry, I thought it was trivial but I think Tayfun caught it during the code review and I took another look at it. Once this stuff is worked it, it can be probably be re-railed as a fast-track. -David From sacadmin Mon Mar 9 11:29:45 2009 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 n29ITjYa007807 for ; Mon, 9 Mar 2009 11:29:45 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n29ITjIr061385 for ; Mon, 9 Mar 2009 11:29:45 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n29ITi0J025698 for ; Mon, 9 Mar 2009 18:29:44 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KG900F004E0FV00@mail-amer.sun.com> for FWARC@sac.sfbay.sun.com; Mon, 09 Mar 2009 12:29:44 -0600 (MDT) Received: from burl-legion-0 ([unknown] [10.8.28.177]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KG9003JX4PBLKB0@mail-amer.sun.com>; Mon, 09 Mar 2009 12:29:35 -0600 (MDT) Date: Mon, 09 Mar 2009 14:29:20 -0400 (EDT) From: Tycho Nightingale Subject: Re: 2009/050 - derail In-reply-to: <499CC324.2020902@sun.com> Sender: Tycho.Nightingale@Sun.COM X-X-Sender: tychon@burl-legion-0 To: FWARC@sac.sfbay.sun.com Cc: Charles Kunzman , David Kahn Reply-to: Tycho Nightingale Message-id: References: <499CC324.2020902@sun.com> Status: RO Content-Length: 1008 On Wed, 18 Feb 2009, David Kahn wrote: > I'm derailing this case. > > The io_sync_direction is defined as a value, > not a flag. That, in itself, may be a mistake > in the initial spec, and if it is, this case > can fix it. > > The version numbers are messed up also. > api version 1.1 already exists for group 0x100. > > There's no update to the io api spec. > > This case needs more work. Sorry, I thought it > was trivial but I think Tayfun caught it during > the code review and I took another look at it. > > Once this stuff is worked it, it can be probably > be re-railed as a fast-track. I'm bringing this case back online as a fast-track. Charles has updated the io-api spec to reflect the new io_sync attributes versus flag usage available as part of group 0x100 1.2. An updated copy is in the materials directory. The one-pager, also in the materials directory, now reflects major 1 minor 2 for the new attributes change as well. The case timer is set to expire on March 16, 2009. Tycho From sacadmin Mon Mar 16 11:36:04 2009 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 n2GIa4ms005409 for ; Mon, 16 Mar 2009 11:36:04 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2GIa336045785 for ; Mon, 16 Mar 2009 11:36:03 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n2GIZwvY003287 for ; Mon, 16 Mar 2009 11:35:58 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; format=flowed; charset=ISO-8859-1 Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KGM0080037P7R00@fe-sfbay-10.sun.com> for FWARC@sac.sfbay.sun.com; Mon, 16 Mar 2009 11:35:58 -0700 (PDT) Received: from [129.150.32.202] ([unknown] [129.150.32.202]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KGM00AWY3NVRK90@fe-sfbay-10.sun.com>; Mon, 16 Mar 2009 11:35:57 -0700 (PDT) Date: Mon, 16 Mar 2009 11:35:56 -0700 From: Hitendra Zhangada Subject: Re: 2009/050 - derail In-reply-to: Sender: Hitendra.Zhangada@Sun.COM To: Tycho Nightingale Cc: FWARC@sac.sfbay.sun.com, Charles Kunzman , David Kahn Message-id: <49BE9C0C.3050005@sun.com> References: <499CC324.2020902@sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 2130 Tycho Nightingale wrote: > > On Wed, 18 Feb 2009, David Kahn wrote: > >> I'm derailing this case. >> >> The io_sync_direction is defined as a value, >> not a flag. That, in itself, may be a mistake >> in the initial spec, and if it is, this case >> can fix it. >> >> The version numbers are messed up also. >> api version 1.1 already exists for group 0x100. >> >> There's no update to the io api spec. >> >> This case needs more work. Sorry, I thought it >> was trivial but I think Tayfun caught it during >> the code review and I took another look at it. >> >> Once this stuff is worked it, it can be probably >> be re-railed as a fast-track. > > I'm bringing this case back online as a fast-track. > > Charles has updated the io-api spec to reflect the new io_sync > attributes versus flag usage available as part of group 0x100 1.2. An > updated copy is in the materials directory. > > The one-pager, also in the materials directory, now reflects major 1 > minor 2 for the new attributes change as well. > > The case timer is set to expire on March 16, 2009. > Can we update the io-api.txt specification such that the document itself have proper versioning? The document starts out as "changes in this version" which led me to think that all of the changes listed there are part of the changes for this case. But later I found out that the list of changes is carried over from the prior version of the io-api.txt from 2006/474. I suggest something as follows, Changes in this version : Changes in prior versions : Ideally, we can have version by version deltas but that may be too much work and so something as simple as what I proposing would work. The commitment level for the io-api.txt itself is Sun Private and so wouldn't the amendments inherit that instead of "committed" as stated in the one-pager? -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Systems Group, Sun Microsystems, Inc. From sacadmin Mon Mar 16 12:46:25 2009 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 n2GJkPdo029959 for ; Mon, 16 Mar 2009 12:46:25 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2GJkPFk039395 for ; Mon, 16 Mar 2009 12:46:25 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2GJkP8R006105 for ; Mon, 16 Mar 2009 19:46:25 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; format=flowed; charset=ISO-8859-1 Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KGM00G005VQRR00@mail-amer.sun.com> for FWARC@sac.sfbay.sun.com; Mon, 16 Mar 2009 13:46:25 -0600 (MDT) Received: from Macintosh-100.local ([unknown] [129.150.19.240]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KGM00AZ26X7RV00@mail-amer.sun.com>; Mon, 16 Mar 2009 13:46:20 -0600 (MDT) Date: Mon, 16 Mar 2009 12:46:15 -0700 From: Charles Kunzman Subject: Re: 2009/050 - derail In-reply-to: <49BE9C0C.3050005@sun.com> Sender: Charles.Kunzman@Sun.COM To: Hitendra Zhangada Cc: Tycho Nightingale , FWARC@sac.sfbay.sun.com, David Kahn Message-id: <49BEAC87.4000800@sun.com> References: <499CC324.2020902@sun.com> <49BE9C0C.3050005@sun.com> User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) Status: RO Content-Length: 2424 Hitendra Zhangada wrote, On 3/16/09 11:35 AM: > Tycho Nightingale wrote: >> >> On Wed, 18 Feb 2009, David Kahn wrote: >> >>> I'm derailing this case. >>> >>> The io_sync_direction is defined as a value, >>> not a flag. That, in itself, may be a mistake >>> in the initial spec, and if it is, this case >>> can fix it. >>> >>> The version numbers are messed up also. >>> api version 1.1 already exists for group 0x100. >>> >>> There's no update to the io api spec. >>> >>> This case needs more work. Sorry, I thought it >>> was trivial but I think Tayfun caught it during >>> the code review and I took another look at it. >>> >>> Once this stuff is worked it, it can be probably >>> be re-railed as a fast-track. >> >> I'm bringing this case back online as a fast-track. >> >> Charles has updated the io-api spec to reflect the new io_sync >> attributes versus flag usage available as part of group 0x100 1.2. >> An updated copy is in the materials directory. >> >> The one-pager, also in the materials directory, now reflects major 1 >> minor 2 for the new attributes change as well. >> >> The case timer is set to expire on March 16, 2009. >> > > Can we update the io-api.txt specification such that the document > itself have proper versioning? The document starts out as "changes > in this version" which led me to think that all of the changes listed > there are part of the changes for this case. But later I found out > that the list of changes is carried over from the prior version of > the io-api.txt from 2006/474. I suggest something as follows, > > Changes in this version : > > > > Changes in prior versions : > > > > > Ideally, we can have version by version deltas but that > may be too much work and so something as simple as > what I proposing would work. Hitendra, The changes in the API document are already organized this way. The changes listed as "in this version" represent the changes from the 1.33->1.34 revision. As part of the discussion about implementing the 1.2 minor version, questions came up regarding the 1.1 version and we decided to add additional clarifications to the document while updating it. Charles > > > The commitment level for the io-api.txt itself is Sun Private > and so wouldn't the amendments inherit that instead of > "committed" as stated in the one-pager? > > From sacadmin Mon Mar 16 13:24:52 2009 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 n2GKOp5c002025 for ; Mon, 16 Mar 2009 13:24:51 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2GKOppp003399 for ; Mon, 16 Mar 2009 13:24:51 -0700 (PDT) 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 n2GKOkgV018288 for ; Mon, 16 Mar 2009 13:24:46 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; format=flowed; charset=ISO-8859-1 Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KGM007008HXPN00@fe-sfbay-09.sun.com> for FWARC@sac.sfbay.sun.com; Mon, 16 Mar 2009 13:24:46 -0700 (PDT) Received: from [129.150.32.202] ([unknown] [129.150.32.202]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KGM001L58P5V6F0@fe-sfbay-09.sun.com> for FWARC@sac.sfbay.sun.com; Mon, 16 Mar 2009 13:24:43 -0700 (PDT) Date: Mon, 16 Mar 2009 13:24:42 -0700 From: Hitendra Zhangada Subject: Re: 2009/050 - derail In-reply-to: <49BEAC87.4000800@sun.com> Sender: Hitendra.Zhangada@Sun.COM To: Charles Kunzman Cc: Tycho Nightingale , FWARC@sac.sfbay.sun.com Message-id: <49BEB58A.3010909@sun.com> References: <499CC324.2020902@sun.com> <49BE9C0C.3050005@sun.com> <49BEAC87.4000800@sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 3095 Charles Kunzman wrote: > > > Hitendra Zhangada wrote, On 3/16/09 11:35 AM: >> Tycho Nightingale wrote: >>> >>> On Wed, 18 Feb 2009, David Kahn wrote: >>> >>>> I'm derailing this case. >>>> >>>> The io_sync_direction is defined as a value, >>>> not a flag. That, in itself, may be a mistake >>>> in the initial spec, and if it is, this case >>>> can fix it. >>>> >>>> The version numbers are messed up also. >>>> api version 1.1 already exists for group 0x100. >>>> >>>> There's no update to the io api spec. >>>> >>>> This case needs more work. Sorry, I thought it >>>> was trivial but I think Tayfun caught it during >>>> the code review and I took another look at it. >>>> >>>> Once this stuff is worked it, it can be probably >>>> be re-railed as a fast-track. >>> >>> I'm bringing this case back online as a fast-track. >>> >>> Charles has updated the io-api spec to reflect the new io_sync >>> attributes versus flag usage available as part of group 0x100 1.2. >>> An updated copy is in the materials directory. >>> >>> The one-pager, also in the materials directory, now reflects major 1 >>> minor 2 for the new attributes change as well. >>> >>> The case timer is set to expire on March 16, 2009. >>> >> >> Can we update the io-api.txt specification such that the document >> itself have proper versioning? The document starts out as "changes >> in this version" which led me to think that all of the changes listed >> there are part of the changes for this case. But later I found out >> that the list of changes is carried over from the prior version of >> the io-api.txt from 2006/474. I suggest something as follows, >> >> Changes in this version : >> >> >> >> Changes in prior versions : >> >> >> >> >> Ideally, we can have version by version deltas but that >> may be too much work and so something as simple as >> what I proposing would work. > Hitendra, > > The changes in the API document are already organized this way. > The changes listed as "in this version" represent the changes from the > 1.33->1.34 revision. As part of the discussion about implementing the > 1.2 minor version, questions came up regarding the 1.1 version and we > decided to add additional clarifications to the document while > updating it. My bad, I missed that the first time I went through the document. Thanks for pointing that out. The specification looks good to me but I would like to get answer to my question related to the interface classification below. >> >> >> The commitment level for the io-api.txt itself is Sun Private >> and so wouldn't the amendments inherit that instead of >> "committed" as stated in the one-pager? Actually, we may want to make entire IO API committed instead of Sun Private. Is there a reason to keep the IO APIs Sun Private? > > -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Systems Group, Sun Microsystems, Inc. From sacadmin Thu Mar 19 06:07:52 2009 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 n2JD7qJR018828 for ; Thu, 19 Mar 2009 06:07:52 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2JD7qIr029839 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 19 Mar 2009 06:07:52 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KGR0060D8H4N200@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 19 Mar 2009 06:07:52 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KGR000OT8H31J80@nwk-avmta-1.sfbay.Sun.COM> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 19 Mar 2009 06:07:51 -0700 (PDT) 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 n2JD7p84021630 for ; Thu, 19 Mar 2009 13:07:51 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KGR0090085MEL00@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 19 Mar 2009 07:07:51 -0600 (MDT) Received: from burl-legion-0 ([unknown] [10.8.28.177]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KGR00BBE8GWFMG0@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 19 Mar 2009 07:07:45 -0600 (MDT) Date: Thu, 19 Mar 2009 09:07:44 -0400 (EDT) From: Tycho Nightingale Subject: Re: 2009/050 - derail In-reply-to: Sender: Tycho.Nightingale@Sun.COM X-X-Sender: tychon@burl-legion-0 To: fwarc@Sun.COM Cc: Charles Kunzman Reply-to: Tycho Nightingale Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <499CC324.2020902@sun.com> Status: RO Content-Length: 1160 On Mon, 9 Mar 2009, Tycho Nightingale wrote: > On Wed, 18 Feb 2009, David Kahn wrote: > >> I'm derailing this case. >> >> The io_sync_direction is defined as a value, >> not a flag. That, in itself, may be a mistake >> in the initial spec, and if it is, this case >> can fix it. >> >> The version numbers are messed up also. >> api version 1.1 already exists for group 0x100. >> >> There's no update to the io api spec. >> >> This case needs more work. Sorry, I thought it >> was trivial but I think Tayfun caught it during >> the code review and I took another look at it. >> >> Once this stuff is worked it, it can be probably >> be re-railed as a fast-track. > > I'm bringing this case back online as a fast-track. > > Charles has updated the io-api spec to reflect the new io_sync attributes > versus flag usage available as part of group 0x100 1.2. An updated copy is > in the materials directory. > > The one-pager, also in the materials directory, now reflects major 1 minor 2 > for the new attributes change as well. > > The case timer is set to expire on March 16, 2009. The case timer has expired. The case is approved and closed. Tycho From sacadmin Thu Mar 19 09:28:00 2009 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 n2JGRxsH029344 for ; Thu, 19 Mar 2009 09:28:00 -0700 (PDT) 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 n2JGRu5q021818 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 19 Mar 2009 16:27:59 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 <0KGR00A0DHQMXR00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 19 Mar 2009 10:27:58 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KGR00K0LHQL3CD0@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 19 Mar 2009 10:27:57 -0600 (MDT) 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 n2JGRvFE006612 for ; Thu, 19 Mar 2009 09:27:57 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KGR00400GHZQC00@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 19 Mar 2009 09:27:57 -0700 (PDT) Received: from [129.150.37.149] ([unknown] [129.150.37.149]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KGR005IPHQ605H0@fe-sfbay-10.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 19 Mar 2009 09:27:47 -0700 (PDT) Date: Thu, 19 Mar 2009 09:27:41 -0700 From: Hitendra Zhangada Subject: Re: 2009/050 - derail In-reply-to: Sender: Hitendra.Zhangada@sun.com To: Tycho Nightingale Cc: fwarc@sun.com, Charles Kunzman Message-id: <49C2727D.3060601@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: <499CC324.2020902@sun.com> User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) Status: RO Content-Length: 1622 Tycho Nightingale wrote: > > On Mon, 9 Mar 2009, Tycho Nightingale wrote: > >> On Wed, 18 Feb 2009, David Kahn wrote: >> >>> I'm derailing this case. >>> >>> The io_sync_direction is defined as a value, >>> not a flag. That, in itself, may be a mistake >>> in the initial spec, and if it is, this case >>> can fix it. >>> >>> The version numbers are messed up also. >>> api version 1.1 already exists for group 0x100. >>> >>> There's no update to the io api spec. >>> >>> This case needs more work. Sorry, I thought it >>> was trivial but I think Tayfun caught it during >>> the code review and I took another look at it. >>> >>> Once this stuff is worked it, it can be probably >>> be re-railed as a fast-track. >> >> I'm bringing this case back online as a fast-track. >> >> Charles has updated the io-api spec to reflect the new io_sync >> attributes versus flag usage available as part of group 0x100 1.2. >> An updated copy is in the materials directory. >> >> The one-pager, also in the materials directory, now reflects major 1 >> minor 2 for the new attributes change as well. >> >> The case timer is set to expire on March 16, 2009. > > The case timer has expired. The case is approved and closed. Yes, timer has expired but my questions related to interface classification has not been answered. Can we settle on this please? Did you get those mails from me? Thanks. > > Tycho -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Systems Group, Sun Microsystems, Inc. From sacadmin Thu Mar 19 09:48:10 2009 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 n2JGm9S0000707 for ; Thu, 19 Mar 2009 09:48:09 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n2JGluq1006511 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 19 Mar 2009 16:48:08 GMT 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 <0KGR00L1XIO6V400@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 19 Mar 2009 09:48:06 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KGR00GHMIO3Q0A0@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 19 Mar 2009 09:48:03 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2JGm3Ew011339 for ; Thu, 19 Mar 2009 16:48:03 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KGR00M00GWTGM00@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 19 Mar 2009 10:48:03 -0600 (MDT) Received: from burl-legion-0 ([unknown] [10.8.28.177]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KGR001Y9IO2NH40@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 19 Mar 2009 10:48:03 -0600 (MDT) Date: Thu, 19 Mar 2009 12:48:02 -0400 (EDT) From: Tycho Nightingale Subject: Re: 2009/050 - derail In-reply-to: <49C2727D.3060601@sun.com> Sender: Tycho.Nightingale@sun.com X-X-Sender: tychon@burl-legion-0 To: Hitendra Zhangada Cc: fwarc@sun.com, Charles Kunzman Reply-to: Tycho Nightingale Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <499CC324.2020902@sun.com> <49C2727D.3060601@sun.com> Status: RO Content-Length: 746 On Thu, 19 Mar 2009, Hitendra Zhangada wrote: > Yes, timer has expired but my questions related to interface > classification has not been answered. Can we settle on this please? > > Did you get those mails from me? Yes, I got the emails. Yes, there was a ton of offline discussion about the change Charles was proposing and yes that caused the entire IO API to unfairly undergo additional scrutiny. As Charles wasn't asking to have the entire IO API (re)reviewed, he simply wanted to focus on one tiny bit, to expedite matters, I moved this case along. If that wasn't the right, approach, sorry. At this point, there appears to be another change to the IO API in flight. Perhaps that is the time to address further issues. Tycho From sacadmin Thu Mar 19 10:10:29 2009 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 n2JHATQK002406 for ; Thu, 19 Mar 2009 10:10:29 -0700 (PDT) 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 n2JHATbO029849 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Thu, 19 Mar 2009 10:10:29 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KGR00M3ZJPHUQ00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 19 Mar 2009 10:10:29 -0700 (PDT) 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 <0KGR00GN6JPFPTA0@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 19 Mar 2009 10:10:27 -0700 (PDT) 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 n2JHARqa016626 for ; Thu, 19 Mar 2009 10:10:27 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KGR00F00IIYVS00@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 19 Mar 2009 10:10:27 -0700 (PDT) Received: from [129.150.37.149] ([unknown] [129.150.37.149]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KGR004IHJP41YG0@fe-sfbay-09.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Thu, 19 Mar 2009 10:10:17 -0700 (PDT) Date: Thu, 19 Mar 2009 10:10:15 -0700 From: Hitendra Zhangada Subject: Re: 2009/050 - derail In-reply-to: Sender: Hitendra.Zhangada@sun.com To: fwarc@sun.com Cc: Charles Kunzman Message-id: <49C27C77.7030106@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: <499CC324.2020902@sun.com> <49C2727D.3060601@sun.com> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 1322 Tycho Nightingale wrote: > > On Thu, 19 Mar 2009, Hitendra Zhangada wrote: > >> Yes, timer has expired but my questions related to interface >> classification has not been answered. Can we settle on this please? >> >> Did you get those mails from me? > > Yes, I got the emails. Yes, there was a ton of offline discussion > about the change Charles was proposing and yes that caused the entire > IO API to unfairly undergo additional scrutiny. > > As Charles wasn't asking to have the entire IO API (re)reviewed, he > simply wanted to focus on one tiny bit, to expedite matters, I moved > this case along. I have not problems with moving ahead with the case as fast track or getting it approved. Actually, I did say it LGTM in my mail. My only concern is the use of interface classification. The interface is fine but the classification of it is where I want to have some discussions. Thanks. > > If that wasn't the right, approach, sorry. At this point, there > appears to be another change to the IO API in flight. Perhaps that is > the time to address further issues. > > Tycho -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Systems Group, Sun Microsystems, Inc. From sacadmin Fri Mar 20 08:08:18 2009 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 n2KF8IoP021676 for ; Fri, 20 Mar 2009 08:08:18 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n2KF8FFr029934 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Fri, 20 Mar 2009 08:08:18 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KGT005018PTWM00@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 20 Mar 2009 09:08:17 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KGT003JM8PSD920@brm-avmta-1.central.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 20 Mar 2009 09:08:17 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2KF8GM1002504 for ; Fri, 20 Mar 2009 15:08:16 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KGT00E008HNXE00@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 20 Mar 2009 09:08:16 -0600 (MDT) Received: from burl-legion-0 ([unknown] [10.8.28.177]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KGT00HD08PC3P60@mail-amer.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Fri, 20 Mar 2009 09:08:00 -0600 (MDT) Date: Fri, 20 Mar 2009 11:07:59 -0400 (EDT) From: Tycho Nightingale Subject: Re: 2009/050 - derail In-reply-to: <49C27C77.7030106@sun.com> Sender: Tycho.Nightingale@sun.com X-X-Sender: tychon@burl-legion-0 To: Hitendra Zhangada Cc: fwarc@sun.com, Charles Kunzman Reply-to: Tycho Nightingale Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <499CC324.2020902@sun.com> <49C2727D.3060601@sun.com> <49C27C77.7030106@sun.com> Status: RO Content-Length: 1262 On Thu, 19 Mar 2009, Hitendra Zhangada wrote: > Tycho Nightingale wrote: >> >> On Thu, 19 Mar 2009, Hitendra Zhangada wrote: >> >>> Yes, timer has expired but my questions related to interface >>> classification has not been answered. Can we settle on this please? >>> >>> Did you get those mails from me? >> >> Yes, I got the emails. Yes, there was a ton of offline discussion about >> the change Charles was proposing and yes that caused the entire IO API to >> unfairly undergo additional scrutiny. >> >> As Charles wasn't asking to have the entire IO API (re)reviewed, he simply >> wanted to focus on one tiny bit, to expedite matters, I moved this case >> along. > > I have not problems with moving ahead with the case as fast track or getting > it approved. Actually, I did say it LGTM in my mail. My only concern is > the use of interface classification. The interface is fine but the > classification > of it is where I want to have some discussions. Your concerns about the classification are valid and I apologize for glossing over them before approving this case. While the case remains approved, I did make the modification of modifying the interface from 'Committed' to 'Sun Private' to conform with existing precedent. Tycho