From sacadmin Thu Jan 31 14:10:10 2008 Received: from dtmail.sfbay.sun.com (pkg [129.146.90.56]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0VMAAvK007055 for ; Thu, 31 Jan 2008 14:10:10 -0800 (PST) Received: from [127.0.0.1] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0VMA7mV012559; Thu, 31 Jan 2008 14:10:09 -0800 (PST) Message-ID: <47A2473F.2010405@sun.com> Date: Thu, 31 Jan 2008 14:10:07 -0800 From: David Kahn User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: FWARC@sac.sfbay.sun.com CC: Tayfun Kocaoglu , Jan Setje-Eilers Subject: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 581 I'm sponsoring this fast track case for Tayfun. The fast track timeout is Feb 7, 2008. This is the first of at least 2 cases to add support for large disks to OpenBoot. This case is mostly about additions to the deblocker package, and required methods for packages that use the deblocker package. Another case will be submitted later that deals with GPT label support. This case is a prerequisite for the 2nd case. The one pager includes the interface table, and the proposal itself is in the case materials directory. The project seeks a minor/micro/patch binding. -David From sacadmin Thu Jan 31 15:20:57 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0VNKv53009073 for ; Thu, 31 Jan 2008 15:20:57 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0VNKvxv024817 for ; Thu, 31 Jan 2008 15:20:57 -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 m0VNKvQT021915 for ; Thu, 31 Jan 2008 23:20:57 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 <0JVJ00B017HP1J00@mail-amer.sun.com> (original mail from S.Jain@Sun.COM) for FWARC@sac.sfbay.sun.com; Thu, 31 Jan 2008 16:20:56 -0700 (MST) Received: from [129.150.18.57] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVJ0003I7ITUE40@mail-amer.sun.com>; Thu, 31 Jan 2008 16:20:54 -0700 (MST) Date: Thu, 31 Jan 2008 15:20:56 -0800 From: Sunit Jain Subject: Re: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 In-reply-to: <47A2473F.2010405@sun.com> Sender: S.Jain@sun.com To: David Kahn Cc: FWARC@sac.sfbay.sun.com, Tayfun Kocaoglu , Jan Setje-Eilers Reply-to: S.Jain@sun.com Message-id: <47A257D8.8050209@Sun.Com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <47A2473F.2010405@sun.com> User-Agent: Thunderbird 2.0.0.12pre (Windows/20080123) Status: RO Content-Length: 1696 [1] Section 4 defines : #blocks-extended ( -- d.blocks ) where the number of blocks is represented as double Why do we still use #blocks in following methods (section 3.1.1) -- read-blocks-extended ( addr d.block# #blocks -- #read ) M write-blocks-extended (addr d.block# #blocks -- #written ) M Shouldn't we be using d.#blocks instead? read-blocks-extended ( addr d.block# d.#blocks -- #read ) M write-blocks-extended (addr d.block# d.#blocks -- #written ) M Then we would also have d.#read and d.#written instead of #read and #written. [2] Section 5 lists the following methods - read-blocks-extended write-blocks-extended #blocks #blocks should be #blocks-extended [3] In all the instances, the 64-bit quantities are signed or unsigned? [4] Which section is the interface table? I do see section 2 listing the existing interface but do not see an interface table. [5] I am not a big fan of the new *-extended names. Can we have something like -- read-blocks64 write-blocks64 #blocks64 Regards, Sunit David Kahn wrote: > > I'm sponsoring this fast track case for Tayfun. > The fast track timeout is Feb 7, 2008. > > This is the first of at least 2 cases > to add support for large disks to OpenBoot. > > This case is mostly about additions to the > deblocker package, and required methods for > packages that use the deblocker package. > > Another case will be submitted later that > deals with GPT label support. This case > is a prerequisite for the 2nd case. > > The one pager includes the interface table, > and the proposal itself is in the case > materials directory. > > The project seeks a minor/micro/patch binding. > > -David > From sacadmin Thu Jan 31 15:43:18 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0VNhH1S010597 for ; Thu, 31 Jan 2008 15:43:17 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0VNhHVQ036323; Thu, 31 Jan 2008 15:43:17 -0800 (PST) Received: from [127.0.0.1] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0VNhGc7015429; Thu, 31 Jan 2008 15:43:16 -0800 (PST) Message-ID: <47A25D14.5090306@sun.com> Date: Thu, 31 Jan 2008 15:43:16 -0800 From: David Kahn User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: S.Jain@sun.com CC: FWARC@sac.sfbay.sun.com, Tayfun Kocaoglu , Jan Setje-Eilers Subject: Re: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 References: <47A2473F.2010405@sun.com> <47A257D8.8050209@Sun.Com> In-Reply-To: <47A257D8.8050209@Sun.Com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2098 Sunit Jain wrote: > [1] > Section 4 defines : > > #blocks-extended ( -- d.blocks ) > > where the number of blocks is represented as double > > Why do we still use #blocks in following methods (section 3.1.1) -- > > read-blocks-extended ( addr d.block# #blocks -- #read ) M > write-blocks-extended (addr d.block# #blocks -- #written ) M > > Shouldn't we be using d.#blocks instead? Only if you think we need to read/write more than 2^32 blocks in one call to read or write. The only thing that needs to be "fixed" is the starting block number in these calls, because read-blocks and write-blocks take a 32-bit argument for the starting block number. > [2] > Section 5 lists the following methods - > > read-blocks-extended > write-blocks-extended > #blocks > > #blocks should be #blocks-extended Fixed, and will update the document in the materials directory. Thank you. > > > [3] > In all the instances, the 64-bit quantities are signed or unsigned? It's a double number, as defined by the Forth standard. I believe they are signed. We are not creating a new data type. The dxyz term is defined in the beginning of the glossary in 1275 as a double number. > > > [4] > Which section is the interface table? I do see section 2 listing the > existing interface > but do not see an interface table. It's in the one-pager, section 4.5 > [5] > I am not a big fan of the new *-extended names. Can we have something > like -- > > read-blocks64 > write-blocks64 > #blocks64 For everybody that doesn't like -extended, there will be people that don't like *64. We had several conversations about the names with and without Mitch. One of the problems with *64 is that everybody's stack size isn't 32, and double numbers could be more or less than 32. In FCode a stack item is 32-bits, but in forth on a 64-bit machine, a stack item is 64-bits. Double numbers are 2 stack items, which is not the same as 64-bits. (Effectively in our OBP implementation, they are 64-bit numbers, but this is written as an OFWG proposal as well.) -David From sacadmin Thu Jan 31 15:54:48 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0VNsmlY011864 for ; Thu, 31 Jan 2008 15:54:48 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0VNsmov043628 for ; Thu, 31 Jan 2008 15:54:48 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0VNsm69011630 for ; Thu, 31 Jan 2008 23:54:48 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 <0JVJ00L018KMB800@mail-amer.sun.com> (original mail from S.Jain@Sun.COM) for FWARC@sac.sfbay.sun.com; Thu, 31 Jan 2008 16:54:48 -0700 (MST) Received: from [129.150.32.146] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVJ006LZ932NQ20@mail-amer.sun.com>; Thu, 31 Jan 2008 16:54:39 -0700 (MST) Date: Thu, 31 Jan 2008 15:54:42 -0800 From: Sunit Jain Subject: Re: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 In-reply-to: <47A25D14.5090306@sun.com> Sender: S.Jain@sun.com To: David Kahn Cc: FWARC@sac.sfbay.sun.com, Tayfun Kocaoglu , Jan Setje-Eilers Reply-to: S.Jain@sun.com Message-id: <47A25FC2.8090102@Sun.Com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <47A2473F.2010405@sun.com> <47A257D8.8050209@Sun.Com> <47A25D14.5090306@sun.com> User-Agent: Thunderbird 2.0.0.12pre (Windows/20080123) Status: RO Content-Length: 2023 Please see inline below -- David Kahn wrote: > > > Sunit Jain wrote: >> [1] >> Section 4 defines : >> >> #blocks-extended ( -- d.blocks ) >> >> where the number of blocks is represented as double >> >> Why do we still use #blocks in following methods (section 3.1.1) -- >> >> read-blocks-extended ( addr d.block# #blocks -- #read ) M >> write-blocks-extended (addr d.block# #blocks -- #written ) M >> >> Shouldn't we be using d.#blocks instead? > > Only if you think we need to read/write more > than 2^32 blocks in one call to read or write. > > The only thing that needs to be "fixed" is the > starting block number in these calls, because > read-blocks and write-blocks take a 32-bit argument > for the starting block number. It is not whether anyone wants to read 2^32 blocks or not, it is about consistency. I believe that the #blocks usage should be consistent in all *-extended interfaces. >> >> >> [4] >> Which section is the interface table? I do see section 2 listing the >> existing interface >> but do not see an interface table. > > It's in the one-pager, section 4.5 > I am looking at large-disk.txt file and there is no section 4.5. Are you referring to another file as 1-pager? >> [5] >> I am not a big fan of the new *-extended names. Can we have >> something like -- >> >> read-blocks64 >> write-blocks64 >> #blocks64 > > For everybody that doesn't like -extended, there will > be people that don't like *64. We had several conversations > about the names with and without Mitch. > > One of the problems with *64 is that everybody's stack > size isn't 32, and double numbers could be more or less > than 32. In FCode a stack item is 32-bits, but in forth > on a 64-bit machine, a stack item is 64-bits. Double > numbers are 2 stack items, which is not the same as > 64-bits. (Effectively in our OBP implementation, they > are 64-bit numbers, but this is written as an OFWG > proposal as well.) I am not too stuck up about the name. Regards, Sunit > > -David From sacadmin Thu Jan 31 16:16:49 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m110GmIP013541 for ; Thu, 31 Jan 2008 16:16:48 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m110GmRW055856; Thu, 31 Jan 2008 16:16:48 -0800 (PST) Received: from [129.146.96.89] (tayfun [129.146.96.89]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m110GlUr072054; Thu, 31 Jan 2008 16:16:48 -0800 (PST) Message-ID: <47A264EF.7040008@sun.com> Date: Thu, 31 Jan 2008 16:16:47 -0800 From: Tayfun Kocaoglu User-Agent: Thunderbird 2.0.0.12pre (X11/20080120) MIME-Version: 1.0 To: S.Jain@sun.com CC: David Kahn , FWARC@sac.sfbay.sun.com, Jan Setje-Eilers Subject: Re: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 References: <47A2473F.2010405@sun.com> <47A257D8.8050209@Sun.Com> <47A25D14.5090306@sun.com> <47A25FC2.8090102@Sun.Com> In-Reply-To: <47A25FC2.8090102@Sun.Com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 739 Sunit Jain wrote: > > Please see inline below -- > > > David Kahn wrote: >> >> Only if you think we need to read/write more >> than 2^32 blocks in one call to read or write. >> >> The only thing that needs to be "fixed" is the >> starting block number in these calls, because >> read-blocks and write-blocks take a 32-bit argument >> for the starting block number. > > It is not whether anyone wants to read 2^32 blocks or not, it is about > consistency. I believe that > the #blocks usage should be consistent in all *-extended interfaces. Neither SCSI nor SATA (or any other H/W interface) cdb's have room for 64-bits of number of blocks so, we'd be consistently throwing away the upper 32-bits of number of blocks argument. -tek From sacadmin Thu Jan 31 16:20:38 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m110KcCc014101 for ; Thu, 31 Jan 2008 16:20:38 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m110Kbw4058081; Thu, 31 Jan 2008 16:20:37 -0800 (PST) Received: from [127.0.0.1] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m110Kau2072192; Thu, 31 Jan 2008 16:20:36 -0800 (PST) Message-ID: <47A265D4.5000903@sun.com> Date: Thu, 31 Jan 2008 16:20:36 -0800 From: David Kahn User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: S.Jain@sun.com CC: FWARC@sac.sfbay.sun.com, Tayfun Kocaoglu , Jan Setje-Eilers Subject: Re: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 References: <47A2473F.2010405@sun.com> <47A257D8.8050209@Sun.Com> <47A25D14.5090306@sun.com> <47A25FC2.8090102@Sun.Com> In-Reply-To: <47A25FC2.8090102@Sun.Com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2049 Yes, the one pager is linked from the project case dir for every ARC case. It's a separate file. There's an interfaces section, and I used that section for the interface table. Some fast tracks put the project proposal into the one pager. Some don't. This one has a separate file for the proposal in the materials case dir, and that's what you've been reviewing. I did it this way since the standalone proposal could also be used as an OFWG proposal if we want to submit it to the OFWG to inform the external OF community as to what we're doing. > It is not whether anyone wants to read 2^32 blocks or not, it is about > consistency. I believe that the #blocks usage should be consistent in all > *-extended interfaces. The starting block# is the argument that needed to be expanded to a double number, and that is consistent. We don't need a double number and the extra stack item for the number of blocks to be read. And as Tayfun pointed out, the current HBA interfaces can't accept double numbers for the number of blocks to be read, so if we expanded that field, that would require additional changes to the HBA drivers or restrictions on the interface. So, in my opinion, the interfaces are consistent. Specifically, they are identical to the non-extended forms of the methods except for the starting block number argument, and in the case of #blocks-extended, in the result. Just because you need a wider argument for one value, doesn't mean you change all the arguments to be double numbers. You only expand what you need to expand. Also, we don't use the return value from #blocks or #blocks-extended in the read or write calls, so just because the result of those calls has a name similar to the argument for the starting block number in the read-blocks* and write-blocks* methods, does not imply that they have to be the same type. You would want them to be the same type if the result of one could be used as the argument in the other call, but that's not the case here. > I am not too stuck up about the name. Thanks, David From sacadmin Thu Jan 31 16:37:01 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m110b1X2014799 for ; Thu, 31 Jan 2008 16:37:01 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m110b0C8002954 for ; Thu, 31 Jan 2008 16:37:01 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m110b0RN016998 for ; Fri, 1 Feb 2008 00:37:00 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 <0JVJ00G01AWOD700@mail-amer.sun.com> (original mail from S.Jain@Sun.COM) for FWARC@sac.sfbay.sun.com; Thu, 31 Jan 2008 17:37:00 -0700 (MST) Received: from [129.150.32.146] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVJ0079SB1OKS40@mail-amer.sun.com>; Thu, 31 Jan 2008 17:37:00 -0700 (MST) Date: Thu, 31 Jan 2008 16:37:03 -0800 From: Sunit Jain Subject: Re: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 In-reply-to: <47A265D4.5000903@sun.com> Sender: S.Jain@sun.com To: FWARC@sac.sfbay.sun.com Cc: Tayfun Kocaoglu , Jan Setje-Eilers Reply-to: S.Jain@sun.com Message-id: <47A269AF.6070903@Sun.Com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <47A2473F.2010405@sun.com> <47A257D8.8050209@Sun.Com> <47A25D14.5090306@sun.com> <47A25FC2.8090102@Sun.Com> <47A265D4.5000903@sun.com> User-Agent: Thunderbird 2.0.0.12pre (Windows/20080123) Status: RO Content-Length: 2473 David Kahn wrote: > > > Yes, the one pager is linked from the project > case dir for every ARC case. It's a separate > file. There's an interfaces section, and I used > that section for the interface table. > > Some fast tracks put the project proposal into > the one pager. Some don't. This one has a separate > file for the proposal in the materials case dir, > and that's what you've been reviewing. I did it this way > since the standalone proposal could also be used > as an OFWG proposal if we want to submit it to the > OFWG to inform the external OF community as to what > we're doing. My question was simple, where is the interface table? Because I do not see it in large-disk.txt. You mentioned that it is in section 4.5 but there is no section 4.5 in large-disk.txt. There is no other file in case directory either. So, I am not sure what you are talking about. Regards, Sunit > >> It is not whether anyone wants to read 2^32 blocks or not, it is >> about consistency. I believe that the #blocks usage should be >> consistent in all >> *-extended interfaces. > > The starting block# is the argument that needed to > be expanded to a double number, and that is consistent. > > We don't need a double number and the extra stack > item for the number of blocks to be read. And as > Tayfun pointed out, the current HBA interfaces > can't accept double numbers for the number of blocks > to be read, so if we expanded that field, that > would require additional changes to the HBA drivers > or restrictions on the interface. > > So, in my opinion, the interfaces are consistent. > Specifically, they are identical to the non-extended > forms of the methods except for the starting block > number argument, and in the case of #blocks-extended, > in the result. > > Just because you need a wider argument for one > value, doesn't mean you change all the arguments > to be double numbers. You only expand what you > need to expand. > > Also, we don't use the return value from > #blocks or #blocks-extended in the read > or write calls, so just because the result > of those calls has a name similar to the > argument for the starting block number in > the read-blocks* and write-blocks* methods, > does not imply that they have to be the > same type. You would want them to be the > same type if the result of one could be used > as the argument in the other call, but that's > not the case here. > >> I am not too stuck up about the name. > > Thanks, > David From sacadmin Thu Jan 31 16:49:17 2008 Received: from urq.East.Sun.COM (urq.East.Sun.COM [129.148.181.218]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m110nHsj014885 for ; Thu, 31 Jan 2008 16:49:17 -0800 (PST) Received: from urq.East.Sun.COM (localhost [127.0.0.1]) by urq.East.Sun.COM (8.13.8+Sun/8.13.8) with ESMTP id m110rUNZ028792; Thu, 31 Jan 2008 19:53:30 -0500 (EST) Received: (from rdh@localhost) by urq.East.Sun.COM (8.13.8+Sun/8.13.8/Submit) id m110rU8Y028789; Thu, 31 Jan 2008 19:53:30 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18338.28042.131150.821773@gargle.gargle.HOWL> Date: Thu, 31 Jan 2008 19:53:30 -0500 From: RDH To: David Kahn Cc: S.Jain@sun.com, FWARC@sac.sfbay.sun.com, Tayfun Kocaoglu , Jan Setje-Eilers Subject: Re: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 In-Reply-To: David Kahn's message of 31 January 2008 15:43:16 References: <47A2473F.2010405@sun.com> <47A257D8.8050209@Sun.Com> <47A25D14.5090306@sun.com> X-Mailer: VM 7.19 under Emacs 20.3.1 Reply-To: rdh@east.sun.com Status: RO Content-Length: 882 David Kahn writes: > > Sunit Jain wrote: ... > > I am not a big fan of the new *-extended names. Can we have something > > like -- > > > > read-blocks64 > > write-blocks64 > > #blocks64 > > For everybody that doesn't like -extended, there will > be people that don't like *64. We had several conversations > about the names with and without Mitch. > > One of the problems with *64 is that everybody's stack > size isn't 32, and double numbers could be more or less > than 32. In FCode a stack item is 32-bits, but in forth > on a 64-bit machine, a stack item is 64-bits. Double > numbers are 2 stack items, which is not the same as > 64-bits. (Effectively in our OBP implementation, they > are 64-bit numbers, but this is written as an OFWG > proposal as well.) > > -David Then shouldn't 'lba64' property be 'lba-extended' (for sake of consistency)? -RDH From sacadmin Thu Jan 31 17:10:04 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m111A420015285 for ; Thu, 31 Jan 2008 17:10:04 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m111A2IW012591; Thu, 31 Jan 2008 17:10:02 -0800 (PST) Received: from [127.0.0.1] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m111A1Qe073471; Thu, 31 Jan 2008 17:10:01 -0800 (PST) Message-ID: <47A27169.6040107@sun.com> Date: Thu, 31 Jan 2008 17:10:01 -0800 From: David Kahn User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: rdh@east.sun.com CC: S.Jain@sun.com, FWARC@sac.sfbay.sun.com, Tayfun Kocaoglu , Jan Setje-Eilers Subject: Re: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 References: <47A2473F.2010405@sun.com> <47A257D8.8050209@Sun.Com> <47A25D14.5090306@sun.com> <18338.28042.131150.821773@gargle.gargle.HOWL> In-Reply-To: <18338.28042.131150.821773@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 296 RDH wrote: > Then shouldn't 'lba64' property be 'lba-extended' (for sake of > consistency)? Good catch. Nobody is particularly happy with "lba64". So, we figured we can change that one during the fast track review. "lba-extended" was not in my list of suggestions, but it's not bad. -David From sacadmin Thu Jan 31 17:34:48 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m111Yl7Q015608 for ; Thu, 31 Jan 2008 17:34:47 -0800 (PST) Received: from dtmail.sfbay.sun.com (dt101-150.SFBay.Sun.COM [10.6.101.150]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m111YleN022820; Thu, 31 Jan 2008 17:34:47 -0800 (PST) Received: from [127.0.0.1] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m111YjZu074043; Thu, 31 Jan 2008 17:34:46 -0800 (PST) Message-ID: <47A27735.6000408@sun.com> Date: Thu, 31 Jan 2008 17:34:45 -0800 From: David Kahn User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Sunit Jain CC: FWARC@sac.sfbay.sun.com, Tayfun Kocaoglu , Jan Setje-Eilers Subject: Re: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 464 Sunit Jain wrote: > My question was simple, where is the interface table? Because I do not see it > in large-disk.txt. You mentioned that it is in section 4.5 but there is no > section 4.5 in large-disk.txt. There is no other file in case directory > either. So, I am not sure what you are talking about. Sorry, I thought you knew where one-pagers are in case dirs. Section 4.5 in this document: http://sac.eng/FWARC/2008/070/20080131_tayfun.kocaoglu -David From sacadmin Fri Feb 1 06:32:19 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m11EWJol002466 for ; Fri, 1 Feb 2008 06:32:19 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m11EWI6A037141 for ; Fri, 1 Feb 2008 06:32:19 -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 m11EWI2e012549 for ; Fri, 1 Feb 2008 14:32:18 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 <0JVK00E01DEJ8200@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM) for FWARC@sac.sfbay.sun.com; Fri, 01 Feb 2008 07:32:18 -0700 (MST) Received: from [129.148.131.33] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVK00B4CDPS5MC0@mail-amer.sun.com> for FWARC@sac.sfbay.sun.com; Fri, 01 Feb 2008 07:32:16 -0700 (MST) Date: Fri, 01 Feb 2008 09:32:15 -0500 From: Stephen Ehring Subject: Re: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 In-reply-to: <18338.28042.131150.821773@gargle.gargle.HOWL> Sender: Stephen.Ehring@sun.com To: FWARC@sac.sfbay.sun.com Reply-to: Stephen.Ehring@sun.com Message-id: <47A32D6F.9070503@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <47A2473F.2010405@sun.com> <47A257D8.8050209@Sun.Com> <47A25D14.5090306@sun.com> <18338.28042.131150.821773@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.12pre (X11/20080120) Status: RO Content-Length: 383 RDH wrote: > Then shouldn't 'lba64' property be 'lba-extended' (for sake of > consistency)? > I like lba-extended better, too. My only suggestion would be to make it an encoded-int version-type property, but maybe that's overkill since the package interfaces don't really change enough to warrant dealing with compatibility issues? Otherwise, the proposal looks good. Steve From sacadmin Fri Feb 1 09:39:04 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m11Hd4lL006460 for ; Fri, 1 Feb 2008 09:39:04 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m11Hd4TG010885; Fri, 1 Feb 2008 09:39:04 -0800 (PST) Received: from [127.0.0.1] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m11Hd3qv093061; Fri, 1 Feb 2008 09:39:03 -0800 (PST) Message-ID: <47A35935.2080403@sun.com> Date: Fri, 01 Feb 2008 09:39:01 -0800 From: David Kahn User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Stephen Ehring CC: FWARC@sac.sfbay.sun.com Subject: Re: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 390 Stephen Ehring wrote: > My only suggestion would be to make it an encoded-int version-type > property, but maybe that's overkill since the package interfaces don't > really change enough to warrant dealing with compatibility issues? What benefit is there in making it an encoded-int? What would the value be? The presence of the property indicates that the feature is there. -David From sacadmin Fri Feb 1 09:46:56 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m11Hkuaf006630 for ; Fri, 1 Feb 2008 09:46:56 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m11HktGX016254 for ; Fri, 1 Feb 2008 09:46:55 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m11Hktrr026737 for ; Fri, 1 Feb 2008 17:46:55 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 <0JVK00K01KDZPA00@mail-amer.sun.com> (original mail from Stephen.Ehring@Sun.COM) for FWARC@sac.sfbay.sun.com; Fri, 01 Feb 2008 10:46:55 -0700 (MST) Received: from [129.148.131.33] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVK000FRMQ0F9G0@mail-amer.sun.com>; Fri, 01 Feb 2008 10:46:49 -0700 (MST) Date: Fri, 01 Feb 2008 12:46:48 -0500 From: Stephen Ehring Subject: Re: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 In-reply-to: <47A35935.2080403@sun.com> Sender: Stephen.Ehring@sun.com To: David Kahn Cc: FWARC@sac.sfbay.sun.com Reply-to: Stephen.Ehring@sun.com Message-id: <47A35B08.7000608@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <47A35935.2080403@sun.com> User-Agent: Thunderbird 2.0.0.12pre (X11/20080120) Status: RO Content-Length: 851 David Kahn wrote: > > > Stephen Ehring wrote: > >> My only suggestion would be to make it an encoded-int version-type >> property, but maybe that's overkill since the package interfaces >> don't really change enough to warrant dealing with compatibility issues? > > What benefit is there in making it an encoded-int? > What would the value be? > In case the interface between the FCode driver and the new deblocker package methods ever changed again (i.e. different stack effects, etc). Since we are defining a new property, it seemed trivial to make it a version of the interface instead of a "does the interface exist" flag. But if we ever change the interface again I guess we can just define a new boolean. > The presence of the property indicates that the > feature is there. I'm fine with that, too. We don't have to change it. Steve From sacadmin Fri Feb 1 14:25:59 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m11MPxgY022576 for ; Fri, 1 Feb 2008 14:25:59 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m11MPxrd048202 for ; Fri, 1 Feb 2008 14:25:59 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m11MPx4o008130 for ; Fri, 1 Feb 2008 22:25:59 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 <0JVK00C01Z5CJO00@mail-amer.sun.com> (original mail from Eduardo.Horvath@Sun.COM) for FWARC@sac.sfbay.sun.com; Fri, 01 Feb 2008 15:25:59 -0700 (MST) Received: from [129.146.96.43] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVK002CSZN9SZ10@mail-amer.sun.com>; Fri, 01 Feb 2008 15:25:58 -0700 (MST) Date: Fri, 01 Feb 2008 14:25:57 -0800 From: Eduardo E Horvath Subject: Re: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 In-reply-to: <47A2473F.2010405@sun.com> Sender: Eduardo.Horvath@sun.com To: David Kahn Cc: FWARC@sac.sfbay.sun.com, Tayfun Kocaoglu , Jan Setje-Eilers Message-id: <47A39C75.70705@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <47A2473F.2010405@sun.com> User-Agent: Thunderbird 2.0.0.12pre (X11/20080120) Status: RO Content-Length: 1722 I have several questions about this particular ARC case: 1) How does this interact with a full 64-bit FCode implementation? A 64-bit clean deblocker should be able to process 64-bit block numbers without requiring an interface change. Presumably you have an HBA card with an FCode dropin that could be evaluated on a machine that has a 32-bit FCode environment, such as what we're using now, or a full 64-bit FCode environment, and I would expect the resultant driver to work in both. Does the "lba64" property indicate the existence of these methods or support for 64-bit addressing in general? Do these new interfaces need to be exported and used in a 64-bit environment, or is this only relevant for 32-bit environments? 2) I know there are existing implementations of this using the existing interface in use outside Sun. A recent FCode drop we got from LSI for their 106x chips uses the existing interfaces with the expectation that the high bits of the block addresses are valid. LSI had to add code specifically for Sun to ignore the high bits in the block addresses to work properly on OBP. How do you expect this interface to coexist with other existing implementations, especially since this covers not only drivers built into OBP but also all plug in cards from lots of different vendors? 3) 'find-method' is a reasonably good way to determine the existence or absence of an interface. What is the need for the "lba64" property? 4) Instead of defining a new set of methods have you considered keeping the existing interface but using "lxjoin" and "xlsplit" around the actual method invocation to allow the existing interface to provide the extended addressing information? -- Eduardo Horvath From sacadmin Fri Feb 1 16:27:30 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m120RUnm029423 for ; Fri, 1 Feb 2008 16:27:30 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m120RTul047846; Fri, 1 Feb 2008 16:27:29 -0800 (PST) Received: from [10.6.101.8] (dtsrs3 [10.6.101.8]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m120RTmf004444; Fri, 1 Feb 2008 16:27:29 -0800 (PST) Message-ID: <47A3B8F1.1020804@sun.com> Date: Fri, 01 Feb 2008 16:27:29 -0800 From: David Kahn User-Agent: Thunderbird 2.0.0.12pre (X11/20080120) MIME-Version: 1.0 To: Eduardo E Horvath CC: FWARC@sac.sfbay.sun.com, Tayfun Kocaoglu Subject: Re: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 References: <47A2473F.2010405@sun.com> <47A39C75.70705@sun.com> In-Reply-To: <47A39C75.70705@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2531 Eduardo E Horvath wrote: > > I have several questions about this particular > ARC case: > > 1) How does this interact with a full 64-bit FCode > implementation? A 64-bit clean deblocker should be > able to process 64-bit block numbers without requiring > an interface change. Presumably you have an HBA card > with an FCode dropin that could be evaluated on a > machine that has a 32-bit FCode environment, such as > what we're using now, or a full 64-bit FCode environment, > and I would expect the resultant driver to work in both. > Does the "lba64" property indicate the existence of > these methods or support for 64-bit addressing in > general? Do these new interfaces need to be exported > and used in a 64-bit environment, or is this only relevant > for 32-bit environments? The following OFWG accepted proposal basically defined the FCode environment for plug-in cards as a 32-bit environment. http://playground.sun.com/1275/proposals/index.html#370 Plug-in cards must not assume that they are operating in a 64-bit environment. > > 2) I know there are existing implementations of this > using the existing interface in use outside Sun. A > recent FCode drop we got from LSI for their 106x chips > uses the existing interfaces with the expectation that > the high bits of the block addresses are valid. LSI > had to add code specifically for Sun to ignore the high > bits in the block addresses to work properly on OBP. > How do you expect this interface to coexist with other > existing implementations, especially since this covers > not only drivers built into OBP but also all plug in > cards from lots of different vendors? I believe that the proposal in this case will work in any environment. > > 3) 'find-method' is a reasonably good way to determine > the existence or absence of an interface. What is the > need for the "lba64" property? The property is there to allow the client program and applications to easily determine if both the target hba and the deblocker package both implement the interfaces defined by this project. Basically, it's a lot simpler for an application, like install, to look for a property than it is to look for a method. > > 4) Instead of defining a new set of methods have you > considered keeping the existing interface but using > "lxjoin" and "xlsplit" around the actual method > invocation to allow the existing interface to provide > the extended addressing information? Using the x words and passing x's as arguments assumes a certain cell size. -David From sacadmin Fri Feb 1 16:38:18 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m120cIcA029532 for ; Fri, 1 Feb 2008 16:38:18 -0800 (PST) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m120cHNn052879; Fri, 1 Feb 2008 16:38:17 -0800 (PST) Received: from [10.6.101.8] (dtsrs3 [10.6.101.8]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m120cGfK004730; Fri, 1 Feb 2008 16:38:17 -0800 (PST) Message-ID: <47A3BB78.1030908@sun.com> Date: Fri, 01 Feb 2008 16:38:16 -0800 From: David Kahn User-Agent: Thunderbird 2.0.0.12pre (X11/20080120) MIME-Version: 1.0 CC: FWARC@sac.sfbay.sun.com, Tayfun Kocaoglu , Jan Setje-Eilers Subject: 2008/070 - Changes to method names to *64 References: <47A2473F.2010405@sun.com> <47A39C75.70705@sun.com> In-Reply-To: <47A39C75.70705@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 405 In order to solve the consistency issue, the method names were changed from *-extended to *64. (Recognizing that OFWG proposal #370: http://playground.sun.com/1275/proposals/index.html#370 defined FCode as a 32-bit language with a 32-bit cell size. There's an updated spec in the materials dir. There's an interface-table.txt file in the materials dir. The only changes are the method names. -David From sacadmin Tue Feb 5 14:44:59 2008 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 m15MixQn014642 for ; Tue, 5 Feb 2008 14:44:59 -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 m15Mix0m021908 for <@sunmail2sca.sfbay.sun.com:fwarc@sun.com>; Tue, 5 Feb 2008 14:44:59 -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 <0JVS00E05F6ZS700@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 05 Feb 2008 14:44:59 -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 <0JVS00EBYF6YQV00@nwk-avmta-2.sfbay.sun.com> for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 05 Feb 2008 14:44:58 -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 m15MiwFN004833 for ; Tue, 05 Feb 2008 14:44:58 -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 <0JVS00401EXSIE00@fe-sfbay-09.sun.com> (original mail from Hitendra.Zhangada@Sun.COM) for fwarc@sun.com (ORCPT fwarc@sun.com); Tue, 05 Feb 2008 14:44:58 -0800 (PST) Received: from [129.150.38.10] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVS007Z7F6X0OA0@fe-sfbay-09.sun.com>; Tue, 05 Feb 2008 14:44:58 -0800 (PST) Date: Tue, 05 Feb 2008 14:46:48 -0800 From: Hitendra Zhangada Subject: Re: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 In-reply-to: <47A27735.6000408@sun.com> Sender: Hitendra.Zhangada@sun.com To: Firmware ARC Cc: Tayfun Kocaoglu , Jan Setje-Eilers Message-id: <47A8E758.8080501@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 References: <47A27735.6000408@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 1273 David Kahn wrote: > > > Sunit Jain wrote: > >> My question was simple, where is the interface table? Because I do >> not see it >> in large-disk.txt. You mentioned that it is in section 4.5 but there >> is no >> section 4.5 in large-disk.txt. There is no other file in case directory >> either. So, I am not sure what you are talking about. > > Sorry, I thought you knew where one-pagers are > in case dirs. Section 4.5 in this document: > > http://sac.eng/FWARC/2008/070/20080131_tayfun.kocaoglu Just catching up on mails. I know where the one-pager is in the case directory but for any developer who is not familiar with ARC notations about this, it will be really hard to find one-pager type of document. Note that the file name is not even called one-pager. I generally copy one-pager in the materials directory which is where most of us go look for information. I have seen this done for many cases and IMO should be a standard practice. BTW, in the interface table isn't "lba64" needs to be in quotes since it is a name (string)? -- Hitendra Zhangada ============================================= SPS Common SW Features Engineering Software Group, Sun Microsystems, Inc. Work Ph# (858) 625 3757, Ext. x53757 SUN Internal homepage http://esp.west/~hitu From sacadmin Tue Feb 5 15:10:40 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m15NAdW4015485 for ; Tue, 5 Feb 2008 15:10:39 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m15NAVsq015650; Tue, 5 Feb 2008 23:10:37 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVS0081HGDN6T00@brm-avmta-1.central.sun.com>; Tue, 05 Feb 2008 16:10:35 -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 <0JVS007L3GDMSZB0@brm-avmta-1.central.sun.com>; Tue, 05 Feb 2008 16:10:35 -0700 (MST) Received: from dtmail.sfbay.sun.com (dt101-150.SFBay.Sun.COM [10.6.101.150]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m15NAYXg017485; Tue, 05 Feb 2008 15:10:34 -0800 (PST) Received: from [192.168.0.2] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m15NAXsa005904; Tue, 05 Feb 2008 15:10:33 -0800 (PST) Date: Tue, 05 Feb 2008 15:10:33 -0800 From: David Kahn Subject: Re: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 To: Hitendra Zhangada Cc: Firmware ARC , Tayfun Kocaoglu , Jan Setje-Eilers Message-id: <47A8ECE9.8010904@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 253 Hitendra Zhangada wrote: > BTW, in the interface table isn't "lba64" needs to be in quotes since it > is a name (string)? I added quotes to "deblocker", "block" and "lba64" in the interface-table.txt file in the materials directory. Thanks, David From sacadmin Sun Feb 10 18:07:33 2008 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1B27XuH028194; Sun, 10 Feb 2008 18:07:33 -0800 (PST) Received: (from dmk@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m1B27XJX028193; Sun, 10 Feb 2008 18:07:33 -0800 (PST) Date: Sun, 10 Feb 2008 18:07:33 -0800 (PST) From: David Kahn Message-Id: <200802110207.m1B27XJX028193@sac.sfbay.sun.com> To: David.Kahn@sun.com, FWARC@sac.sfbay.sun.com Subject: Re: 2008/070 - OBP deblocker package changes to support large disks - fastrack timeout 02/07/2008 Cc: setje@sun.com, tayfun.kocaoglu@sun.com Status: RO Content-Length: 162 This case is approved. >I'm sponsoring this fast track case for Tayfun. >The fast track timeout is Feb 7, 2008. >The project seeks a minor/micro/patch binding.