diff options
| author | Eric Blake | 2017-10-12 05:46:57 +0200 |
|---|---|---|
| committer | Kevin Wolf | 2017-10-26 14:45:57 +0200 |
| commit | 298a1665a2800f7264e483c2dd1f551574243a2f (patch) | |
| tree | 74d8d30bf06f312a0d343e883854eb1af83dce5d /scripts/modules/module_block.py | |
| parent | qemu-iotests: Test backing_fmt with backing node reference (diff) | |
| download | qemu-298a1665a2800f7264e483c2dd1f551574243a2f.tar.gz qemu-298a1665a2800f7264e483c2dd1f551574243a2f.tar.xz qemu-298a1665a2800f7264e483c2dd1f551574243a2f.zip | |
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 'scripts/modules/module_block.py')
0 files changed, 0 insertions, 0 deletions
