block: Allow NULL file for bdrv_get_block_status()
commit298a1665a2800f7264e483c2dd1f551574243a2f
authorEric Blake <eblake@redhat.com>
Thu, 12 Oct 2017 03:46:57 +0000 (11 22:46 -0500)
committerKevin Wolf <kwolf@redhat.com>
Thu, 26 Oct 2017 12:45:57 +0000 (26 14:45 +0200)
tree74d8d30bf06f312a0d343e883854eb1af83dce5d
parent760c4d43ae43f5d4b5eec450a53f056c3c91fab1
block: Allow NULL file for bdrv_get_block_status()

Not all callers care about which BDS owns the mapping for a given
range of the file.  This patch merely simplifies the callers by
consolidating the logic in the common call point, while guaranteeing
a non-NULL file to all the driver callbacks, for no semantic change.
The only caller that does not care about pnum is bdrv_is_allocated,
as invoked by vvfat; we can likewise add assertions that the rest
of the stack does not have to worry about a NULL pnum.

Furthermore, this will also set the stage for a future cleanup: when
a caller does not care about which BDS owns an offset, it would be
nice to allow the driver to optimize things to not have to return
BDRV_BLOCK_OFFSET_VALID in the first place.  In the case of fragmented
allocation (for example, it's fairly easy to create a qcow2 image
where consecutive guest addresses are not at consecutive host
addresses), the current contract requires bdrv_get_block_status()
to clamp *pnum to the limit where host addresses are no longer
consecutive, but allowing a NULL file means that *pnum could be
set to the full length of known-allocated data.

Signed-off-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
block/io.c
block/mirror.c
block/qcow2.c
include/block/block_int.h
qemu-img.c