[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v8 20/21] vvfat: Switch to .bdrv_co_block_status

From: Eric Blake
Subject: Re: [Qemu-block] [PATCH v8 20/21] vvfat: Switch to .bdrv_co_block_status()
Date: Wed, 14 Feb 2018 08:50:39 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 02/14/2018 07:12 AM, Kevin Wolf wrote:
Am 13.02.2018 um 21:27 hat Eric Blake geschrieben:
We are gradually moving away from sector-based interfaces, towards
byte-based.  Update the vvfat driver accordingly.  Note that we
can rely on the block driver having already clamped limits to our
block size, and simplify accordingly.

Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
Reviewed-by: Fam Zheng <address@hidden>

-    *n = bs->total_sectors - sector_num;
-    if (*n > nb_sectors) {
-        *n = nb_sectors;
-    } else if (*n < 0) {
-        return 0;
-    }
+    *n = bytes;
      return BDRV_BLOCK_DATA;

Preexisting, but this is inconsistent with other protocol drivers as far
as OFFSET_VALID is concerned (as I hinted in another mail, I like it
better this way, but it's still inconsistent).

Do we actually need any callback here or could the solution be to simply
remove it like with nvme?

Does that mean io.c's defaults for protocol drivers is wrong? It defaults to setting OFFSET_VALID and *map on all protocol drivers without a callback (at least nvme, nbd); I didn't delete this callback because I noticed the difference in return value, and couldn't justify whether it was intentional. Also, vvfat is weird - it is somewhat of a format driver, rather than just a protocol; even though it sets .protocol_name. It may be possible for vvfat to actually set OFFSET_VALID to particular offsets within the host file that correspond to what the guest would read, where it is not a simple 1:1 mapping, precisely because it is imposing format on the host file. However, vvfat is one of those things that I try to avoid as much as possible, because it is just so weird.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]