On 04/03/07 06:04, Pawel Jakub Dawidek wrote: > On Mon, Apr 02, 2007 at 11:56:24PM -0500, Eric Anderson wrote: >> Here is a patch that adds that functionality. Can be found here: >> >> http://www.googlebit.com/freebsd/patches/gjournal_size_expression.patch >> >> and attached. > > Thanks for the patch. I'd prefer to have such functionality as a part of > libutil. Simlar to humanize_number(3), but the other way around. > Some comments below. Like this: http://www.googlebit.com/freebsd/patches/libutil-unhumanized.patch (and attached) >> + * Convert an expression of the following forms to a uintmax_t. >> + * 1) A positive decimal number. >> + * 2) A positive decimal number followed by a 'b' or 'B' (mult by 512). > > Why? If I give '-s 1024B' it means I want 1024 bytes, not 1024*512 > bytes. I would multiply by 512 if I receive number of sectors or > something. My suggestion is to accept 'b' and 'B', but ignore it (or > multiply by 1). Yes, true. B should mean bytes, not blocks.. [FIXED] >> + * 3) A positive decimal number followed by a 'k' or 'K' (mult by 1 << 10). >> + * 4) A positive decimal number followed by a 'm' or 'M' (mult by 1 << 20). >> + * 5) A positive decimal number followed by a 'g' or 'G' (mult by 1 << 30). > > I'd add 't' and 'T' as well. [ADDED] >> + * 5) A positive decimal number followed by a 'w' or 'W' (mult by sizeof int). > > I suggest dropping it, I don't really see a use for it... [REMOVED] New gjournal patch is here: http://www.googlebit.com/freebsd/patches/gjournal_size_expression-libutil.patch (and attached) It now also needs the libutil patch above. The man page for the unhumanize_number function is crude, so it should be looked over also. Comments please!! Eric
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:07 UTC