[PATCH] ubi_tools: enhance -s option to allow size multiplier to match mtd-utils

[Mike Frysinger]

On Friday 31 May 2013 22:28:03 Paul B. Henson wrote:
> On 5/31/2013 4:34 PM, Mike Frysinger wrote:
> >> +static int get_bytes(const char *str)
> [...]
> > the style is wrong, but ignoring that, this seems like it'd be prime
> > for adding to common libbb code if there isn't a func in there
> > already
> 
> I don't see one. Is there an existing libbb source file you think would
> be suitable to add this function to, or would it be better to add a new
> file?

i think libbb has grown to the point where it needs to start providing its own 
API reference :/.  it's been a while since i hacked seriously on busybox, so 
i've lost touch with much of its deeper layers.

there's a human readable file in there, but that goes the opposite direction 
(int->pretty display)

does the busybox fdisk accept human readable inputs like the util-linux 
version ?  that might be a worthwhile place to poke around.

> This particular internal to ubi_tools implementation was specifically
> tailored to exactly match the mtd-utils implementation, presumably if
> it's going to be made into a general utility function it should be a bit
> more flexible.

hmm, a fair point.  but i'm not sure it's one strong enough to win over.  
consider that busybox subsumes many projects which accept human readable 
inputs.  it's probably safe to assume that they aren't all going to behave 
exactly the same.  should we create duplicate implementations to satisfy them 
all ?  or just take the slightly rough edges for the sake of smaller code ?  
i'm in the latter camp.

> As is, it returns an int and expects a string that exactly matches
> \d+(.{3})?, where the three character suffix is one of case sensitive
> "KiB", "MiB", or "GiB". As a more general utility function, should it
> still return int or another type? Should it be more flexible and accept
> mixed case suffixes, as well as accept the commonly used KB, MB, and GB
> suffixes?

starting with just the binary based names should be fine as then it's 
unambiguous (everyone agrees what 300 MiB represents).  drop a note in there 
that if someone cares to add the other variants (KB/MB/GB and K/M/G), they 
should probably do so using 1000 instead of 1024.

case sensitive probably results in smaller code and people can figure it out 
pretty quickly.

"int" isn't going to fly for 32bit systems (which embedded frequently is).  i 
know some places in the mtd-utils UBI code base still uses it, but we've been 
actively discouraging it (since embedded has long ago moved pass 4GiB flashes).  
the core mtd-utils code (libmtd under lib/) should be 64bit clean which means 
the code that uses that is also forced to go that route.  ubi-utils is almost 
in its own little world, but i've been slowly moving it over to the common 
mtd-utils code.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20130602/a0c3aa0c/attachment.asc>