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

[Eric Blake]

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