diff mbox series

[v9,2/9] include: Add a lookup table of sizes

Message ID 20180918152923.24824-3-lbloch@janustech.com
State New
Headers show
Series Take the image size into account when allocating the L2 cache | expand

Commit Message

Leonid Bloch Sept. 18, 2018, 3:29 p.m. UTC
Adding a lookup table for the powers of two, with the appropriate size
prefixes. This is needed when a size has to be stringified, in which
case something like '(1 * KiB)' would become a literal '(1 * (1L << 10))'
string. Powers of two are used very often for sizes, so such a table
will also make it easier and more intuitive to write them.

This table is generatred using the following AWK script:

BEGIN {
	suffix="KMGTPE";
	for(i=10; i<64; i++) {
		val=2**i;
		s=substr(suffix, int(i/10), 1);
		n=2**(i%10);
		pad=21-int(log(n)/log(10));
		printf("#define S_%d%siB %*d\n", n, s, pad, val);
	}
}

Signed-off-by: Leonid Bloch <lbloch@janustech.com>
---
 include/qemu/units.h | 55 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

Comments

Alberto Garcia Sept. 21, 2018, 12:17 p.m. UTC | #1
On Tue 18 Sep 2018 05:29:16 PM CEST, Leonid Bloch wrote:
> Adding a lookup table for the powers of two, with the appropriate size
> prefixes. This is needed when a size has to be stringified, in which
> case something like '(1 * KiB)' would become a literal '(1 * (1L <<
> 10))' string. Powers of two are used very often for sizes, so such a
> table will also make it easier and more intuitive to write them.

I wonder in what cases you want to stringify those literals... if it's
something that you want to show the user you either:

  a) know the value in advance, and then you probably want to show
     "4 GiB" instead of "4294967296 bytes"

  b) don't know the value in advance (it's a variable), but then you
     can't use these macros.

Am I missing anything?

Berto
Leonid Bloch Sept. 21, 2018, 1:43 p.m. UTC | #2
On 9/21/18 3:17 PM, Alberto Garcia wrote:
> On Tue 18 Sep 2018 05:29:16 PM CEST, Leonid Bloch wrote:
>> Adding a lookup table for the powers of two, with the appropriate size
>> prefixes. This is needed when a size has to be stringified, in which
>> case something like '(1 * KiB)' would become a literal '(1 * (1L <<
>> 10))' string. Powers of two are used very often for sizes, so such a
>> table will also make it easier and more intuitive to write them.
> 
> I wonder in what cases you want to stringify those literals... if it's
> something that you want to show the user you either:
> 
>    a) know the value in advance, and then you probably want to show
>       "4 GiB" instead of "4294967296 bytes"

Then the value will need to be set in two places at any future change.

> 
>    b) don't know the value in advance (it's a variable), but then you
>       can't use these macros.
> 
> Am I missing anything?

This is needed in some places:

$ ag 'stringify\(DEFAULT_CLUSTER_SIZE\)'
block/parallels.c
99:            .def_value_str = stringify(DEFAULT_CLUSTER_SIZE),

block/vdi.c
988:            .def_value_str = stringify(DEFAULT_CLUSTER_SIZE)

block/qcow2.c
4726:            .def_value_str = stringify(DEFAULT_CLUSTER_SIZE)

The latter causes failure in test case 137 if defined as (64 * KiB).

Of course the values in block/parallels.h and block/vdi.c will need to 
be changed as well, I'll do it in a separate patch.

Besides resolving the cases with the necessity to stringify, It also 
creates nice shortcuts for all feasible power-of-two sizes, which are 
very common.

Leonid.

> 
> Berto
>
diff mbox series

Patch

diff --git a/include/qemu/units.h b/include/qemu/units.h
index 692db3fbb2..68a7758650 100644
--- a/include/qemu/units.h
+++ b/include/qemu/units.h
@@ -17,4 +17,59 @@ 
 #define PiB     (INT64_C(1) << 50)
 #define EiB     (INT64_C(1) << 60)
 
+#define S_1KiB                  1024
+#define S_2KiB                  2048
+#define S_4KiB                  4096
+#define S_8KiB                  8192
+#define S_16KiB                16384
+#define S_32KiB                32768
+#define S_64KiB                65536
+#define S_128KiB              131072
+#define S_256KiB              262144
+#define S_512KiB              524288
+#define S_1MiB               1048576
+#define S_2MiB               2097152
+#define S_4MiB               4194304
+#define S_8MiB               8388608
+#define S_16MiB             16777216
+#define S_32MiB             33554432
+#define S_64MiB             67108864
+#define S_128MiB           134217728
+#define S_256MiB           268435456
+#define S_512MiB           536870912
+#define S_1GiB            1073741824
+#define S_2GiB            2147483648
+#define S_4GiB            4294967296
+#define S_8GiB            8589934592
+#define S_16GiB          17179869184
+#define S_32GiB          34359738368
+#define S_64GiB          68719476736
+#define S_128GiB        137438953472
+#define S_256GiB        274877906944
+#define S_512GiB        549755813888
+#define S_1TiB         1099511627776
+#define S_2TiB         2199023255552
+#define S_4TiB         4398046511104
+#define S_8TiB         8796093022208
+#define S_16TiB       17592186044416
+#define S_32TiB       35184372088832
+#define S_64TiB       70368744177664
+#define S_128TiB     140737488355328
+#define S_256TiB     281474976710656
+#define S_512TiB     562949953421312
+#define S_1PiB      1125899906842624
+#define S_2PiB      2251799813685248
+#define S_4PiB      4503599627370496
+#define S_8PiB      9007199254740992
+#define S_16PiB    18014398509481984
+#define S_32PiB    36028797018963968
+#define S_64PiB    72057594037927936
+#define S_128PiB  144115188075855872
+#define S_256PiB  288230376151711744
+#define S_512PiB  576460752303423488
+#define S_1EiB   1152921504606846976
+#define S_2EiB   2305843009213693952
+#define S_4EiB   4611686018427387904
+#define S_8EiB   9223372036854775808
+
 #endif