Re: [Qemu-devel] ping Re: [PATCH 0/6] misc vvfat fixes

[Kevin Wolf <kwolf@redhat.com>]

Am 27.10.2011 15:10, schrieb Paolo Bonzini:
> On 10/27/2011 02:38 PM, Kevin Wolf wrote:
>> Am 27.10.2011 13:46, schrieb Paolo Bonzini:
>>> On 10/05/2011 09:12 AM, Paolo Bonzini wrote:
>>>> It occurred to me that, if there's one thing vvfat ought to be good
>>>> at, it is creating disk images with qemu-img convert (a driver disk
>>>> in my case).
>>>>
>>>> It turns out the use case is really broken.  qemu-img doesn't
>>>> complete at all, the resulting images often do not pass fsck,
>>>> and it's impossible to create a 1.44 MB disk image.  This
>>>> series fixes all of the small problems I found.
>>>>
>>>> Coding standard in this file is such a pain that I hardly bothered
>>>> about it.
>>>>
>>>>
>>>> Paolo Bonzini (6):
>>>>     vvfat: fix out of bounds array_get usage
>>>>     vvfat: do not fail if the disk has spare sectors the
>>>>     vvfat: need to use first_sectors_number to distinguish fdd/hdd
>>>>     vvfat: unify and correct computation of sector count
>>>>     vvfat: do not hardcode sector counts in error message
>>>>     vvfat: reorganize computation of disk geometry
>>>>
>>>>    block/vvfat.c |   50 ++++++++++++++++++++++++--------------------------
>>>>    3 files changed, 26 insertions(+), 28 deletions(-)
>>>>
>>>
>>> ping?
>>
>> Looked at it a week or two ago, didn't immediately understand the first
>> patch and decided that there's more important stuff for 1.0...
> 
> Yeah.  It can probably go in during the freeze.
> 
> Regarding the first patch, we simply fail this assert:
> 
> static inline void* array_get(array_t* array,unsigned int index) {
>      assert(index < array->next);
>      return array->pointer + index * array->item_size;
> }
> 
> so you need to first set s->directory.next like array_get_next does.

So is this combination of array_ensure_allocated(), setting
s->directory.next and memset() basically an open-coded array_set_size()
that initialises new elements with zeros?

Kevin