aboutsummaryrefslogtreecommitdiff
path: root/util/hbitmap.c
diff options
context:
space:
mode:
authorEric Blake <eblake@redhat.com>2017-10-11 22:46:57 -0500
committerKevin Wolf <kwolf@redhat.com>2017-10-26 14:45:57 +0200
commit298a1665a2800f7264e483c2dd1f551574243a2f (patch)
tree74d8d30bf06f312a0d343e883854eb1af83dce5d /util/hbitmap.c
parent760c4d43ae43f5d4b5eec450a53f056c3c91fab1 (diff)
downloadqemu-298a1665a2800f7264e483c2dd1f551574243a2f.zip
qemu-298a1665a2800f7264e483c2dd1f551574243a2f.tar.gz
qemu-298a1665a2800f7264e483c2dd1f551574243a2f.tar.bz2
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>
Diffstat (limited to 'util/hbitmap.c')
0 files changed, 0 insertions, 0 deletions