On Mon, 07/03 17:14, Eric Blake wrote: > 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 <ebl...@redhat.com>
Reviewed-by: Fam Zheng <f...@redhat.com>
