diff options
author | Eric Blake <eblake@redhat.com> | 2017-10-11 22:46:57 -0500 |
---|---|---|
committer | Kevin Wolf <kwolf@redhat.com> | 2017-10-26 14:45:57 +0200 |
commit | 298a1665a2800f7264e483c2dd1f551574243a2f (patch) | |
tree | 74d8d30bf06f312a0d343e883854eb1af83dce5d /net | |
parent | 760c4d43ae43f5d4b5eec450a53f056c3c91fab1 (diff) | |
download | qemu-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 'net')
0 files changed, 0 insertions, 0 deletions