From gdamore@sun.com Fri Nov 16 14:59:55 2007 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 lAGMxskr005916 for ; Fri, 16 Nov 2007 14:59: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.7/ENSMAIL,v2.2) with ESMTP id lAGMxkxB027854 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 16 Nov 2007 22:59:53 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 <0JRM00I05FVS7600@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Nov 2007 14:59:52 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRM002LSFVRO550@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Nov 2007 14:59:52 -0800 (PST) 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 lAGMxpej007640 for ; Fri, 16 Nov 2007 14:59:51 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRM00401FPHKW00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Nov 2007 14:59:51 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRM00I14FVDEU40@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Nov 2007 14:59:37 -0800 (PST) Date: Fri, 16 Nov 2007 14:55:11 -0800 From: "Garrett D'Amore" Subject: PSARC 2007/659 materials posted Sender: Garrett.Damore@sun.com To: PSARC-ext@sun.com Message-id: <473E1FCF.10709@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 167 I've just posted the draft functional specification for the SDcard Phase I stack in the inception.materials directory -- file name "sdcard.spec.txt". -- Garrett From gdamore@sun.com Fri Nov 16 15:58:48 2007 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 lAGNwlEO007009 for ; Fri, 16 Nov 2007 15:58:47 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lAGNwjGT018917 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 17 Nov 2007 07:58:46 +0800 (SGT) 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 <0JRM00D05ILWG400@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Nov 2007 16:58:44 -0700 (MST) 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 <0JRM00322ILWV490@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Nov 2007 16:58:44 -0700 (MST) 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 lAGNwijn015109 for ; Fri, 16 Nov 2007 15:58:44 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRM00L01IHG5T00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Nov 2007 15:58:44 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRM002DAILVFG70@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 16 Nov 2007 15:58:43 -0800 (PST) Date: Fri, 16 Nov 2007 15:54:18 -0800 From: "Garrett D'Amore" Subject: PSARC 2007/659 materials updated Sender: Garrett.Damore@sun.com To: PSARC-ext@sun.com Message-id: <473E2DAA.3060709@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 124 I've posted sdcard.20q.txt (20 questions file) and sdcard-1pager.txt in the inception.materials directory. -- Garrett From owner-sac-advocates Tue Nov 20 15:35:39 2007 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 lAKNZdJh016476 for ; Tue, 20 Nov 2007 15:35:39 -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 lAKNYvfM061885; Tue, 20 Nov 2007 16:34:58 -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 <0JRT0001HW69Z800@nwk-avmta-2.sfbay.sun.com> (ORCPT psarc-agenda-announce@Sun.COM); Tue, 20 Nov 2007 15:34:57 -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 <0JRT00HSKW6836E0@nwk-avmta-2.sfbay.sun.com> (ORCPT psarc-agenda-announce@Sun.COM); Tue, 20 Nov 2007 15:34:56 -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 lAKNYu7F045791; Tue, 20 Nov 2007 15:34:56 -0800 (PST) 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 lAKNYJpO016471 for ; Tue, 20 Nov 2007 15:34:19 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lAKNYBbw003963 for <@sunmail2sca.sfbay.sun.com:psarc-agenda-announce@sun.com>; Wed, 21 Nov 2007 07:34:18 +0800 (SGT) 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 <0JRT00H15W53HA00@brm-avmta-1.central.sun.com> for psarc-agenda-announce@sun.com (ORCPT psarc-agenda-announce@Sun.COM); Tue, 20 Nov 2007 16:34:15 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRT00GFMW52W400@brm-avmta-1.central.sun.com> for psarc-agenda-announce@sun.com (ORCPT psarc-agenda-announce@Sun.COM); Tue, 20 Nov 2007 16:34:15 -0700 (MST) 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 lAKNYEFI025999 for ; Tue, 20 Nov 2007 23:34:14 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRT00901VOEQ800@mail-amer.sun.com> (original mail from Aarti.Pai@Sun.COM) for psarc-agenda-announce@Sun.COM (ORCPT psarc-agenda-announce@Sun.COM); Tue, 20 Nov 2007 16:34:14 -0700 (MST) Received: from [129.145.154.107] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRT004YHW4Y8HD0@mail-amer.sun.com> for psarc-agenda-announce@Sun.COM (ORCPT psarc-agenda-announce@Sun.COM); Tue, 20 Nov 2007 16:34:10 -0700 (MST) Date: Tue, 20 Nov 2007 15:34:09 -0800 From: Aarti Pai Subject: CORRECTION: PSARC Agenda 11/28/2007 (2007/659) Sender: Aarti.Pai@sun.com To: psarc-agenda-announce@sun.com Cc: "Garrett D'Amore" , Jennifer Truong Reply-to: Aarti.Pai@sun.com Message-id: <47436EF1.3060505@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_HMexwOeF8Tty9iN0SIfwLw)" X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 4525 This is a multi-part message in MIME format. --Boundary_(ID_HMexwOeF8Tty9iN0SIfwLw) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT A case request has just come through that was approved for the 11/28 agenda. Aarti --Boundary_(ID_HMexwOeF8Tty9iN0SIfwLw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT --Boundary_(ID_HMexwOeF8Tty9iN0SIfwLw)-- From owner-sac-advocates Tue Nov 20 15:42:12 2007 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 lAKNgBK0016623 for ; Tue, 20 Nov 2007 15:42:12 -0800 (PST) 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 lAKNfLfL020998; Tue, 20 Nov 2007 23:41:23 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 <0JRT00103WGY9R00@nwk-avmta-2.sfbay.sun.com> (ORCPT psarc-agenda-announce@sun.com); Tue, 20 Nov 2007 15:41:22 -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 <0JRT001WKWGX6T00@nwk-avmta-2.sfbay.sun.com> (ORCPT psarc-agenda-announce@sun.com); Tue, 20 Nov 2007 15:41:22 -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 lAKNfLh5048551; Tue, 20 Nov 2007 15:41:21 -0800 (PST) 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 lAKNel2N016601 for ; Tue, 20 Nov 2007 15:40:48 -0800 (PST) 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 lAKNejdT020826 for <@sunmail2sca.sfbay.sun.com:psarc-agenda-announce@sun.com>; Tue, 20 Nov 2007 23:40:46 +0000 (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 <0JRT00105WFX8S00@nwk-avmta-2.sfbay.sun.com> for psarc-agenda-announce@sun.com (ORCPT psarc-agenda-announce@sun.com); Tue, 20 Nov 2007 15:40:45 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRT001ORWFW6T00@nwk-avmta-2.sfbay.sun.com> for psarc-agenda-announce@sun.com (ORCPT psarc-agenda-announce@sun.com); Tue, 20 Nov 2007 15:40:45 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lAKNeiFK048448; Tue, 20 Nov 2007 15:40:44 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id lAKNe7kJ019702; Tue, 20 Nov 2007 15:40:07 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id lAKNe7vb019701; Tue, 20 Nov 2007 15:40:07 -0800 (PST) Date: Tue, 20 Nov 2007 15:40:07 -0800 (PST) From: Gary Winiger Subject: Re: CORRECTION: PSARC Agenda 11/28/2007 (2007/659) To: psarc-agenda-announce@sun.com, Aarti.Pai@sun.com Cc: Garrett.Damore@sun.com, Jennifer.Truong@sun.com Message-id: <200711202340.lAKNe7vb019701@marduk.eng.sun.com> MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 188 > A case request has just come through that was approved for the 11/28 agenda. When will the materials be present? Are the ones in the case directory the materials for review? Gary.. From owner-sac-advocates Tue Nov 20 15:51:16 2007 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 lAKNpFXe016852 for ; Tue, 20 Nov 2007 15:51:15 -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 lAKNo5Qw012730; Wed, 21 Nov 2007 07:50:06 +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 <0JRT0090DWVGYT00@nwk-avmta-1.sfbay.Sun.COM> (ORCPT psarc-agenda-announce@sun.com); Tue, 20 Nov 2007 15:50:04 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRT008NLWVFAG10@nwk-avmta-1.sfbay.Sun.COM> (ORCPT psarc-agenda-announce@sun.com); Tue, 20 Nov 2007 15:50:03 -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 lAKNo20a051492; Tue, 20 Nov 2007 15:50:02 -0800 (PST) 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 lAKNnPEn016785 for ; Tue, 20 Nov 2007 15:49:26 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lAKNnNPk011757 for <@sunmail2sca.sfbay.sun.com:psarc-agenda-announce@sun.com>; Wed, 21 Nov 2007 07:49:25 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JRT00101WUBUD00@nwk-avmta-2.sfbay.sun.com> for psarc-agenda-announce@sun.com (ORCPT psarc-agenda-announce@sun.com); Tue, 20 Nov 2007 15:49:23 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRT001LUWUA6T30@nwk-avmta-2.sfbay.sun.com> for psarc-agenda-announce@sun.com (ORCPT psarc-agenda-announce@sun.com); Tue, 20 Nov 2007 15:49:22 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAKNnMj8001664 for ; Tue, 20 Nov 2007 23:49:22 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRT00F01WSS5O00@mail-amer.sun.com> (original mail from Aarti.Pai@Sun.COM) for psarc-agenda-announce@sun.com (ORCPT psarc-agenda-announce@sun.com); Tue, 20 Nov 2007 16:49:22 -0700 (MST) Received: from [129.145.154.107] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRT00K35WU7LF60@mail-amer.sun.com>; Tue, 20 Nov 2007 16:49:20 -0700 (MST) Date: Tue, 20 Nov 2007 15:49:19 -0800 From: Aarti Pai Subject: Re: CORRECTION: PSARC Agenda 11/28/2007 (2007/659) In-reply-to: <200711202340.lAKNe7vb019701@marduk.eng.sun.com> Sender: Aarti.Pai@Sun.COM To: Gary Winiger Cc: psarc-agenda-announce@Sun.COM, Garrett.Damore@Sun.COM, Jennifer.Truong@Sun.COM Reply-to: Aarti.Pai@Sun.COM Message-id: <4743727F.6050204@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ukEn9RbsgFgm64m2+e40bw)" X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 X-PMX-Version: 5.2.0.264296 References: <200711202340.lAKNe7vb019701@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 2246 This is a multi-part message in MIME format. --Boundary_(ID_ukEn9RbsgFgm64m2+e40bw) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Correct. All materials have been confirmed by the project owner to be in the inception.materials dir. sac% pwd /shared/sac/Archives/CaseLog/arc/PSARC/2007/659 sac% ls -l inception.materials total 102 -rw-r--r-- 1 gd78059 sac 8842 Nov 16 15:57 sdcard-1pager.txt -rw-r--r-- 1 gd78059 sac 24518 Nov 16 15:57 sdcard.20q.txt -rw-r--r-- 1 gd78059 sac 15825 Nov 16 14:57 sdcard.spec.txt Aarti Gary Winiger wrote: >>A case request has just come through that was approved for the 11/28 agenda. >> >> > > When will the materials be present? Are the ones in the case > directory the materials for review? > >Gary.. > > --Boundary_(ID_ukEn9RbsgFgm64m2+e40bw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Correct. All materials have been confirmed by the project owner to be in the inception.materials dir.
sac% pwd
/shared/sac/Archives/CaseLog/arc/PSARC/2007/659
sac% ls -l inception.materials
total 102
-rw-r--r--   1 gd78059  sac         8842 Nov 16 15:57 sdcard-1pager.txt
-rw-r--r--   1 gd78059  sac        24518 Nov 16 15:57 sdcard.20q.txt
-rw-r--r--   1 gd78059  sac        15825 Nov 16 14:57 sdcard.spec.txt

