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
