From Tue Jun 12 09:14:34 2001 Date: Tue, 12 Jun 2001 09:14:34 -0700 (PDT) From: Postmaster Subject: Message from mail server Content-Length: 95 Mime-Version: 1.0 Status: RO X-IMAP: 992362474 13 Delete. This is a system message. --END+PSEUDO-- From sac-list-owner Thu May 3 14:26:01 2001 Date: Thu, 3 May 2001 14:27:04 -0700 (PDT) From: Andrew Tucker Subject: 2001/329 New Size Suffixes for mount_tmpfs and mount_xmemfs To: psarc@eng.sun.com Cc: ozgur@eng.sun.com, sch@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: kO0pciOh3JrImTj/WH1fxA== Content-Length: 3073 Status: RO X-Status: $$$$ X-UID: 0000000001 I'm sponsoring the following fast-track for Ozgur Leonard. Timeout set to expire 5/10. This case is seeking a minor release binding. -------------------------------------------------------------------- 1. Description The '-o size=XXX' option to mount_tmpfs(1M) allows one to append a suffix of 'k' for kilobytes or 'm' for megabytes, specifying the unit to be applied to the number. This fast track proposes the addition of two new suffixes, 'g' for gigabytes and 'b' for bytes, for the sake of symmetry. mount_xmemfs(1M), allowing the same "size" flag supports 'g' but does not support 'b'. Incorporation of the 'b' suffix to mount_xmemfs is also proposed. 2. Discussion The proposed changes to the interface as well as the underlying filesystem are straightforward. 3. Man page changes *** mount_tmpfs.1 Wed May 2 18:33:59 2001 --- mount_tmpfs.new Wed May 2 18:35:58 2001 *************** *** 44,50 **** ticular tmpfs file system. If the argument is has a `k' suffix, the number will be interpreted as a number of kilobytes. An `m' suffix will be ! interpreted as a number of megabytes. No suffix is interpreted as bytes. In all cases, the actual size of the file system is the number of bytes specified, rounded up to the physical --- 44,52 ---- ticular tmpfs file system. If the argument is has a `k' suffix, the number will be interpreted as a number of kilobytes. An `m' suffix will be ! interpreted as a number of megabytes. A 'g' ! suffix will be interpreted as a number of giga- ! bytes. A suffix of 'b' or the absence of a suffix is interpreted as bytes. In all cases, the actual size of the file system is the number of bytes specified, rounded up to the physical *** mount_xmemfs.1 Thu May 3 13:57:17 2001 --- mount_xmemfs.new Thu May 3 13:57:58 2001 *************** *** 50,57 **** argument has a k suffix, the number is inter- preted as kilobytes. An m suffix is interpreted as megabytes and g is interpreted as gigabytes. ! A sz specified with no suffix is interpreted as ! bytes. In all cases, the actual size of the file system is the number of bytes specified, rounded up to --- 50,57 ---- argument has a k suffix, the number is inter- preted as kilobytes. An m suffix is interpreted as megabytes and g is interpreted as gigabytes. ! A sz specified with no suffix or a b suffix is ! interpreted as bytes. In all cases, the actual size of the file system is the number of bytes specified, rounded up to From sac-list-owner Thu May 3 14:56:34 2001 X-Authentication-Warning: opulent.Central.Sun.COM: lduncan set sender to lduncan@durango.central using -f From: Lee Duncan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 3 May 2001 15:57:11 -0600 To: psarc@eng.sun.com, ozgur@eng.sun.com, Stephen Hahn Subject: Re: 2001/329 New Size Suffixes for mount_tmpfs and mount_xmemfs X-Disclaimer: My opinions are so off the wall that nobody claims them Content-Length: 973 Status: O X-Status: $$$$ X-UID: 0000000002 This may be dumb, but has anyone considered a library routine to do this, since so many programs seem to have this need? (Perhaps something like strtol().) ---------------------------------------------------------------- I'm sponsoring the following fast-track for Ozgur Leonard. Timeout set to expire 5/10. This case is seeking a minor release binding. -------------------------------------------------------------------- 1. Description The '-o size=XXX' option to mount_tmpfs(1M) allows one to append a suffix of 'k' for kilobytes or 'm' for megabytes, specifying the unit to be applied to the number. This fast track proposes the addition of two new suffixes, 'g' for gigabytes and 'b' for bytes, for the sake of symmetry. mount_xmemfs(1M), allowing the same "size" flag supports 'g' but does not support 'b'. Incorporation of the 'b' suffix to mount_xmemfs is also proposed. 2. Discussion ... -- *Lee++ Just Say No To MIME From sac-list-owner Thu May 3 15:18:08 2001 Date: Thu, 03 May 2001 15:23:05 -0700 From: Richard McDougall X-Accept-Language: en MIME-Version: 1.0 To: Andrew Tucker CC: psarc@eng.sun.com, ozgur@eng.sun.com, sch@eng.sun.com Subject: Re: 2001/329 New Size Suffixes for mount_tmpfs and mount_xmemfs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 3400 Status: O X-Status: $$$$ X-UID: 0000000003 Eagle will have 64TG of memory, so it seems feasible that one would create a file system of a fraction of thise. Why not add the T options now? Richard. Andrew Tucker wrote: > > I'm sponsoring the following fast-track for Ozgur Leonard. Timeout > set to expire 5/10. This case is seeking a minor release binding. > > -------------------------------------------------------------------- > > 1. Description > > The '-o size=XXX' option to mount_tmpfs(1M) allows one to append a > suffix of 'k' for kilobytes or 'm' for megabytes, specifying the unit > to be applied to the number. This fast track proposes the addition of > two new suffixes, 'g' for gigabytes and 'b' for bytes, for the sake > of symmetry. > > mount_xmemfs(1M), allowing the same "size" flag supports 'g' but does > not support 'b'. Incorporation of the 'b' suffix to mount_xmemfs is > also proposed. > > 2. Discussion > > The proposed changes to the interface as well as the underlying > filesystem are straightforward. > > 3. Man page changes > > *** mount_tmpfs.1 Wed May 2 18:33:59 2001 > --- mount_tmpfs.new Wed May 2 18:35:58 2001 > *************** > *** 44,50 **** > ticular tmpfs file system. If the argument is > has a `k' suffix, the number will be interpreted > as a number of kilobytes. An `m' suffix will be > ! interpreted as a number of megabytes. No suffix > is interpreted as bytes. In all cases, the > actual size of the file system is the number of > bytes specified, rounded up to the physical > --- 44,52 ---- > ticular tmpfs file system. If the argument is > has a `k' suffix, the number will be interpreted > as a number of kilobytes. An `m' suffix will be > ! interpreted as a number of megabytes. A 'g' > ! suffix will be interpreted as a number of giga- > ! bytes. A suffix of 'b' or the absence of a suffix > is interpreted as bytes. In all cases, the > actual size of the file system is the number of > bytes specified, rounded up to the physical > > *** mount_xmemfs.1 Thu May 3 13:57:17 2001 > --- mount_xmemfs.new Thu May 3 13:57:58 2001 > *************** > *** 50,57 **** > argument has a k suffix, the number is inter- > preted as kilobytes. An m suffix is interpreted > as megabytes and g is interpreted as gigabytes. > ! A sz specified with no suffix is interpreted as > ! bytes. > > In all cases, the actual size of the file system > is the number of bytes specified, rounded up to > --- 50,57 ---- > argument has a k suffix, the number is inter- > preted as kilobytes. An m suffix is interpreted > as megabytes and g is interpreted as gigabytes. > ! A sz specified with no suffix or a b suffix is > ! interpreted as bytes. > > In all cases, the actual size of the file system > is the number of bytes specified, rounded up to From sac-list-owner Thu May 3 15:31:59 2001 X-Authentication-Warning: opulent.Central.Sun.COM: lduncan set sender to lduncan@durango.central using -f From: Lee Duncan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 3 May 2001 16:32:37 -0600 To: Richard McDougall Cc: psarc@eng.sun.com, ozgur@eng.sun.com, sch@eng.sun.com Subject: Re: 2001/329 New Size Suffixes for mount_tmpfs and mount_xmemfs X-Disclaimer: My opinions are so off the wall that nobody claims them Content-Length: 256 Status: O X-Status: $$$$ X-UID: 0000000004 RM> Eagle will have 64TG of memory, so it seems feasible that one RM> would create a file system of a fraction of thise. Why not add the RM> T options now? RM> Richard. What are "TG"? Is that really TB (Terra bytes)? -- *Lee++ Just Say No To MIME From sac-list-owner Thu May 3 15:32:32 2001 Date: Thu, 3 May 2001 15:35:08 -0700 (PDT) From: Gary Winiger To: tucker@trinity.eng.sun.com, Richard.McDougall@Sun.COM Subject: Re: 2001/329 New Size Suffixes for mount_tmpfs and mount_xmemfs Cc: psarc@eng.sun.com, ozgur@eng.sun.com, sch@eng.sun.com Content-Length: 247 Status: O X-Status: $$$$ X-UID: 0000000005 > Eagle will have 64TG of memory, so it seems feasible that one would > create a file system of a fraction of thise. Why not add the T options > now? Tera byte and gigabyte seems more appropriate to me than byte. Is 'b' really useful? Gary.. From sac-list-owner Thu May 3 15:34:40 2001 Date: Thu, 03 May 2001 15:39:36 -0700 From: Richard McDougall X-Accept-Language: en MIME-Version: 1.0 To: lduncan@central.sun.com CC: Richard McDougall , psarc@eng.sun.com, ozgur@eng.sun.com, sch@eng.sun.com Subject: Re: 2001/329 New Size Suffixes for mount_tmpfs and mount_xmemfs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 334 Status: O X-Status: $$$$ X-UID: 0000000006 64TB. Richard. Lee Duncan wrote: > > RM> Eagle will have 64TG of memory, so it seems feasible that one > RM> would create a file system of a fraction of thise. Why not add the > RM> T options now? > > RM> Richard. > > What are "TG"? Is that really TB (Terra bytes)? > -- > *Lee++ > Just Say No To MIME From sac-list-owner Thu May 3 15:35:06 2001 Date: Thu, 03 May 2001 15:35:59 -0700 From: Jordan Brown X-Accept-Language: en MIME-Version: 1.0 To: Gary Winiger CC: tucker@trinity.eng.sun.com, Richard.McDougall@Sun.COM, psarc@eng.sun.com, ozgur@eng.sun.com, sch@eng.sun.com Subject: Re: 2001/329 New Size Suffixes for mount_tmpfs and mount_xmemfs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 267 Status: O X-Status: $$$$ X-UID: 0000000007 > Tera byte and gigabyte seems more appropriate to me than byte. > Is 'b' really useful? Probably not, but it'd be better to have all commands that accept those suffixes accept the full set, rather than having each command accept some random subset. From sac-list-owner Thu May 3 15:45:56 2001 X-Authentication-Warning: opulent.Central.Sun.COM: lduncan set sender to lduncan@durango.central using -f From: Lee Duncan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 3 May 2001 16:46:34 -0600 To: tucker@trinity.eng.sun.com, psarc@eng.sun.com, ozgur@eng.sun.com, sch@eng.sun.com Subject: Re: 2001/329 New Size Suffixes for mount_tmpfs and mount_xmemfs X-Disclaimer: My opinions are so off the wall that nobody claims them Content-Length: 392 Status: O X-Status: $$$$ X-UID: 0000000008 > Tera byte and gigabyte seems more appropriate to me than byte. > Is 'b' really useful? JB> Probably not, but it'd be better to have all commands that accept JB> those suffixes accept the full set, rather than having each JB> command accept some random subset. Yet another reason to supply this as a library routine that could be shared. -- *Lee++ Just Say No To MIME From sac-list-owner Thu May 3 16:20:57 2001 Date: Thu, 3 May 2001 16:21:24 -0700 (PDT) From: "Joseph E. Kowalski III" Subject: Re: 2001/329 New Size Suffixes for mount_tmpfs and mount_xmemfs To: tucker@trinity.eng.sun.com, Richard.McDougall@Sun.COM, gww@marduk.ebay.sun.com Cc: psarc@eng.sun.com, ozgur@eng.sun.com, sch@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 6hf1yRLMp3ocMl0RnVUmmg== Content-Length: 380 Status: O X-Status: $$$$ X-UID: 0000000009 > Tera byte and gigabyte seems more appropriate to me than byte. > Is 'b' really useful? I promised myself not to get into the suffixes again, but from the mkfile manpage... The default size is in bytes, but it can be flagged as kilobytes, blocks, or megabytes, with the k, b, or m suffixes, respectively. seems like a nice one to follow. - jek3 From sac-list-owner Thu May 3 18:24:56 2001 Date: Thu, 3 May 2001 18:25:19 -0700 (PDT) From: "Joseph E. Kowalski III" Subject: Re: 2001/329 New Size Suffixes for mount_tmpfs and mount_xmemfs To: tucker@trinity.eng.sun.com, Richard.McDougall@Sun.COM, gww@marduk.ebay.sun.com, Joseph.Kowalski@eng.sun.com Cc: psarc@eng.sun.com, ozgur@eng.sun.com, sch@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: TabfBE7pC76HgpaEKXdmqg== Content-Length: 496 Status: O X-Status: $$$$ X-UID: 0000000010 > > Tera byte and gigabyte seems more appropriate to me than byte. > > Is 'b' really useful? > > I promised myself not to get into the suffixes again, but from the > mkfile manpage... > > The default size is in bytes, but it can be > flagged as kilobytes, blocks, or megabytes, with the k, b, > or m suffixes, respectively. > > seems like a nice one to follow. > > - jek3 I misread this. b is for blocks! Sorry I mentioned it. blocks should be dead. - jek3 From sac-list-owner Fri May 4 04:22:54 2001 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 4 May 2001 07:24:40 -0400 (EDT) From: James Carlson To: "Joseph E. Kowalski III" Cc: tucker@trinity.eng.sun.com, Richard.McDougall@sun.com, gww@marduk.ebay.sun.com, psarc@eng.sun.com, ozgur@eng.sun.com, sch@eng.sun.com Subject: Re: 2001/329 New Size Suffixes for mount_tmpfs and mount_xmemfs Content-Length: 710 Status: RO X-Status: $$$$ X-UID: 0000000011 Joseph E. Kowalski III writes: > I misread this. b is for blocks! Sorry I mentioned it. > > blocks should be dead. Possibly, but that does point out a problem. The use of "b" for bytes here is surprising. If I can say "200" and mean 200 bytes, why would I expect that "200b" does the same thing? If I can say "200g" for 200GB, then why can't I say "200gb"? For consistency, I think "b" should either be assigned some meaning other than "bytes" or removed. (b=512 seems ok ...) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sac-list-owner Fri May 4 10:48:24 2001 Date: Fri, 4 May 2001 10:50:54 -0700 (PDT) From: Gary Winiger To: Joseph.Kowalski@eng.sun.com, james.d.carlson@east.sun.com Subject: Re: 2001/329 New Size Suffixes for mount_tmpfs and mount_xmemfs Cc: tucker@trinity.eng.sun.com, Richard.McDougall@sun.com, gww@marduk.ebay.sun.com, psarc@eng.sun.com, ozgur@eng.sun.com, sch@eng.sun.com Content-Length: 893 Status: RO X-Status: $$$$ X-UID: 0000000012 > For consistency, I think "b" should either be assigned some meaning > other than "bytes" or removed. (b=512 seems ok ...) The case requests "b" to mean bytes. With the current sizes of memory and disks bytes didn't make sense to me. IMO mount everywhere should be consistant with how file system sizes can be specified. Blocks don't seem to make sense for memory file systems, but bytes do. They are both the native unit size of the backing store. I don't have a good answer other than to suggest the submitter look at the rest of the sizing and perhaps have a common library routine (as already suggested). If eliminating "b" from mount_tmpfs/xmemfs will not break existing customers (I believe it's not there today), then IMO a common sizing TB, GB, KB (and perhaps historically B for blocks -- 512bytes) is the most consistent message to send to the customer. Gary.. From sac-list-owner Mon May 7 13:21:33 2001 Date: Mon, 7 May 2001 13:22:41 -0700 From: Ozgur C Leonard To: Gary Winiger Cc: Joseph.Kowalski@eng.sun.com, james.d.carlson@east.sun.com, tucker@trinity.eng.sun.com, Richard.McDougall@sun.com, psarc@eng.sun.com, sch@eng.sun.com Subject: Re: 2001/329 New Size Suffixes for mount_tmpfs and mount_xmemfs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Content-Length: 3020 Status: RO X-Status: $$$$ X-UID: 0000000013 On Fri, May 04, 2001 at 10:50:54AM -0700, Gary Winiger wrote: > > For consistency, I think "b" should either be assigned some meaning > > other than "bytes" or removed. (b=512 seems ok ...) > > The case requests "b" to mean bytes. With the current sizes of memory > and disks bytes didn't make sense to me. IMO mount everywhere should > be consistant with how file system sizes can be specified. Blocks > don't seem to make sense for memory file systems, but bytes do. They > are both the native unit size of the backing store. > > I don't have a good answer other than to suggest the submitter look > at the rest of the sizing and perhaps have a common library routine > (as already suggested). If eliminating "b" from mount_tmpfs/xmemfs > will not break existing customers (I believe it's not there today), > then IMO a common sizing TB, GB, KB (and perhaps historically B for > blocks -- 512bytes) is the most consistent message to send to the > customer. > A number of good points were raised in the discussion so far. I will attempt to summarize them, and provide clarifications. Issues Raised: > Eagle will have 64TB of memory. The suffix 't' should also be added in > anticipation. (Rich McDougall) Since xmemfs is only defined for IA32 and supports a maximum of 64GB, the letter 't' would not make sense for mount_xmemfs. I propose adding the 't' suffix (meaning Terabytes) for mount_tmpfs only. (Incidentally, the implementation of mount_xmemfs(1) currently supports the 't' option, but it is not documented.). > It would be useful to have a common library routine to perform this > sort of parsing. (Lee Duncan) The method for parsing these strings is unfortunately non-standard across these two filesystems. mount_tmpfs passes strings to tmp_mount() in the kernel, while mount_xmemfs does the parsing in userland and passes an offset_t to the kernel. While such a common routine would be generally useful to various userland applications (such as od(1)), it would not simplify this particular RFE, and is not proposed at this time. > Why is 'b' taken to mean bytes? Does 'gb' work as well as 'g'? (James > Carlson and others) The current implementation of mount_tmpfs(1M) permits multiple suffixes to be used simultaneously. Ie, size=2mk is a valid option and is taken to mean "2gb". This behavior is not documented. If 'b' were to be adopted as meaning "bytes", then following the existing behavior, '2mb', '2kb', '2gb' would all be valid options with the intuitive semantics of "megabytes", etc. However, as mkfile(1) and od(1) both take 'b' to mean '512 bytes', and as there is nothing particularly special about the number 512 as xmemfs and tmpfs are concerned (a block is equal to the default pagesize on tmpfs, and can be user-specified on xmemfs), I would be willing to drop the proposal for the 'b' suffix altogether. The set of supported suffixes would thus be expanded to [kmgt] (and their uppercase counterparts) for tmpfs, and xmemfs would not be modified. Ozgur From sac-owner Sun Dec 30 15:51:56 2001 X-Authentication-Warning: newday.wi-commwireless.com: lduncan set sender to lduncan@central using -f From: Lee Duncan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 30 Dec 2001 16:48:27 -0700 To: ozgur.leonard@sun.com CC: jek3@eng.sun.com, psarc-record@sac.eng.sun.com Subject: PSARC 2001/329 ? X-Disclaimer: My opinions ... well, you know Content-Length: 1397 Hi Ozgur: My name is Lee Duncan, and I'm writing the opinion on your PSARC case from last year, 2001/329: New Size Suffixes for mount_tmpfs and mount_xmemfs. As I refreshed my memory by going through the mail file in the case directory, I see that you agreed to remove the "b" suffix from your proposal because of possible confusion with other utilities that use "b" to mean "512-byte blocks". I just wanted to make sure that was actually the way you implemented your changes before I write the official opinion. To refresh your memory (since it *has* been a while), you replied to a question by James Carlson with: Ozgur> However, as mkfile(1) and od(1) both take 'b' to mean '512 Ozgur> bytes', and as there is nothing particularly special about the Ozgur> number 512 as xmemfs and tmpfs are concerned (a block is equal Ozgur> to the default pagesize on tmpfs, and can be user-specified on Ozgur> xmemfs), I would be willing to drop the proposal for the 'b' Ozgur> suffix altogether. Ozgur> The set of supported suffixes would thus be expanded to [kmgt] Ozgur> (and their uppercase counterparts) for tmpfs, and xmemfs would Ozgur> not be modified. I'll start writing the opinion assuming this is correct (since it's currently during the winter break), but please confirm this. Thanks (and I hope you had a good holiday, by the way (;o)) -- LeeD "This is not my house." -- David Byrne From sac-owner Mon Jan 7 12:44:33 2002 X-Authentication-Warning: opulent.Central.Sun.COM: lduncan set sender to lduncan@central.Sun.COM using -f From: Lee Duncan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 7 Jan 2002 13:44:57 -0700 To: "Joseph E. Kowalski, III" CC: Ozgur Leonard , psarc-record@sac.eng.sun.com Subject: PSARC/2001/329 X-Disclaimer: My opinions are so off the wall that nobody claims them Content-Length: 748 Hi Joe: Sorry to bother you when you're so busy, but I'd like to get this case done that I'm writing the opinion for (2001/329), and I think you'd like me to finish as well. The problem is that I can't seem to reach Ozgur. I've emailed him (you were cc-ed) and I just tried to call him. Should I go ahead with the opinion as I've written it? The main question I have is whether or not Ozgur changed just mount_tmpfs(1m), or did it also change mount_xmemfs(1m) as well? (I guess I could go try to track down the code changes? (;o() I've written the opinion to reflect that last agreed-upon version, which only changed mount_tmpfs(1m). Should I just go ahead? Any advice would be appreciated. -- LeeD "This is not my house." -- David Byrne From sac-owner Mon Jan 7 13:14:56 2002 Date: Mon, 7 Jan 2002 13:14:53 -0800 From: Ozgur C Leonard To: lee.duncan@sun.com Cc: jek3@eng.sun.com, psarc-record@sac.eng.sun.com Subject: Re: PSARC 2001/329 ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Content-Length: 1821 On Sun, Dec 30, 2001 at 04:48:27PM -0700, Lee Duncan wrote: > Hi Ozgur: > > My name is Lee Duncan, and I'm writing the opinion on your PSARC case > from last year, 2001/329: New Size Suffixes for mount_tmpfs and > mount_xmemfs. > > As I refreshed my memory by going through the mail file in the case > directory, I see that you agreed to remove the "b" suffix from your > proposal because of possible confusion with other utilities that use > "b" to mean "512-byte blocks". I just wanted to make sure that was > actually the way you implemented your changes before I write the > official opinion. My apologies; I was on vacation and I've been going through the past month's emails today. I actually didn't implement any of these (because I was waiting for the opinion to be written), but the description included above is the one finally agreed on at PSARC. Thanks for the follow-up Ozgur > To refresh your memory (since it *has* been a while), you replied to a > question by James Carlson with: > > Ozgur> However, as mkfile(1) and od(1) both take 'b' to mean '512 > Ozgur> bytes', and as there is nothing particularly special about the > Ozgur> number 512 as xmemfs and tmpfs are concerned (a block is equal > Ozgur> to the default pagesize on tmpfs, and can be user-specified on > Ozgur> xmemfs), I would be willing to drop the proposal for the 'b' > Ozgur> suffix altogether. > > Ozgur> The set of supported suffixes would thus be expanded to [kmgt] > Ozgur> (and their uppercase counterparts) for tmpfs, and xmemfs would > Ozgur> not be modified. > > I'll start writing the opinion assuming this is correct (since it's > currently during the winter break), but please confirm this. > > Thanks (and I hope you had a good holiday, by the way (;o)) > -- > LeeD > > "This is not my house." -- David Byrne From sac-owner Mon Jan 7 14:31:30 2002 X-Authentication-Warning: opulent.Central.Sun.COM: lduncan set sender to lduncan@central.Sun.COM using -f From: Lee Duncan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 7 Jan 2002 15:32:12 -0700 To: psarc@sac.eng.sun.com CC: Ozgur Leonard Subject: Please review Opinion for PSARC/2001/329: New Size Suffixes X-Disclaimer: My opinions are so off the wall that nobody claims them Content-Length: 3845 Please review the following opinion for PSARC/2001/329: New Size Suffixes for mount_tmpfs(1m) by 1/14/2001. A pretty HTML version is also available at: http://sac.eng/PSARC/2001/329/opinion.html ---------------------------------------------------------------- Sun Microsystems Systems Architecture Committee Subject New Size Suffixes for mount_tmpfs Submitted by Ozgur Leonard File 2001/329/opinion.html Date May 9th, 2001 Joseph Kowalski (opinion written by Lee Duncan), Lisa Committee Camesano, Ralph Campbell, John Danielson, Terrence Miller, Andy Rudoff, Glenn Skinner, Andrew Tucker Steering CommitteeSOESC 1. Summary This case enhances the mount_tmpfs(1m) command so that sizes can be specified to it in kilobytes, megabytes, gigabytes, and terabytes using standard abbreviations. Previously, only kilobytes and megabytes could be specified. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in an update/patch release of Solaris 3. Interfaces Interfaces Exported Interface Name Classification Comment New size suffixes for "-o Defined by mount_tmpfs(1m) man size=XXX" Standard page 4. Opinion This case was originally proposed as a fast track with a fair amount of email discussion, which centered on the following areas. 4.1 Use of "b" To Mean Bytes The original proposal suggested the suffix "b" stand for bytes, but committee members suggested this conflicted with some existing commands, such as od(1) and mkfile(1), where a size suffix of "b" is taken to mean 512-byte blocks. In addition, a suffix is not needed as a shortcut to mean bytes, since a number with no suffix already means bytes. 4.2 Support of "t" To Mean Terabytes The original proposal did not suggest a suffix for terabytes, but agreed to add it after discussion with the committee showed general agreement that planning for future (larger) amounts of memory usage would be wise. 4.3 Which mount(1m) Subcommands To Update The project team originally suggested updating the mount_xmemfs(1m) command as well as mount_tmpfs(1m), but because of size limitations in mount_xmemfs(1m) on the IA32 platform, this command did not need the terabyte suffix. Since mount_xmemfs(1m) already supported all the other suffixes in this proposal, there was no need to update it. 4.4 Need For A Common Standard and Library Some members of the committee felt that some sort of library routine or routines should be created to parse size specifications, including the suffix. In this way, the duplicate work each command currently has to do to parse these values is consolidated. In addition, this would ensure that all commands using this interface interpreted size suffixes in the same way, reducing end-user confusion. The project team agreed in principal, but said that even if such a library existed, it would require major changes in this particular case to use such a library. The committee did not want to impede this project for a long-standing problem, so reluctantly agreed. 5. Minority Opinion(s) None. 6. Advisory Information The review committee advises the steering committee that some thought should be given to creating a standard specification for size suffixes. This standard could be implemented as one or more common library routines, thus eliminating duplication and end-user confusion. Appendices Appendix A: Technical Changes Required None Appendix B: Technical Changes Advised None Appendix C: Reference Material Unless otherwise stated, path names are relative to the case directory (PSARC/2001/329). 1. mail case mail log file From sac-owner Mon Jan 14 15:40:59 2002 X-Authentication-Warning: opulent.Central.Sun.COM: lduncan set sender to Lee.Duncan@Sun.COM using -f From: Lee Duncan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 14 Jan 2002 16:41:40 -0700 To: sac-review@sac.eng.sun.com CC: Ozgur Leonard Subject: Please review Opinion for PSARC/2001/329: New Size Suffixes X-Disclaimer: My opinions are so off the wall that nobody claims them Content-Length: 3847 Please review the following opinion for PSARC/2001/329: New Size Suffixes for mount_tmpfs(1m) by 1/21/2001. An HTML version is also available at: http://sac.eng/PSARC/2001/329/opinion.html ---------------------------------------------------------------- Sun Microsystems Systems Architecture Committee Subject New Size Suffixes for mount_tmpfs Submitted by Ozgur Leonard File 2001/329/opinion.html Date May 9th, 2001 Joseph Kowalski (opinion written by Lee Duncan), Lisa Committee Camesano, Ralph Campbell, John Danielson, Terrence Miller, Andy Rudoff, Glenn Skinner, Andrew Tucker Steering Committee SOESC 1. Summary This case enhances the mount_tmpfs(1m) command so that sizes can be specified to it in kilobytes, megabytes, gigabytes, and terabytes using standard abbreviations. Previously, only kilobytes and megabytes could be specified. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in an update/patch release of Solaris 3. Interfaces Interfaces Exported Interface Name Classification Comment New size suffixes for "-o Defined by mount_tmpfs(1m) man size=XXX" Standard page 4. Opinion This case was originally proposed as a fast track with a fair amount of email discussion, which centered on the following areas. 4.1 Use of "b" To Mean Bytes The original proposal suggested the suffix "b" stand for bytes, but committee members suggested this conflicted with some existing commands, such as od(1) and mkfile(1), where a size suffix of "b" is taken to mean 512-byte blocks. In addition, a suffix is not needed as a shortcut to mean bytes, since a number with no suffix already means bytes. 4.2 Support of "t" To Mean Terabytes The original proposal did not suggest a suffix for terabytes, but agreed to add it after discussion with the committee showed general agreement that planning for future (larger) amounts of memory usage would be wise. 4.3 Which mount(1m) Subcommands To Update The project team originally suggested updating the mount_xmemfs(1m) command as well as mount_tmpfs(1m), but because of size limitations in mount_xmemfs(1m) on the IA32 platform, this command did not need the terabyte suffix. Since mount_xmemfs(1m) already supported all the other suffixes in this proposal, there was no need to update it. 4.4 Need For A Common Standard and Library Some members of the committee felt that some sort of library routine or routines should be created to parse size specifications, including the suffix. In this way, the duplicate work each command currently has to do to parse these values is consolidated. In addition, this would ensure that all commands using this interface interpreted size suffixes in the same way, reducing end-user confusion. The project team agreed in principal, but said that even if such a library existed, it would require major changes in this particular case to use such a library. The committee did not want to impede this project for a long-standing problem, so reluctantly agreed. 5. Minority Opinion(s) None. 6. Advisory Information The review committee advises the steering committee that some thought should be given to creating a standard specification for size suffixes. This standard could be implemented as one or more common library routines, thus eliminating duplication and end-user confusion. Appendices Appendix A: Technical Changes Required None Appendix B: Technical Changes Advised None Appendix C: Reference Material Unless otherwise stated, path names are relative to the case directory (PSARC/2001/329). 1. mail case mail log file From sac-owner Tue Jan 22 11:57:20 2002 X-Authentication-Warning: opulent.Central.Sun.COM: lduncan set sender to Lee.Duncan@Sun.COM using -f From: Lee Duncan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 22 Jan 2002 12:58:04 -0700 To: sac-opinion@sac.eng.sun.com, soesc-opinion@sac.eng.sun.com, psarc-record@sac.eng.sun.com CC: Ozgur Leonard Subject: Opinion for PSARC//2001/329: New Size Suffixes X-Disclaimer: My opinions are so off the wall that nobody claims them Content-Length: 3786 Also available as: http://sac.eng/PSARC/2001/329/opinion.txt (included below) http://sac.eng/PSARC/2001/329/opinion.html ---------------------------------------------------------------- Sun Microsystems Systems Architecture Committee Subject New Size Suffixes for mount_tmpfs Submitted by Ozgur Leonard File PSARC/2001/329/opinion.html Date May 9th, 2001 Joseph Kowalski (opinion written by Lee Duncan), Lisa Committee Camesano, Ralph Campbell, John Danielson, Terrence Miller, Andy Rudoff, Glenn Skinner, Andrew Tucker Steering Committee SOESC 1. Summary This case enhances the mount_tmpfs(1m) command so that sizes can be specified to it in kilobytes, megabytes, gigabytes, and terabytes using standard abbreviations. Previously, only kilobytes and megabytes could be specified. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in an update/patch release of Solaris 3. Interfaces Interfaces Exported Interface Name Classification Comment New size suffixes for "-o Defined by mount_tmpfs(1m) man size=XXX" Standard page 4. Opinion This case was originally proposed as a fast track with a fair amount of email discussion, which centered on the following areas. 4.1 Use of "b" To Mean Bytes The original proposal suggested the suffix "b" stand for bytes, but committee members suggested this conflicted with some existing commands, such as od(1) and mkfile(1), where a size suffix of "b" is taken to mean 512-byte blocks. In addition, a suffix is not needed as a shortcut to mean bytes, since a number with no suffix already means bytes. 4.2 Support of "t" To Mean Terabytes The original proposal did not suggest a suffix for terabytes, but agreed to add it after discussion with the committee showed general agreement that planning for future (larger) amounts of memory usage would be wise. 4.3 Which mount(1m) Subcommands To Update The project team originally suggested updating the mount_xmemfs(1m) command as well as mount_tmpfs(1m), but because of size limitations in mount_xmemfs(1m) on the IA32 platform, this command did not need the terabyte suffix. Since mount_xmemfs(1m) already supported all the other suffixes in this proposal, there was no need to update it. 4.4 Need For A Common Standard and Library Some members of the committee felt that some sort of library routine or routines should be created to parse size specifications, including the suffix. In this way, the duplicate work each command currently has to do to parse these values is consolidated. In addition, this would ensure that all commands using this interface interpreted size suffixes in the same way, reducing end-user confusion. The project team agreed in principle, but said that even if such a library existed, it would require major changes in this particular case to use such a library. The committee did not want to impede this project for a long-standing problem, so reluctantly agreed. 5. Minority Opinion(s) None. 6. Advisory Information The review committee advises the steering committee that some thought should be given to creating a standard specification for size suffixes. This standard could be implemented as one or more common library routines, thus eliminating duplication and end-user confusion. Appendices Appendix A: Technical Changes Required None Appendix B: Technical Changes Advised None Appendix C: Reference Material Unless otherwise stated, path names are relative to the case directory (PSARC/2001/329). 1. mail case mail log file