Aarti

Gary Winiger wrote: 
A case request has just come through that was approved for the 11/28 agenda.
    

	When will the materials be present?  Are the ones in the case
	directory the materials for review?

Gary..

--Boundary_(ID_ukEn9RbsgFgm64m2+e40bw)-- From owner-sac-advocates Tue Nov 20 15:52:33 2007 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 lAKNqW2V016910 for ; Tue, 20 Nov 2007 15:52:33 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lAKNpOuS013044; Wed, 21 Nov 2007 07:51:26 +0800 (SGT) 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 <0JRT00I07WXNVW00@brm-avmta-1.central.sun.com> (ORCPT psarc-agenda-announce@Sun.COM); Tue, 20 Nov 2007 16:51:23 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRT00G4QWXNVW10@brm-avmta-1.central.sun.com> (ORCPT psarc-agenda-announce@Sun.COM); Tue, 20 Nov 2007 16:51:23 -0700 (MST) 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 lAKNpNYj051826; Tue, 20 Nov 2007 15:51:23 -0800 (PST) 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 lAKNolsI016848 for ; Tue, 20 Nov 2007 15:50:47 -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 lAKNof5j026193 for <@sunmail2sca.sfbay.sun.com:psarc-agenda-announce@sun.com>; Tue, 20 Nov 2007 23:50:46 +0000 (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 <0JRT00A09WWL2400@nwk-avmta-1.sfbay.Sun.COM> for psarc-agenda-announce@sun.com (ORCPT psarc-agenda-announce@Sun.COM); Tue, 20 Nov 2007 15:50:45 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRT008XQWWIAC10@nwk-avmta-1.sfbay.Sun.COM> for psarc-agenda-announce@sun.com (ORCPT psarc-agenda-announce@Sun.COM); Tue, 20 Nov 2007 15:50:42 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAKNogp6000482 for ; Tue, 20 Nov 2007 15:50:42 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRT00701WOMPY00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for psarc-agenda-announce@Sun.COM (ORCPT psarc-agenda-announce@Sun.COM); Tue, 20 Nov 2007 15:50:42 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRT006O4WVZNXD0@fe-sfbay-10.sun.com>; Tue, 20 Nov 2007 15:50:23 -0800 (PST) Date: Tue, 20 Nov 2007 15:45:46 -0800 From: "Garrett D'Amore" Subject: Re: CORRECTION: PSARC Agenda 11/28/2007 (2007/659) In-reply-to: <200711202340.lAKNe7vb019701@marduk.eng.sun.com> Sender: Garrett.Damore@sun.com To: Gary Winiger Cc: psarc-agenda-announce@sun.com, Aarti.Pai@sun.com, Garrett.Damore@sun.com, Jennifer.Truong@sun.com Message-id: <474371AA.9010105@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-PMX-Version: 5.2.0.264296 References: <200711202340.lAKNe7vb019701@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 669 Gary Winiger wrote: >> A case request has just come through that was approved for the 11/28 agenda. >> > > When will the materials be present? Are the ones in the case > directory the materials for review? > Yep. Should all be there. I might have some minor tweaks to send, but I'll post those within the next day or so... (I might need to alter the logic for polled IO that is used in response to panic(), and I'll probably add a nexus xx_reset() entry point so that the framework can reset the nexus driver when it decides things have gone seriously amiss.) Don't hesitate to let me know if yo have any questions. -- Garrett > Gary.. > From owner-sac-advocates Tue Nov 20 15:54:38 2007 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 lAKNsbJU017358 for ; Tue, 20 Nov 2007 15:54:38 -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 lAKNr7CP013576; Wed, 21 Nov 2007 07:53:26 +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 <0JRT00A03X10HP00@nwk-avmta-1.sfbay.Sun.COM> (ORCPT psarc-agenda-announce@Sun.COM); Tue, 20 Nov 2007 15:53:24 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRT008AXX10AG20@nwk-avmta-1.sfbay.Sun.COM> (ORCPT psarc-agenda-announce@Sun.COM); Tue, 20 Nov 2007 15:53:24 -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 lAKNrO9v052326; Tue, 20 Nov 2007 15:53:24 -0800 (PST) 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 lAKNqloo016924 for ; Tue, 20 Nov 2007 15:52:47 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lAKNqi7t013510 for <@sunmail2sca.sfbay.sun.com:psarc-agenda-announce@sun.com>; Wed, 21 Nov 2007 07:52:46 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JRT00101WZXZS00@nwk-avmta-2.sfbay.sun.com> for psarc-agenda-announce@sun.com (ORCPT psarc-agenda-announce@Sun.COM); Tue, 20 Nov 2007 15:52:45 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JRT001U4WZX6T40@nwk-avmta-2.sfbay.sun.com> for psarc-agenda-announce@sun.com (ORCPT psarc-agenda-announce@Sun.COM); Tue, 20 Nov 2007 15:52:45 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAKNqiP0005348 for ; Tue, 20 Nov 2007 15:52:44 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRT00801WSQUA00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for psarc-agenda-announce@Sun.COM (ORCPT psarc-agenda-announce@Sun.COM); Tue, 20 Nov 2007 15:52:44 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRT005TXWZS47F0@fe-sfbay-09.sun.com>; Tue, 20 Nov 2007 15:52:41 -0800 (PST) Date: Tue, 20 Nov 2007 15:48:04 -0800 From: "Garrett D'Amore" Subject: Re: CORRECTION: PSARC Agenda 11/28/2007 (2007/659) In-reply-to: <200711202340.lAKNe7vb019701@marduk.eng.sun.com> Sender: Garrett.Damore@sun.com To: Gary Winiger Cc: psarc-agenda-announce@sun.com, Aarti.Pai@sun.com, Garrett.Damore@sun.com, Jennifer.Truong@sun.com Message-id: <47437234.2060201@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-PMX-Version: 5.2.0.264296 References: <200711202340.lAKNe7vb019701@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 648 Gary Winiger wrote: >> A case request has just come through that was approved for the 11/28 agenda. >> > > When will the materials be present? Are the ones in the case > directory the materials for review? > > Gary.. > Btw, I am of the opinion that this is just barely a one-pager in review scope. So that means you probably won't need as long to review it as you might have for other projects. *Probably*. :-) From my perspective, this case is as much (or nearly so) about laying groundwork for the "Phase II" case (getting ARC members familiar with the technology) as it is getting architectural for Phase I. -- Garrett From gdamore@sun.com Wed Nov 28 09:02:29 2007 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 lASH2SZB022855 for ; Wed, 28 Nov 2007 09:02:29 -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 lASH2NqR027621 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Nov 2007 17:02:28 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 <0JS80030B7C3ZM00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 09:02:27 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS800AI77BZRSE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 09:02:23 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lASH2N9Q000112 for ; Wed, 28 Nov 2007 09:02:23 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS8003012Y6IS00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 09:02:23 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS800LO57BS62C0@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 09:02:16 -0800 (PST) Date: Wed, 28 Nov 2007 08:57:17 -0800 From: "Garrett D'Amore" Subject: PSARC 2007/659 issue reponses Sender: Garrett.Damore@sun.com To: PSARC-ext@sun.com Message-id: <474D9DED.5010501@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 2864 There are (as of now), two issues in the issues file for this case. Here's a quick response: gw-1 Do I correctly understand that all the userland stuff such as hald/dbus, allocate functions the same without change, but just has more devices that are hot plugable? Yes, that's the idea. Its possible that I'll discover a problem with userland (I'm still trying to debug this!) where a userland change might be necessary, but that would represent a bug in the userland code. (For example, if it "knows" that "usb" attached devices are hotpluggable, and doesn't support automatic mount/unmount for normal SCSI hotplug. I'm hoping that this is not the case. For now it seems mostly not to be, but I think I'm having some trouble that could be related to failure to generate appropriate sysevents during hotplug. I'm not sure yet.) jdc-1 Why does sda_slot_online return no error, but offline does? (I would have expected the reverse.) sda_slot_online just notifies the framework to start attempting to use the slot. The first thing that happens after that is an attempt is made at card detection, by the framework. That is run asynchronously from another thread, so there is no good way to report any error back to the driver. The only failure that could be happen would be a failure in the driver in any case, so the driver shouldn't call sda_slot_online if it doesn't believe that the slot is ready for use. As for sda_slot_offline, the reason I originally had when I wrote the spec was to allow for failure to be returned if the slot was busy due to other drivers still using it. However, as I've since learned, this detection is not necessary, because the DDI framework guards detach properly to prevent it. In other words, the calling sequence of xxx_detach() -> sda_slot_offline() is always safe, because xxx_detach() won't be called at all if there are leaf drivers present. In my current implementation sda_slot_offline always returns success (0), and really has no work of its own to do. Here's the current implementation: int sda_slot_offline(sda_slot_t *slot) { mutex_enter(&slot->s_lock); slot->s_online = B_FALSE; mutex_exit(&slot->s_lock); return (0); } As you can see, I could probably just make this a void, and I'm willing to do that now given my updated understand of detach-safety. One possible wrinkle in this would be if I added code to the framework so that the drivers had a cb_ops routine that they were exporting. In that case, I can see potential for problems, but I think a proper getinfo(9e) still protects against xxx_detach() getting called in unsafe situations. (This is unlike my experience with NIC drivers and DLPI style 2, where inherent races mean you *have* to guard against improper/unsafe detach, just so you know where I was coming from.) -- Garrett From gdamore@Sun.COM Wed Nov 28 11:00:17 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lASJ0HKK003207 for ; Wed, 28 Nov 2007 11:00:17 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id lASJ03wH013733 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Nov 2007 11:00:17 -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 <0JS800519CSFGS00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 12:00:15 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS8000UYCSALT60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 12:00:10 -0700 (MST) 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 lASJ0AoT017886 for ; Wed, 28 Nov 2007 11:00:10 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS800I01CBPS200@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 11:00:10 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS800GADCS0ICF0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 11:00:00 -0800 (PST) Date: Wed, 28 Nov 2007 10:55:01 -0800 From: "Garrett D'Amore" Subject: PSARC 2007/659 spec updates Sender: Garrett.Damore@Sun.COM To: PSARC-ext@Sun.COM Message-id: <474DB985.5090500@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 1679 I've deposited an updated copy of the spec as sdcard.spec.txt in the final.materials directory. The diffs follow below. I've also deposited a copy of the issues file, with my responses inline, in the final.materials directory. I'll be drafting an opinion and hope to have a first draft out for review later today or tomorrow. -- Garrett --- 659/inception.materials/sdcard.spec.txt Fri Nov 16 14:57:51 2007 +++ 659/final.materials/sdcard.spec.txt Wed Nov 28 10:47:47 2007 @@ -2,7 +2,7 @@ Functional Specification Garrett D'Amore (gdamore@sun.com) -Nov 16, 2007 +Nov 28, 2007 CHAPTER 1: Introduction @@ -307,10 +307,10 @@ This marks the SD slot online, and attaches nexus devices. -int sda_slot_offline(sda_slot_t *); +void sda_slot_offline(sda_slot_t *); - This detaches the slot from the system. It returns DDI_SUCCESS on success, - DDI_FAILURE otherwise. + This detaches the slot from the system, and releases any associated + resources in the framework. void sda_cmd_done(sda_cmd_t *cmd, int errno); @@ -334,7 +334,11 @@ void sda_slot_detect(sda_slot_t *); - This is called by the nexus driver when a card has been inserted or removed. + This is called by the device driver when a card has been inserted or removed. + The framework will subsequently call the driver's so_getprop() routine with + SDA_PROP_INSERTED to determine whether a card is physically present in the + system or not. (The driver should call this in response to a change in the + SDCD# signal level, for example.) void sda_slot_err(sda_slot_t *slot, const char *format, ...); void sda_slot_log(sda_slot_t *slot, const char *format, ...); From gdamore@sun.com Wed Nov 28 11:41:31 2007 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 lASJfUwI004596 for ; Wed, 28 Nov 2007 11:41:30 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lASJfNn4027480 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 29 Nov 2007 03:41:29 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS80030HEP2DR00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 11:41:26 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS800MX2EP28080@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 11:41:26 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lASJfPq1023822 for ; Wed, 28 Nov 2007 11:41:25 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS800I01EGEY500@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 11:41:25 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS800F2OEOW0S80@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Nov 2007 11:41:24 -0800 (PST) Date: Wed, 28 Nov 2007 11:36:21 -0800 From: "Garrett D'Amore" Subject: PSARC 2007/659 draft opinion Sender: Garrett.Damore@sun.com To: PSARC-ext@sun.com Message-id: <474DC335.5000500@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_ybVRhhHmXTIjertV6+tgQw)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 7413 This is a multi-part message in MIME format. --Boundary_(ID_ybVRhhHmXTIjertV6+tgQw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Attached is a copy of the draft opinion for 2007/659. A copy is placed in the case directory as opinion-draft.{ms,txt} Thanks! -- Garrett --Boundary_(ID_ybVRhhHmXTIjertV6+tgQw) Content-type: text/plain; name=opinion-draft.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion-draft.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: SDcard Stack Phase I Submitted by: Garrett D'Amore File: PSARC/2007/659/opinion.ms Date: November 28, 2007 Committee: Kais Belgaied, James D. Carlson, Mark Carl- son, Gary Winiger (opinion written by Garrett D'Amore). Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary SDcard Stack Phase I is a project to provide access to Secure Digital (SD) storage media via SD card slots found on common laptop computers. SD media is a small-form-factor storage media popular for use with digital cameras, MP3 players, and other consumer devices. 2. Decision & Precedence Information The project is approved as specified in reference [1], but as modified by the required technical change listed in Appendix A below. The project may be delivered in a patch release of the ON consolidation. The project depends on the following other project and may not be delivered before it. PSARC/2007/654 blk2scsa 3. Interfaces PSARC/2007/659 Copyright 2007 Sun Microsystems - 2 - The project exports the following interfaces. ____________________________________________________________________________ | Interfaces Exported | |___________________|_______________________|______________________________| |Interface | Classification | Comments | |___________________|_______________________|______________________________| |drv/sdhost | Volatile | sdhost device driver name | |drv/sdcard | Volatile | sdcard device driver name | | | | | |misc/sda | Consolidation Private| sda common API support | |sys/sdcard/sda.h | Consolidation Private| sda common API header | | | | | |sda_mem_init() | Project Private | memory card API | |sda_mem_fini() | Project Private | memory card API | | | | | |sda_slot_init() | Consolidation Private| nexus API | |sda_slot_fini() | Consolidation Private| nexus API | |sda_slot_alloc() | Consolidation Private| nexus API | |sda_slot_free() | Consolidation Private| nexus API | |sda_slot_online() | Consolidation Private| nexus API | |sda_slot_offline() | Consolidation Private| nexus API | |sda_slot_detect() | Consolidation Private| nexus API | |sda_cmd_done() | Consolidation Private| nexus API | |sda_transfer_done()| Consolidation Private| nexus API | |sda_slot_err() | Consolidation Private| nexus API | |sda_slot_log() | Consolidation Private| nexus API | | | | | |struct sda_slot | Consolidation Private| nexus API opaque slot handle| |struct sda_ops | Consolidation Private| nexus API operations vector | |struct sda_cmd | Consolidation Private| nexus API operations | | | | | |SDA_OPS_VERSION | Consolidation Private| nexus API operations version| |SDA_CMDF_* | Consolidation Private| nexus API command flags | |SDA_PROP_* | Consolidation Private| nexus API slot properties | |___________________|_______________________|______________________________| The project imports the following interfaces. ____________________________________________________ | Interfaces Imported | |_________|_______________________|________________| |Interface| Classification | Comments | |_________|_______________________|________________| |blk2scsa | Consolidation Private| PSARC 2007/654| |_________|_______________________|________________| 4. Opinion PSARC/2007/659 Copyright 2007 Sun Microsystems - 3 - 4.1. blk2scsa dependency One member was unclear about the boundary between blk2scsa PSARC/2007/654 . The project team clarified this, and an updated clarification has been posted in the final.materials/issues file. Further, it is noted that PSARC/2007/654 is a dependency for this case. 4.2. sda_slot_online versus sda_slot_offline errors One member was surprised that sda_slot_offline could return an error while sda_slot_online could not. The project team responded that this was a hold over from earlier design, and has updated the specification so that both functions have no return value (void). 4.3. hald/dbus/userland interaction One member raised a question as to whether certain userland components would need to be modified as part of this case. The project team responded that this should not be the case, barring any bugs in those components (which would be fixed if necessary.) 4.4. sda_slot_detect insertion/removal One member questioned that sda_slot_detect did not accept an argument with the current state (inserted or removed) of the card, and other members expressed concern that this could cause confusion for device driver implementors. The project team clarified the relationship of this portion of the API, and updated the specification to make clear the interaction of this function and the SDA_PROP_INSERTED property. 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required 1. The project shall deliver a cfgadm plugin for SDcard busses, so that users of cfgadm are presented with meaningful and accurate information about the state of SDcard slots. PSARC/2007/659 Copyright 2007 Sun Microsystems - 4 - 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2007/659. 1. 20 Questions File: inception.materials/sdcard.20q.txt 2. One Pager File: inception.materials/sdcard.1pager.txt 3. Functional Specification File: final.materials/sdcard.spec.txt 4 Issues and Responses File: final.materials/issues PSARC/2007/659 Copyright 2007 Sun Microsystems --Boundary_(ID_ybVRhhHmXTIjertV6+tgQw)-- From sac-owner Wed Nov 28 13:07:28 2007 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 lASL7RfW007498 for ; Wed, 28 Nov 2007 13:07:28 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lASL7P0I008625 for <@sunmail2sca.sfbay.sun.com:All-ARCs@sun.com>; Thu, 29 Nov 2007 05:07:27 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JS80071RIOCG400@nwk-avmta-2.sfbay.sun.com> for All-ARCs@sun.com (ORCPT All-ARCs@Sun.COM); Wed, 28 Nov 2007 13:07:24 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JS800MXPIOB7VE0@nwk-avmta-2.sfbay.sun.com> for All-ARCs@sun.com (ORCPT All-ARCs@Sun.COM); Wed, 28 Nov 2007 13:07:23 -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 lASL7N4A028505 for ; Wed, 28 Nov 2007 21:07:23 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS800301I2E9100@mail-amer.sun.com> (original mail from Aarti.Pai@Sun.COM) for All-ARCs@Sun.COM (ORCPT All-ARCs@Sun.COM); Wed, 28 Nov 2007 14:07:23 -0700 (MST) Received: from [129.145.154.72] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS8002B9INZI8G0@mail-amer.sun.com> for All-ARCs@Sun.COM (ORCPT All-ARCs@Sun.COM); Wed, 28 Nov 2007 14:07:11 -0700 (MST) Date: Wed, 28 Nov 2007 13:07:11 -0800 From: Aarti Pai Subject: PSARC case approved 11/28/2007 - (2007/659) Sender: Aarti.Pai@sun.com To: Aarti Pai Reply-to: Aarti.Pai@sun.com Message-id: <474DD87F.50101@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 219 PSARC approved 11/28/2007 Case: SDcard Stack Phase I (2007/659) Incompatible Changes: none Precedent: none If more information is needed, please contact the case owner/intern. Aarti From sacadmin Thu Nov 29 10:07:28 2007 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 lATI7R6c006704 for ; Thu, 29 Nov 2007 10:07:27 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lATI7AB2000587 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Fri, 30 Nov 2007 02:07:26 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JSA0010750CHM00@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 29 Nov 2007 10:07:24 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSA00K4950CLWD0@nwk-avmta-2.sfbay.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 29 Nov 2007 10:07:24 -0800 (PST) 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 lATI7OVE003237 for ; Thu, 29 Nov 2007 18:07:24 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSA00L013ZIMF00@mail-amer.sun.com> (original mail from Aarti.Pai@Sun.COM) for psarc@sun.com (ORCPT psarc@sun.com); Thu, 29 Nov 2007 11:07:24 -0700 (MST) Received: from [129.150.32.206] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSA000JK508FF20@mail-amer.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Thu, 29 Nov 2007 11:07:20 -0700 (MST) Date: Thu, 29 Nov 2007 10:07:19 -0800 From: Aarti Pai Subject: Meeting Minutes for PSARC- 11/28/2007 - (2007/659) SDCard Stack Phase 1 Sender: Aarti.Pai@sun.com To: psarc@sun.com Message-id: <474EFFD7.2050602@Sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.11pre (Windows/20071128) Status: RO Content-Length: 541 Minutes/Audio for PSARC meeting of 11/28/2007 are now available: - Arc Business: http://sac.sfbay/Archives/Minutes/PSARC/2007/20071128.arcbiz Audio: http://sac.sfbay/Archives/Minutes/PSARC/2007/20071128.arcbiz.open1.mp3 - Commitment Review: SDCard Stack Phase 1 (2007/659): http://sac.sfbay/Archives/Minutes/PSARC/2007/20071128.2007.659.commitment Audio: http://sac.sfbay/Archives/Minutes/PSARC/2007/20071128.2007.659.commitment.mp3 Please contact me directly if you require any corrections/modifications to these minutes. Aarti From gdamore@Sun.COM Fri Nov 30 08:20:17 2007 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 lAUGKHfM008731 for ; Fri, 30 Nov 2007 08:20:17 -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 lAUGKGJd019986 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 30 Nov 2007 09:20:17 -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 <0JSB00M0JUPSWK00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 Nov 2007 09:20:16 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSB00KGKUPRLJ20@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 Nov 2007 09:20:15 -0700 (MST) 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 lAUGKFms018803 for ; Fri, 30 Nov 2007 08:20:15 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSB00301UNLS100@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 Nov 2007 08:20:15 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSB008ZGUPR1P80@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 30 Nov 2007 08:20:15 -0800 (PST) Date: Fri, 30 Nov 2007 08:15:11 -0800 From: "Garrett D'Amore" Subject: Opinion for review: PSARC 2007/659 SDcard Stack Phase I Sender: Garrett.Damore@Sun.COM To: PSARC-ext@Sun.COM Message-id: <4750370F.9030204@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 161 I've placed the opinion in the case directory. ASCII, PostScript, PDF, and nroff supplied. Deadline for PSARC review is Dec. 6, 2007. Thanks! -- Garrett From garrett@damore.org Wed Dec 12 01:01:48 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBC91lqu029531 for ; Wed, 12 Dec 2007 01:01:48 -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 lBC91lHl019959 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 12 Dec 2007 01:01:47 -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 <0JSX00G05IEZXF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Dec 2007 01:01:47 -0800 (PST) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSX00C2SIEXX150@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Dec 2007 01:01:45 -0800 (PST) Received: from relay18i.sun.com (ip128.net129179-4.block1.us.syntegra.com [129.179.4.128]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBC91j38018130 for ; Wed, 12 Dec 2007 09:01:45 +0000 (GMT) Received: from mmp12es.sun.com ([160.41.209.22] [160.41.209.22]) by relay18i.sun.com with ESMTP id BT-MMP-282173 for PSARC-ext@sun.com; Wed, 12 Dec 2007 09:01:44 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.sun.com with ESMTP id BT-MMP-3785372 for PSARC-ext@sun.com; Wed, 12 Dec 2007 09:01:42 +0000 (Z) Received: from mail134c25.carrierzone.com ([64.29.147.204] [64.29.147.204]) by relay1i.sun.com with ESMTP id BT-MMP-125916 for PSARC-ext@sun.com; Wed, 12 Dec 2007 09:01:42 +0000 (Z) Received: from [10.7.251.172] (sca-ea-fw-1.Sun.COM [192.18.43.225]) (authenticated bits=0) by mail134c25.carrierzone.com (8.13.6.20060614/8.13.1) with ESMTP id lBC91ch2020355 for ; Wed, 12 Dec 2007 09:01:40 +0000 (GMT) Date: Wed, 12 Dec 2007 00:56:09 -0800 From: "Garrett D'Amore" Subject: PSARC 2007/659 sdcard stack To: PSARC-ext@sun.com Message-id: <475FA229.3010000@damore.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Z58C9AUZenXdUBdRCN0y2w)" X-PMX-Version: 5.2.0.264296 X-Brightmail-Tracker: AAAAAA== X-Authenticated-User: garrett.damore.org X-Antispam: No, score=-2.4/5.0, scanned in 0.776sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 32670 This is a multi-part message in MIME format. --Boundary_(ID_Z58C9AUZenXdUBdRCN0y2w) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT I've been working on the SDcard software, and have implemented the TCR. However, in order to implement the TCR, I found that I needed to change the spec somewhat. Specifically, instead of registering abstract "slots" with the framework, I needed host drivers to register their devinfo nodes. This is necessary in order to deal with attachment point interfaces, since the framework will now supply a cb_ops on behalf of the host driver. (It also means that the framework supplies a getinfo() entry point.) What I'm not sure is whether to handle this as an update (and reset the PSARC review timer, which has technically expired), or to run it as a separate fasttrack. I'd like the opinions of the experts. To facilitate this, I've attached two files: sdcard.update.spec, which is the updated spec in its entirety, and sdcard.diff, which is the diff -u of the new spec versus the old spec. There are also some minor language cleanups in the diffs (e.g. replace "nexus" with "host driver", etc.) Thanks for your input. I'll deal with this however PSARC feels is most appropriate. -- Garrett --Boundary_(ID_Z58C9AUZenXdUBdRCN0y2w) Content-type: text/x-patch; name=sdcard.diff Content-transfer-encoding: 7BIT Content-disposition: inline; filename=sdcard.diff --- /net/sac.eng/export/sac/PSARC/2007/659/final.materials/sdcard.spec.txt Wed Nov 28 10:47:47 2007 +++ sdcard.update.txt Mon Dec 10 18:07:46 2007 @@ -39,13 +39,14 @@ ================================== Our long term view is to provide a general purpose SD stack (SDA, for -SD Architecture), with public APIs for SD slot devices (nexus -drivers), as well as target devices for I/O peripherals. +SD Architecture), with public APIs for SD host drivers, as well as target +devices for I/O peripherals. -As part of that view, we would supply a reference nexus implementation -for the most common "standard" SD slot controller (SD Standard Host -Controller, identified by PCI class 0x8 and subclass 0x5.) This is the -standard implemented by the controllers found on most modern laptops. +As part of that view, we would supply a reference host driver +implementation for the most common "standard" host controller (SD +Standard Host Controller, identified by PCI class 0x8 and subclass +0x5.) This is the standard implemented by the controllers found on +most modern laptops. We would also supply a driver for the memory cards (which will not use the same APIs as generic SD I/O peripherals, due to the very different @@ -62,13 +63,13 @@ to deliver a simplified SD stack, with only the following components: * sda - core framework - * sdhost - nexus driver for SD Standard Host Controller + * sdhost - host driver for SD Standard Host Controller * sdcard - SD memory card driver, more below For this delivery, which we will term Phase I, we would make the nexus driver APIs Consolidation Private. The API between the sdcard and sda modules will always be Project Private. Later, in Phase II, we would -open up the nexus API and add leaf driver APIs. +open up the host driver API and add leaf driver APIs. This PSARC case only addresses Phase I. @@ -85,7 +86,7 @@ would be caused by a "true" layered approach. The reason that the sdcard driver exists at all (rather than allowing -sda nexus drivers to act as blk2scsa drivers themselves) is that in +sda host drivers to act as blk2scsa drivers themselves) is that in the future we anticipate needing to export different nexus operations for SDA I/O peripherals. Since a given device info can only have one set of nexus operations (bus_ops), an additional placeholder is @@ -99,11 +100,11 @@ +--------------------+ | filesystem | | sda common module | +--------------+ +--------------+ +--------------+ ^ - | sda nexus |------------| sda memory | | + | sda host |------------| sda memory | | +-- | driver API | | card private | +----------+ | +--------------+ +--- | API +----------+ | sd | | sdhost | | +-----------| blk2scsa | --> | emulated | - | nexusr | +-------+ | sdcard | +----------+ | target 0 | + | host | +-------+ | sdcard | +----------+ | target 0 | | driver | -> | SD | -> | driver | +----------+ | | | slot | | | +--------+ | (bus) | +----------+ @@ -128,20 +129,21 @@ detach, cb_ops, and any other required supporting functions. -CHAPTER 5: Nexus Driver API (Phase I) +CHAPTER 5: Host Driver API (Phase I) ====================================== -The nexus driver API is quite a bit more complex. It is provided in the +The host driver API is quite a bit more complex. It is provided in the header file, as follows. 5.1 Types --------- -The nexus API includes the following types. +The host driver API includes the following types. -typedef struct sda_slot sda_slot; +typedef struct sda_host sda_host; - An opaque (to the nexus driver) handle representing an SD slot. + An opaque (to the host driver) handle to the framework's state for the + host. There will be one of these per host driver instance. typedef struct sda_cmd sda_cmd_t; @@ -149,7 +151,7 @@ The SD Simplified Physical Layer Specification[1] outlines some of them. It has the following members: - uint16_t sc_index; + uint8_t sc_index; The "index", or operation code, for the command. E.g. the GO_IDLE command is 0, the APP_CMD command is 55, etc. @@ -169,24 +171,24 @@ removed, and the remaining words are stored in native byte order. For all other response types the 8-bit prefix and 8-bit suffix are removed, and the remaining 32-bits are stored in native order in sc_response[0]. - This field is supplied by the nexus driver. + This field is supplied by the host driver. - uint32_t sc_byte_count; + uint16_t sc_nblks; - For commands with a data transfer phase, this is the number of bytes to - be transferred. + For commands with a data transfer phase, this is the number of SD + protocol blocks to transfer. See sc_blksz below for more detail. - uint32_t sc_byte_resid; + uint16_t sc_blksz; - Upon completion, the nexus driver should indicate any residual number of - bytes that were not transferred here. - - uint16_t sc_block_size; - SD uses a blocking factor. This is the block size to use. (Stream oriented commands can use a value of 1 here.) Memory commands will generally use 512 or the native card block size here. + uint32_t sc_resid; + + Upon completion, the host driver should indicate any residual number of + bytes that were not transferred here. + caddr_t sc_kvaddr; If non-zero, then this is the starting address of a kernel buffer @@ -205,12 +207,12 @@ a multi-block operation requires a CMD12 to terminate the transfer when the transfer is complete. SDA_CMDF_POLLED indicates that polled I/O should be used to complete the transfer, in which case the - xxx_cmd() entry point in the nexus won't return until the command + xxx_cmd() entry point in the host driver won't return until the command has completed. typedef struct sda_ops sda_ops_t; - This structure is the operations vector implemented by the nexus driver. + This structure is the operations vector implemented by the host driver. It contains the following members. int so_version; @@ -219,17 +221,17 @@ int (*so_cmd)(void *private, sda_cmd_t *); - This is the main submission entry point for SD commands. The private - argument is the nexus driver's private data handle that was established - when the slot was allocated. Unless the command has SDA_CMDF_POLLED - set, the nexus driver will return immediately. Returns 0 on success, - an errno otherwise. + This is the main submission entry point for SD commands. The + private argument is the host driver's private data handle that + was established for the slot. Unless the command has + SDA_CMDF_POLLED set, the host driver will return immediately. + Returns 0 on success, an errno otherwise. int (*so_getprop)(void *private, int propnum, uint32_t *valp); int (*so_setprop)(void *private, int propnum, uint32_t val); These two functions are used to access bus control properties for the - nexus. The following properties are defined: + host. The following properties are defined: SDA_PROP_INSERTED - 1 if a card is prsent in the slot, 0 otherwise @@ -244,7 +246,7 @@ argument is eitehr 1 or 4. SDA_PROP_OCR - the bit mask of voltages for the slot. On - read returns the set supported by teh slot. On write, a single + read returns the set supported by the slot. On write, a single bit (only) sets the voltage for the slot. See [1] for more detail on the specific bits. (sda.h defines values OCR_35_36V, OCR_34_35V... OCR_17_18V for this purpose. The @@ -251,12 +253,12 @@ other OCR bits (power up bit, CCS, number of functions for IO cards) are not used with this property. - SDA_PROP_CAP_4BITS - reads as true if the nexus supports 4-bit bus + SDA_PROP_CAP_4BITS - reads as true if the slot supports 4-bit bus SDA_PROP_CAP_HIV - indicates the slot can operate between 2.7 and 3.6 volts. - SDA_PROP_CAP_NOPIO - indicates that the nexus never needs to access + SDA_PROP_CAP_NOPIO - indicates that the host never needs to access kernel virtual memory associated with transfer buffers if the DMA cookies are provided. (This saves the cost of a bp_mapin() on buffers being transferred from the filesystem.) @@ -281,35 +283,44 @@ The following funcctions are exported by SDA for the nexus driver to use: -void sda_slot_init_ops(struct dev_ops *); -void sda_slot_fini_ops(struct dev_ops *); +void sda_host_init_ops(struct dev_ops *); +void sda_host_fini_ops(struct dev_ops *); - The sdhost driver calls these in its _init() and _fini() entry points to + The host driver calls these in its _init() and _fini() entry points to populate the bus_ops entry point in the dev_ops. (There may also be changes to update cb_ops in the future, though not for Phase I.) -sda_slot_t *sda_slot_alloc(dev_info_t *dip, int num, sda_ops_t *ops, - ddi_dma_attr_t *, void *private); +sda_host_t *sda_host_alloc(dev_info_t *dip, int nslot, sda_ops_t *ops, + ddi_dma_attr_t *attrp); - This allocates a "slot handle", and sdhost calls it once for each slot on - the instance associated with the dip. num is the slot number, normally - starting from zero, on the instance. Its used primarily in formulating - log messages and the address for leaf devices. + This allocates a host structure, and the host driver calls it once for each + driver instance. nslot is the number of slots available on the instance. ops is a structure of operations that the nexus driver supports. See the sda_ops_t description in 5.1 above. -void sda_slot_free(sda_slot_t *); + The attrp is the DMA attributes of the host driver. - This frees a previously allocated slot structure. +void sda_host_free(sda_host_t *); -void sda_slot_online(sda_slot_t *); + This frees previously allocated host state. - This marks the SD slot online, and attaches nexus devices. +void sda_host_set_private(sda_host_t *host, int slotnum, void *private); -void sda_slot_offline(sda_slot_t *); + This associates the opaque private pointer with given host and slot. + The private pointer must be set prior to calling sda_host_attach, + and will be used as the first argument to the various entry points + in the sda_ops structure. - This detaches the slot from the system, and releases any associated +int sda_host_attach(sda_host_t *); + + This "attaches" the SD host (and all of its slots) to the framework. + This should be called after interrupts are enabled, as the first thing the + framework will do is attempt to detect and initialize any inserted card. + +void sda_host_offline(sda_host_t *); + + This detaches the host from the system, and releases any associated resources in the framework. void sda_cmd_done(sda_cmd_t *cmd, int errno); @@ -332,20 +343,21 @@ there was any problem with the transfer (e.g. ETIMEDOUT if the operation took too long, etc.) -void sda_slot_detect(sda_slot_t *); +void sda_host_detect(sda_host_t *host, int slot_num); - This is called by the device driver when a card has been inserted or removed. - The framework will subsequently call the driver's so_getprop() routine with - SDA_PROP_INSERTED to determine whether a card is physically present in the - system or not. (The driver should call this in response to a change in the - SDCD# signal level, for example.) + This is called by the device driver when a card has been inserted to + or removed from the named slot_num. The framework will subsequently + call the driver's so_getprop() routine with SDA_PROP_INSERTED to + determine whether a card is physically present in the system or not. + (The driver should call this in response to a change in the SDCD# + signal level, for example.) -void sda_slot_err(sda_slot_t *slot, const char *format, ...); -void sda_slot_log(sda_slot_t *slot, const char *format, ...); +void sda_host_err(sda_host_t *host, const char *format, ...); +void sda_host_log(sda_host_t *host, const char *format, ...); - These are printf-like messaging macros. slot may be NULL. sda_slot_err + These are printf-like messaging functions. host may be NULL. sda_host_err indicates an error, and will cauase cmn_err(CE_WARN, ...) to be used. - sda_slot_log is an informational message that is only sent to the system log, + sda_host_log is an informational message that is only sent to the system log, and will not not be displayed on the console. @@ -372,19 +384,19 @@ sda_mem_init() Project Private memory card API sda_mem_fini() Project Private memory card API -sda_slot_init() Consolidation Private nexus API -sda_slot_fini() Consolidation Private nexus API -sda_slot_alloc() Consolidation Private nexus API -sda_slot_free() Consolidation Private nexus API -sda_slot_online() Consolidation Private nexus API -sda_slot_offline() Consolidation Private nexus API -sda_slot_detect() Consolidation Private nexus API +sda_host_init() Consolidation Private nexus API +sda_host_fini() Consolidation Private nexus API +sda_host_alloc() Consolidation Private nexus API +sda_host_free() Consolidation Private nexus API +sda_host_attach() Consolidation Private nexus API +sda_host_detach() Consolidation Private nexus API +sda_hsot_detect() Consolidation Private nexus API sda_cmd_done() Consolidation Private nexus API sda_transfer_done() Consolidation Private nexus API -sda_slot_err() Consolidation Private nexus API -sda_slot_log() Consolidation Private nexus API +sda_host_err() Consolidation Private nexus API +sda_host_log() Consolidation Private nexus API -struct sda_slot Consolidation Private nexus API opaque slot handle +struct sda_host Consolidation Private nexus API opaque host handle struct sda_ops Consolidation Private nexus API operations vector struct sda_cmd Consolidation Private nexus API operations --Boundary_(ID_Z58C9AUZenXdUBdRCN0y2w) Content-type: text/plain; name=sdcard.update.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=sdcard.update.txt SDcard Stack Phase I Functional Specification Garrett D'Amore (gdamore@sun.com) Nov 28, 2007 CHAPTER 1: Introduction ======================== One of the most popular of a growing number of digital memory formats is the Secure Digital (SD for short) family. This format is used by many modern cameras, MP3 players, and readers are readily found in USB readers and on-board slots on mobile computing devices. SD is an evolution of MultiMediaCard (MMC), and generally all SD readers can read MMC media. (Newer media versions of the MMC have evolved, and it is not clear at this time that MMC/SD compatibility has been retained, although it is quite likely that at least some form of electrical compatibility has been retained with only a need for software changes.) The latest SD standard also supports high capacity (>2GB) media, and includes support for general purpose I/O devices such as 802.11 adapters, bluetooth, and even digital cameras. SD itself specifies a bus with either one or four data pins, and some additional control pins. All SD cards can also be used on Serial Peripheral Interface busses, although such interfaces are not commonly found on consumer grade equipment. (SPI is much too slow for many of the applications for which SD technology is usually deployed.) Note that most (all?) USB readers act as translators for SD memory cards, making thhem appear as USB mass storage devices. Thus such readers can normally only use memory cards. CHAPTER 2: SDcard Stack Long Term ================================== Our long term view is to provide a general purpose SD stack (SDA, for SD Architecture), with public APIs for SD host drivers, as well as target devices for I/O peripherals. As part of that view, we would supply a reference host driver implementation for the most common "standard" host controller (SD Standard Host Controller, identified by PCI class 0x8 and subclass 0x5.) This is the standard implemented by the controllers found on most modern laptops. We would also supply a driver for the memory cards (which will not use the same APIs as generic SD I/O peripherals, due to the very different nature of how such devices interact with the bus) and one additional I/O peripheral yet to be determined. CHAPTER 3: SDcard Stack Near Term ================================== We desire to get some experience with SD and get the most needed functionality to market quickly - namely support for memory cards in slots found on the most common laptop models. To that end, we propose to deliver a simplified SD stack, with only the following components: * sda - core framework * sdhost - host driver for SD Standard Host Controller * sdcard - SD memory card driver, more below For this delivery, which we will term Phase I, we would make the nexus driver APIs Consolidation Private. The API between the sdcard and sda modules will always be Project Private. Later, in Phase II, we would open up the host driver API and add leaf driver APIs. This PSARC case only addresses Phase I. The sdcard driver will make use of (or logically appear to do so, more below) the blk2scsa project to appear as a SCSI-2 device with removable media. This will allow SD memory media to participate fully in Solaris, including support for hot insertion and removal, just like when they are used in USB readers. The sdcard driver itself will actually have only a tiny amount of code in it, as instead the sda module will provide all of the core functionality needed, including implementing the needed blk2scsa operations. This is being done to reduce overhead and complexity that would be caused by a "true" layered approach. The reason that the sdcard driver exists at all (rather than allowing sda host drivers to act as blk2scsa drivers themselves) is that in the future we anticipate needing to export different nexus operations for SDA I/O peripherals. Since a given device info can only have one set of nexus operations (bus_ops), an additional placeholder is required to avoid conflict. Here's a picture of what the architecture will look like in Phase I. +--------------+ | pcfs mounted | +--------------------+ | filesystem | | sda common module | +--------------+ +--------------+ +--------------+ ^ | sda host |------------| sda memory | | +-- | driver API | | card private | +----------+ | +--------------+ +--- | API +----------+ | sd | | sdhost | | +-----------| blk2scsa | --> | emulated | | host | +-------+ | sdcard | +----------+ | target 0 | | driver | -> | SD | -> | driver | +----------+ | | | slot | | | +--------+ | (bus) | +----------+ ^ +-------+ | +---------+ | PCI bus | +---------+ CHAPTER 4: Memory Card API (Phase I) ===================================== The sda module provides only two functions for the sdcard driver: int sda_mem_init(struct modlinkage *); int sda_mem_fini(struct modlinkage *); The sdcard driver needs only to call these in its _init(9e) and _fini(9e) entry points. The sdcard driver will supply an unpopulated dev_ops in its modlinkage. The sda module will populate the dev_ops, including attach, detach, cb_ops, and any other required supporting functions. CHAPTER 5: Host Driver API (Phase I) ====================================== The host driver API is quite a bit more complex. It is provided in the header file, as follows. 5.1 Types --------- The host driver API includes the following types. typedef struct sda_host sda_host; An opaque (to the host driver) handle to the framework's state for the host. There will be one of these per host driver instance. typedef struct sda_cmd sda_cmd_t; This is structure represents a command to be sent to the SD card. The SD Simplified Physical Layer Specification[1] outlines some of them. It has the following members: uint8_t sc_index; The "index", or operation code, for the command. E.g. the GO_IDLE command is 0, the APP_CMD command is 55, etc. uint32_t sc_argument; The command-specific argument for the command. uint8_t sc_rtype; The response type expected. It will be one of R1, R1b, R2, R3, R4, R5, R5b, R6, or R7. uint32_t sc_response[4]; The response data from the command. For R2, the 8-bit prefix is removed, and the remaining words are stored in native byte order. For all other response types the 8-bit prefix and 8-bit suffix are removed, and the remaining 32-bits are stored in native order in sc_response[0]. This field is supplied by the host driver. uint16_t sc_nblks; For commands with a data transfer phase, this is the number of SD protocol blocks to transfer. See sc_blksz below for more detail. uint16_t sc_blksz; SD uses a blocking factor. This is the block size to use. (Stream oriented commands can use a value of 1 here.) Memory commands will generally use 512 or the native card block size here. uint32_t sc_resid; Upon completion, the host driver should indicate any residual number of bytes that were not transferred here. caddr_t sc_kvaddr; If non-zero, then this is the starting address of a kernel buffer for the data transfer. uint_t sc_ndmac; ddi_dma_cookie_t *sc_dmacs; If sc_ndmac is non-zero, then the buffer has been prepared for DMA already, and cookies to use are supplied here. uint32_t sc_flags; Flags for the operation. SDA_CMDF_READ and SDA_CMDF_WRITE indicate the direction of any data transfer. SDA_CMDF_AUTO_CMD12 indicates that a multi-block operation requires a CMD12 to terminate the transfer when the transfer is complete. SDA_CMDF_POLLED indicates that polled I/O should be used to complete the transfer, in which case the xxx_cmd() entry point in the host driver won't return until the command has completed. typedef struct sda_ops sda_ops_t; This structure is the operations vector implemented by the host driver. It contains the following members. int so_version; Must be set to SDA_OPS_VERSION for Phase I. int (*so_cmd)(void *private, sda_cmd_t *); This is the main submission entry point for SD commands. The private argument is the host driver's private data handle that was established for the slot. Unless the command has SDA_CMDF_POLLED set, the host driver will return immediately. Returns 0 on success, an errno otherwise. int (*so_getprop)(void *private, int propnum, uint32_t *valp); int (*so_setprop)(void *private, int propnum, uint32_t val); These two functions are used to access bus control properties for the host. The following properties are defined: SDA_PROP_INSERTED - 1 if a card is prsent in the slot, 0 otherwise SDA_PROP_WPROTECT - 1 if the card has a write protect tab enabled, 0 otherwise. SDA_PROP_LED - set to 1 to turn an access LED on, 0 to turn off. SDA_PROP_CLOCK - change the bus speed, argument is given in Hz. SDA_PROP_BUSWIDTH - set to change the bus width on the controller, argument is eitehr 1 or 4. SDA_PROP_OCR - the bit mask of voltages for the slot. On read returns the set supported by the slot. On write, a single bit (only) sets the voltage for the slot. See [1] for more detail on the specific bits. (sda.h defines values OCR_35_36V, OCR_34_35V... OCR_17_18V for this purpose. The other OCR bits (power up bit, CCS, number of functions for IO cards) are not used with this property. SDA_PROP_CAP_4BITS - reads as true if the slot supports 4-bit bus SDA_PROP_CAP_HIV - indicates the slot can operate between 2.7 and 3.6 volts. SDA_PROP_CAP_NOPIO - indicates that the host never needs to access kernel virtual memory associated with transfer buffers if the DMA cookies are provided. (This saves the cost of a bp_mapin() on buffers being transferred from the filesystem.) SDA_PROP_CAP_HIGHSPEED - future expansion for high-speed clocking SDA_PROP_CAP_8BITS - future expansion for 8-bit MMC bus SDA_PROP_CAP_LOWV - future expansion for low voltage (1.8V) cards SDA_PROP_CAP_INTR - future expansion for SDIO interrupt support int (*so_poll)(void *private); This function is used to poll the device when interrupts have been disabled, such as when a panic() is in progress. The device must not sleep, and should attempt to poll for completion on any outstanding commands. 5.2 Functions ------------- The following funcctions are exported by SDA for the nexus driver to use: void sda_host_init_ops(struct dev_ops *); void sda_host_fini_ops(struct dev_ops *); The host driver calls these in its _init() and _fini() entry points to populate the bus_ops entry point in the dev_ops. (There may also be changes to update cb_ops in the future, though not for Phase I.) sda_host_t *sda_host_alloc(dev_info_t *dip, int nslot, sda_ops_t *ops, ddi_dma_attr_t *attrp); This allocates a host structure, and the host driver calls it once for each driver instance. nslot is the number of slots available on the instance. ops is a structure of operations that the nexus driver supports. See the sda_ops_t description in 5.1 above. The attrp is the DMA attributes of the host driver. void sda_host_free(sda_host_t *); This frees previously allocated host state. void sda_host_set_private(sda_host_t *host, int slotnum, void *private); This associates the opaque private pointer with given host and slot. The private pointer must be set prior to calling sda_host_attach, and will be used as the first argument to the various entry points in the sda_ops structure. int sda_host_attach(sda_host_t *); This "attaches" the SD host (and all of its slots) to the framework. This should be called after interrupts are enabled, as the first thing the framework will do is attempt to detect and initialize any inserted card. void sda_host_offline(sda_host_t *); This detaches the host from the system, and releases any associated resources in the framework. void sda_cmd_done(sda_cmd_t *cmd, int errno); The nexus driver calls this when the command phase for cmd has finished. The errno indicates the completion status of the command. Note that commands which involve a data transfer phase or use the busy bit (response types R1b and R5b) may have this called while the DAT lines are still active. (I.e. the nexus driver shall not wait for the DAT lines to become idle before calling this.) If errno is non-zero, then the cmd will not have a data phase associated with it. void sda_transfer_done(sda_cmd_t *cmd, int errno); The nexus driver calls this when a command that was making use of DAT lines (such as a command with response type R1b or R5b, or a command with a data transfer associated) has finished completely. The errno is non-zero if there was any problem with the transfer (e.g. ETIMEDOUT if the operation took too long, etc.) void sda_host_detect(sda_host_t *host, int slot_num); This is called by the device driver when a card has been inserted to or removed from the named slot_num. The framework will subsequently call the driver's so_getprop() routine with SDA_PROP_INSERTED to determine whether a card is physically present in the system or not. (The driver should call this in response to a change in the SDCD# signal level, for example.) void sda_host_err(sda_host_t *host, const char *format, ...); void sda_host_log(sda_host_t *host, const char *format, ...); These are printf-like messaging functions. host may be NULL. sda_host_err indicates an error, and will cauase cmn_err(CE_WARN, ...) to be used. sda_host_log is an informational message that is only sent to the system log, and will not not be displayed on the console. APPENDIX A: Interface Tables ============================== Here are the interface tables: Imported Interfaces Imported Interface Stability Comments ---------------------------------------------------------- blk2scsa Consolidation Private PSARC 2007/654 Exported Interface Stability Comments ---------------------------------------------------------- drv/sdhost Volatile sdhost device driver name drv/sdcard Volatile sdcard device driver name misc/sda Consolidation Private sda common API support sys/sdcard/sda.h Consolidation Private sda common API header sda_mem_init() Project Private memory card API sda_mem_fini() Project Private memory card API sda_host_init() Consolidation Private nexus API sda_host_fini() Consolidation Private nexus API sda_host_alloc() Consolidation Private nexus API sda_host_free() Consolidation Private nexus API sda_host_attach() Consolidation Private nexus API sda_host_detach() Consolidation Private nexus API sda_hsot_detect() Consolidation Private nexus API sda_cmd_done() Consolidation Private nexus API sda_transfer_done() Consolidation Private nexus API sda_host_err() Consolidation Private nexus API sda_host_log() Consolidation Private nexus API struct sda_host Consolidation Private nexus API opaque host handle struct sda_ops Consolidation Private nexus API operations vector struct sda_cmd Consolidation Private nexus API operations SDA_OPS_VERSION Consolidation Private nexus API operations version SDA_CMDF_* Consolidation Private nexus API command flags SDA_PROP_* Consolidation Private nexus API slot properties APPENDIX B: References ======================= [1] SD Specifications Part 1: Physical Layer Simplified Specification, Version 2.00, September 25, 2006 (www.sdcard.org) [2] SD Specifications Part A2: SD Host Controller Simplified Specification, Version 2.00, February 8, 2007 (www.sdcard.org) [3] SD Specifications Part E1: SDIO Simplified Specification, Version 2.00, February 8, 2007 (www.sdcard.org) [4] Generic Block Device to SCSA Translation Layer, Functional Specification, Garrett D'Amore, November 13, 2007, PSARC 2007/654 --Boundary_(ID_Z58C9AUZenXdUBdRCN0y2w)-- From gww@eng.sun.com Wed Dec 12 12:53:01 2007 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 lBCKr0Fw016058 for ; Wed, 12 Dec 2007 12:53:01 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBCKqtfu027078 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 13 Dec 2007 04:52:59 +0800 (SGT) 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 <0JSY00I03FC9DH00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Dec 2007 13:52:57 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JSY0066BFC86EC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 12 Dec 2007 13:52:56 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBCKqtC8063639; Wed, 12 Dec 2007 12:52:55 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id lBCKp62F018072; Wed, 12 Dec 2007 12:51:06 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id lBCKp6Jo018071; Wed, 12 Dec 2007 12:51:06 -0800 (PST) Date: Wed, 12 Dec 2007 12:51:06 -0800 (PST) From: Gary Winiger Subject: Re: PSARC 2007/659 sdcard stack To: PSARC-ext@sun.com, garrett@damore.org Message-id: <200712122051.lBCKp6Jo018071@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1340 Garrett, > I've been working on the SDcard software, and have implemented the TCR. > However, in order to implement the TCR, I found that I needed to change > the spec somewhat. Thanks for bringing this up. > What I'm not sure is whether to handle this as an update (and reset the > PSARC review timer, which has technically expired), or to run it as a > separate fasttrack. I'd like the opinions of the experts. As the case hasn't started SAC review and the changes seem to be confined at the implementation level rather than a change in the primary architecture, here's what I suggest: 1) update the spec as you suggested. Keeping around the previous spec just for reference. 2) make the interface changes in the the opinion interface table. 3) add a section 4 paragraph noting that when implementing the TCR that some of the interfaces changes to accomodate the implementation and they are reflected in the interface table and updated spec. And some short comment that the specific change was: something like to change the abstract slots to host driver devinfo nodes and why. 4) Send this on to SAC review. Set the timer for a week and in the note around the SAC review make a short statement about what changed, why and where in the opinion that change is reflected. Gary.. From sac-owner Mon Jan 7 09:07:00 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 m07H6xf9013008 for ; Mon, 7 Jan 2008 09:07:00 -0800 (PST) Received: from sunmail5.uk.sun.com (localhost [127.0.0.1]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m07H6w3S009198 for ; Mon, 7 Jan 2008 17:06:58 GMT Received: (from noaccess@localhost) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/Submit) id m07H6wPp009197 for sac-opinion-not-2b-used-directly; Mon, 7 Jan 2008 17:06:58 GMT 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 m07H6sTx009161; Mon, 7 Jan 2008 17:06:58 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 <0JUA0061DA7JM200@nwk-avmta-2.sfbay.sun.com>; Mon, 07 Jan 2008 09:06:55 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUA006RHA7I6100@nwk-avmta-2.sfbay.sun.com>; Mon, 07 Jan 2008 09:06:54 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m07H6sB8016437; Mon, 07 Jan 2008 09:06:54 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUA00J01A61R500@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Mon, 07 Jan 2008 09:06:54 -0800 (PST) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUA005G1A7IHP20@fe-sfbay-09.sun.com>; Mon, 07 Jan 2008 09:06:54 -0800 (PST) Date: Mon, 07 Jan 2008 09:00:29 -0800 From: "Garrett D'Amore" Subject: PSARC 2007/659 SDcard Stack Phase I Sender: Garrett.Damore@sun.com To: sac-opinion@sun.com, solaris-pac-opinion@sun.com Message-id: <47825AAD.6080309@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_PV58SwtsmUiQjJ2TWcGqhA)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 8159 This is a multi-part message in MIME format. --Boundary_(ID_PV58SwtsmUiQjJ2TWcGqhA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT --Boundary_(ID_PV58SwtsmUiQjJ2TWcGqhA) Content-type: text/plain; name=opinion.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: SDcard Stack Phase I Submitted by: Garrett D'Amore File: PSARC/2007/659/opinion.ms Date: November 28, 2007 Committee: Gary Winiger (opinion written by Garrett D'Amore), Kais Belgaied, James D. Carlson, Mark Carlson, Glenn Skinner. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary SDcard Stack Phase I is a project to provide access to Secure Digital (SD) storage media via SD card slots found on common laptop computers. SD media is a small-form-factor storage media popular for use with digital cameras, MP3 players, and other consumer devices. 2. Decision & Precedence Information The project is approved as specified in reference [1] - [4], but as modified by the required technical change listed in Appendix A below. The project may be delivered in a patch release of the ON consolidation. The project depends on the following other project and may not be delivered before it. PSARC/2007/654 blk2scsa 3. Interfaces PSARC/2007/659 Copyright 2007 Sun Microsystems - 2 - The project exports the following interfaces. _______________________________________________________________________________ | Interfaces Exported | |______________________|_______________________|______________________________| |Interface | Classification | Comments | |______________________|_______________________|______________________________| |drv/sdhost | Volatile | sdhost device driver name | |drv/sdcard | Volatile | sdcard device driver name | | | | | |misc/sda | Consolidation Private| sda common API support | |sys/sdcard/sda.h | Consolidation Private| sda common API header | | | | | |sda_mem_init() | Project Private | memory card API | |sda_mem_fini() | Project Private | memory card API | | | | | |sda_host_init() | Consolidation Private| nexus API | |sda_host_fini() | Consolidation Private| nexus API | |sda_host_alloc() | Consolidation Private| nexus API | |sda_host_free() | Consolidation Private| nexus API | |sda_host_attach() | Consolidation Private| nexus API | |sda_host_detach() | Consolidation Private| nexus API | |sda_host_set_private()| Consolidation Private| nexus API | |sda_host_detect() | Consolidation Private| nexus API | |sda_cmd_done() | Consolidation Private| nexus API | |sda_transfer_done() | Consolidation Private| nexus API | |sda_host_err() | Consolidation Private| nexus API | |sda_host_log() | Consolidation Private| nexus API | | | | | |struct sda_host | Consolidation Private| nexus API opaque slot handle| |struct sda_ops | Consolidation Private| nexus API operations vector | |struct sda_cmd | Consolidation Private| nexus API operations | | | | | |SDA_OPS_VERSION | Consolidation Private| nexus API operations version| |SDA_CMDF_* | Consolidation Private| nexus API command flags | |SDA_PROP_* | Consolidation Private| nexus API slot properties | |______________________|_______________________|______________________________| The project imports the following interfaces. ____________________________________________________ | Interfaces Imported | |_________|_______________________|________________| |Interface| Classification | Comments | |_________|_______________________|________________| |blk2scsa | Consolidation Private| PSARC 2007/654| |_________|_______________________|________________| 4. Opinion PSARC/2007/659 Copyright 2007 Sun Microsystems - 3 - 4.1. blk2scsa dependency One member was unclear about the boundary between blk2scsa PSARC/2007/654 and this project. The project team clarified this, and an updated clarification has been posted in [4]. Further, it is noted that PSARC/2007/654 is a dependency for this case. 4.2. sda_slot_online versus sda_slot_offline errors One member was surprised that sda_slot_offline could return an error while sda_slot_online could not. The project team responded that this was a hold over from earlier design, and has updated the specification so that both functions have no return value (void). 4.3. hald/dbus/userland interaction One member raised a question as to whether certain userland components would need to be modified as part of this case. The project team responded that this should not be the case, barring any bugs in those components (which would be fixed if necessary.) 4.4. sda_slot_detect insertion/removal One member questioned that sda_slot_detect did not accept an argument with the current state (inserted or removed) of the card, and other members expressed concern that this could cause confusion for device driver implementors. The project team clarified the relationship of this portion of the API, and updated the specification to make clear the interaction of this function and the SDA_PROP_INSERTED property. 4.5. cfgadm plugin During case investigation, it was noted that without a specific plugin for cfgadm(1M), administrators might be presented with confusing information misrepresenting an SD slot as a SCSI bus. This led to the required technical change listed in 4.6. spec change due to TCR When implementing the technical change required in Appendix A, the project team found that some interface changes were required. Specifically, instead of using abstract slots, the host driver must register itself once per instance. A new sda_host_set_private() function is provided for host drivers to supply per-slot private data. The interface table and the specification in [4] have been updated accord- ingly. PSARC/2007/659 Copyright 2007 Sun Microsystems - 4 - 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required 1. The project shall deliver a cfgadm plugin for SDcard busses, so that users of cfgadm are presented with meaningful and accurate information about the state of SDcard slots. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2007/659. 1. 20 Questions File: inception.materials/sdcard.20q.txt 2. One Pager File: inception.materials/sdcard.1pager.txt 3. Functional Specification File: final.materials/sdcard.spec.txt 4 Issues and Responses File: final.materials/issues PSARC/2007/659 Copyright 2007 Sun Microsystems --Boundary_(ID_PV58SwtsmUiQjJ2TWcGqhA)--