Re: [RFC PATCH v2 06/25] include/block/block_int: split header into I/O and global state API

[Stefan Hajnoczi]

On Thu, Oct 07, 2021 at 01:30:42PM +0200, Emanuele Giuseppe Esposito wrote:
> 
> 
> On 07/10/2021 12:52, Stefan Hajnoczi wrote:
> > On Tue, Oct 05, 2021 at 10:31:56AM -0400, Emanuele Giuseppe Esposito wrote:
> > > +int coroutine_fn bdrv_co_copy_range_from(BdrvChild *src, int64_t 
> > > src_offset,
> > > +                                         BdrvChild *dst, int64_t 
> > > dst_offset,
> > > +                                         int64_t bytes,
> > > +                                         BdrvRequestFlags read_flags,
> > > +                                         BdrvRequestFlags write_flags);
> > > +int coroutine_fn bdrv_co_copy_range_to(BdrvChild *src, int64_t 
> > > src_offset,
> > > +                                       BdrvChild *dst, int64_t 
> > > dst_offset,
> > > +                                       int64_t bytes,
> > > +                                       BdrvRequestFlags read_flags,
> > > +                                       BdrvRequestFlags write_flags);
> > 
> > These look like I/O APIs to me. Are they in the GS API because only
> > qemu-img.c call copy_range? I thought SCSI emulation might call it too,
> > but grep says otherwise.
> 
> SCSI (iscsi.c) implements the function pointer
> (*bdrv_co_copy_range_from/to), but does not call the function itself.
> However, later in the patches I put the function pointer as I/O.

I meant the SCSI target emulation in hw/scsi/ where the SCSI commands
that require copy_range could be handled.

> These two functions are only tested by test-replication and thus are always
> under BQL when tested. But after looking at them again, and since they
> internally use only I/O APIs, I think we can move them to the I/O API.

Okay, great.

Stefan

signature.asc
Description: PGP signature