[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 35/45] add hierarchical bitmap data type and
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH v2 35/45] add hierarchical bitmap data type and test cases |
Date: |
Wed, 24 Oct 2012 16:50:19 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 |
Il 24/10/2012 16:41, Kevin Wolf ha scritto:
>> +struct HBitmapIter {
>> + const HBitmap *hb;
>> +
>> + /* Copied from hb for access in the inline functions (hb is opaque). */
>> + int granularity;
>> +
>> + /* Entry offset into the last-level array of longs. */
>> + size_t pos;
>
> Other places, for example HBitmap.size/count and the local pos variable
> in hbitmap_iter_skip_words(), use uint64_t. Why is size_t here enough?
size_t is enough if it is a word position. uint64_t is necessary if it
is a bit position. This line of hbitmap_iter_next explains it well:
item = ((uint64_t)hbi->pos << BITS_PER_LEVEL) + ffsl(cur) - 1;
Here the word position hbi->pos is converted to a bit position, so we
need to convert size_t to uint64_t.
In fact, hbitmap_iter_skip_words could indeed use a size_t. It uses
uint64_t because the line above used to be in hbitmap_iter_skip_words,
and used pos instead of hbi->pos. With that code, using uint64_t saved
a cast.
Paolo
>
>> +
>> + /* The currently-active path in the tree. Each item of cur[i] stores
>> + * the bits (i.e. the subtrees) yet to be processed under that node.
>> + */
>> + unsigned long cur[HBITMAP_LEVELS];
>> +};
>
> Kevin
>