[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 2/5] vmdk: Implement .bdrv_co_create callback
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH v4 2/5] vmdk: Implement .bdrv_co_create callback |
Date: |
Fri, 07 Dec 2018 14:04:00 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Markus Armbruster <address@hidden> writes:
> Kevin Wolf <address@hidden> writes:
>
>> From: Fam Zheng <address@hidden>
>>
>> This makes VMDK support blockdev-create. The implementation reuses the
>> image creation code in vmdk_co_create_opts which now acceptes a callback
>> pointer to "retrieve" BlockBackend pointers from the caller. This way we
>> separate the logic between file/extent acquisition and initialization.
>>
>> The QAPI command parameters are mostly the same as the old create_opts
>> except the dropped legacy @compat6 switch, which is redundant with
>> @hwversion.
>>
>> Signed-off-by: Fam Zheng <address@hidden>
>> Signed-off-by: Kevin Wolf <address@hidden>
>> ---
>> qapi/block-core.json | 70 +++++++
>> qapi/qapi-schema.json | 16 +-
>> block/vmdk.c | 448 ++++++++++++++++++++++++++++++------------
>> 3 files changed, 400 insertions(+), 134 deletions(-)
>>
>> diff --git a/qapi/block-core.json b/qapi/block-core.json
>> index d4fe710836..0793550cf2 100644
>> --- a/qapi/block-core.json
>> +++ b/qapi/block-core.json
[...]
>> +##
>> +# @BlockdevCreateOptionsVmdk:
>> +#
>> +# Driver specific image creation options for VMDK.
>> +#
>> +# @file Where to store the new image file. This refers to the image
>> +# file for monolithcSparse and streamOptimized format, or the
>> +# descriptor file for other formats.
>> +# @size Size of the virtual disk in bytes
>> +# @extents Where to store the data extents. Required for monolithcFlat,
>> +# twoGbMaxExtentSparse and twoGbMaxExtentFlat formats. For
>> +# monolithicFlat, only one entry is required; for
>> +# twoGbMaxExtent* formats, the number of entries required is
>> +# calculated as extent_number = virtual_size / 2GB.
>
> Doesn't quite spell out that the number of extents has to match
> exactly. I'm not sure I care.
Nevermind, you address that in PATCH 5.
[...]