qemu-devel
[Top][All Lists]
Advanced

[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
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]