qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH v4 2/5] vmdk: Implement .bdrv_co_cr


From: Markus Armbruster
Subject: Re: [Qemu-block] [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.

[...]



reply via email to

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