diff options
author | Hanna Reitz <hreitz@redhat.com> | 2022-06-20 18:26:55 +0200 |
---|---|---|
committer | Kevin Wolf <kwolf@redhat.com> | 2023-02-01 16:52:33 +0100 |
commit | 456e75171a85c19a5bfa202eefcbdc4ef1692f05 (patch) | |
tree | ad52dd1e50cce7293f0e1b363716ba298a0281b0 /job.c | |
parent | 7f36a50ab4e7d39369cac67be4ba9d6ee4081dc0 (diff) | |
download | qemu-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 'job.c')
0 files changed, 0 insertions, 0 deletions