On 10/16/2014 09:27 AM, Max Reitz wrote: >>> + memset(*refcount_table + old_nb_clusters, 0, >>> + (*nb_clusters - old_nb_clusters) * sizeof(uint16_t)); >> Is this calculation unnecessarily hard-coded to refcount_order==4? > > While now in the process of editing this patch, no, this is not > hard-coded to that refcount_order. It's hard-coded to *refcount_table > being uint16_t *. I think this fine.
Correct - our choice of uint16_t* is what hard-codes our current dependence on refcount_order==4, and we assert that is the case elsewhere. > Making the in-memory refcount table > support variable refcount orders would be pretty hard and in fact we do > not need it before we actually support other refcount_orders. Agreed. Particularly for refcount orders < 3, where you pack more than one refcount in a single byte. > When doing > that, I (or anyone else) will probably add some function read_refcount() > which reads a refcount from a refcount block or a concatenation of > refblocks (such as this in-memory refcount table) while taking into > account a variable refcount_order. When that is done, we can rework this > code. Fair enough. Don't hold up this series for that future improvement. > > But for now it's fine to make the in-memory refcount table entries > uint16_t, which is the reason for all the sizeof(uint16_t). > > Max > > -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
