aboutsummaryrefslogtreecommitdiff
path: root/block/vmdk.c
diff options
context:
space:
mode:
authorHanna Reitz <hreitz@redhat.com>2022-06-20 18:26:55 +0200
committerKevin Wolf <kwolf@redhat.com>2023-02-01 16:52:33 +0100
commit456e75171a85c19a5bfa202eefcbdc4ef1692f05 (patch)
treead52dd1e50cce7293f0e1b363716ba298a0281b0 /block/vmdk.c
parent7f36a50ab4e7d39369cac67be4ba9d6ee4081dc0 (diff)
downloadqemu-456e75171a85c19a5bfa202eefcbdc4ef1692f05.zip
qemu-456e75171a85c19a5bfa202eefcbdc4ef1692f05.tar.gz
qemu-456e75171a85c19a5bfa202eefcbdc4ef1692f05.tar.bz2
block/vmdk: Change extent info type
VMDK's implementation of .bdrv_get_specific_info() returns information about its extent files, ostensibly in the form of ImageInfo objects. However, it does not get this information through bdrv_query_image_info(), but fills only a select few fields with custom information that does not always match the fields' purposes. For example, @format, which is supposed to be a block driver name, is filled with the extent type, e.g. SPARSE or FLAT. In ImageInfo, @compressed shows whether the data that can be seen in the image is stored in compressed form or not. For example, a compressed qcow2 image will store compressed data in its data file, but when accessing the qcow2 node, you will see normal data. This is not how VMDK uses the @compressed field for its extent files: Instead, it signifies whether accessing the extent file will yield compressed data (which the VMDK driver then (de-)compresses). Create a new structure to represent the extent information. This allows us to clarify the fields' meanings, and it clearly shows that these are not complete ImageInfo objects. (That is, if a user wants an extent file's ImageInfo object, they will need to query it separately, and will not get it from ImageInfoSpecificVmdk.extents.) Note that this removes the last use of ['ImageInfo'] (i.e. an array of ImageInfo objects), so the QAPI generator will no longer generate ImageInfoList by default. However, we use it in qemu-img.c, so we need to create a dummy object to force the generate to create that type, similarly to DummyForceArrays in machine.json (introduced in commit 9f08c8ec73878122ad4b061ed334f0437afaaa32 ("qapi: Lazy creation of array types")). Signed-off-by: Hanna Reitz <hreitz@redhat.com> Message-Id: <20220620162704.80987-4-hreitz@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'block/vmdk.c')
-rw-r--r--block/vmdk.c8
1 files changed, 4 insertions, 4 deletions
diff --git a/block/vmdk.c b/block/vmdk.c
index 1bba61a..5b0eae8 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -2898,12 +2898,12 @@ static int vmdk_has_zero_init(BlockDriverState *bs)
return 1;
}
-static ImageInfo *vmdk_get_extent_info(VmdkExtent *extent)
+static VmdkExtentInfo *vmdk_get_extent_info(VmdkExtent *extent)
{
- ImageInfo *info = g_new0(ImageInfo, 1);
+ VmdkExtentInfo *info = g_new0(VmdkExtentInfo, 1);
bdrv_refresh_filename(extent->file->bs);
- *info = (ImageInfo){
+ *info = (VmdkExtentInfo){
.filename = g_strdup(extent->file->bs->filename),
.format = g_strdup(extent->type),
.virtual_size = extent->sectors * BDRV_SECTOR_SIZE,
@@ -2982,7 +2982,7 @@ static ImageInfoSpecific *vmdk_get_specific_info(BlockDriverState *bs,
int i;
BDRVVmdkState *s = bs->opaque;
ImageInfoSpecific *spec_info = g_new0(ImageInfoSpecific, 1);
- ImageInfoList **tail;
+ VmdkExtentInfoList **tail;
*spec_info = (ImageInfoSpecific){
.type = IMAGE_INFO_SPECIFIC_KIND_VMDK,