Re: [RFC 0/3] 64bit block-layer part I

[Eric Blake <eblake@redhat.com>]

On 4/22/20 1:24 PM, Vladimir Sementsov-Ogievskiy wrote:

>> So, I think the simplest way is to add .bdrv_co_pwritev_zeros64 and
>> .bdrv_co_pdiscard64 and update drivers one-by-one. If at some point all
>> drivers updated - drop unused 32bit functions, and then drop "64" suffix
>> from API. If not - we'll live with both APIs.
> 
> Hmm. Or, maybe nothing dangerous if we convert it to 64bit, and add 
> comment,
> that function is not actually prepared for 64bit bytes and depends on
> max_transfer/max_zeroes being <= INT_MAX ?
> 
> Or, maybe better, keep old functions as is and add 64bit wrappers, which
> assert that bytes < INT_MAX, and call old function? This is clean, driver
> maybe updated later on demand, and we don't need extra API. If no 
> objections,
> I'll try this way in the next version.

That approach sounds good; it matches how we added flags and iov 
support, as well as how we transitioned from sector interfaces over to 
byte interfaces: we added a new .bdrv_ callback for the drivers that 
could take advantage of the increased interface, without having to touch 
the older drivers using the old callbacks, then only later finally got 
rid of the old interfaces as we modernized other drivers.  There's still 
the issue of how much we convert in the initial series - even if adding 
a new wrapper makes it easier to patch only one driver at a time, it's 
not nice to leave the job half-done by not visiting all of the drivers 
eventually.

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