On 05.03.2014 17:11, Benoît Canet wrote:
The Monday 03 Mar 2014 à 16:28:48 (+0100), Max Reitz wrote :
Implement this function in the same way as raw_bsd does: Acknowledge
that this is a passthrough driver (always return BDRV_BLOCK_OFFSET_VALID
and BDRV_BLOCK_DATA and derive the offset directly from the sector
index) and add BDRV_BLOCK_RAW to the returned value.
Signed-off-by: Max Reitz <address@hidden>
---
block/json.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/block/json.c b/block/json.c
index a2f4691..7392802 100644
--- a/block/json.c
+++ b/block/json.c
@@ -113,6 +113,14 @@ static coroutine_fn int
json_co_write_zeroes(BlockDriverState *bs,
return bdrv_co_write_zeroes(bs, sector_num, nb_sectors, flags);
}
+static coroutine_fn int64_t json_co_get_block_status(BlockDriverState *bs,
+ int64_t sector_num,
+ int nb_sectors, int *pnum)
+{
+ return BDRV_BLOCK_RAW | BDRV_BLOCK_OFFSET_VALID | BDRV_BLOCK_DATA |
+ (sector_num << BDRV_SECTOR_BITS);
+}
I don't understand what is the selling point of this method instead of calling
bdrv_co_get_block_status on bs->file.
Some information risk to be lost and it does look like magic.
This is the same what "raw" does. It just is more meaningful: This
way, this function does not pretend to provide the blocks itself but
instead tells the truth; that is, the blocks are provided by an
underlying BDS (bs->file).
I wasn't really sure what to do myself. Generally, this driver is
actually meant to pretend that it provides the blocks itself. On the
other hand, I tried to imitate the behavior or "raw", since this is
something I can hope to be approximately correct. Also, as I've said
before, the value returned here is in fact at least technically
correct.