[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/2] block-copy: small fix and refactor
From: |
Kevin Wolf |
Subject: |
Re: [PATCH 0/2] block-copy: small fix and refactor |
Date: |
Mon, 7 Jun 2021 17:10:03 +0200 |
Am 03.06.2021 um 09:38 hat Paolo Bonzini geschrieben:
> On 02/06/21 14:21, Kevin Wolf wrote:
> > Am 02.06.2021 um 11:13 hat Stefan Hajnoczi geschrieben:
> > > On Fri, May 28, 2021 at 05:16:26PM +0300, Vladimir Sementsov-Ogievskiy
> > > wrote:
> > > > Hi all!
> > > >
> > > > This is my suggestion how to refactor block-copy to avoid extra atomic
> > > > operations in
> > > > "[PATCH v2 0/7] block-copy: protect block-copy internal structures"
> > > >
> > > > Vladimir Sementsov-Ogievskiy (2):
> > > > block-copy: fix block_copy_task_entry() progress update
> > > > block-copy: refactor copy_range handling
> > > >
> > > > block/block-copy.c | 79 +++++++++++++++++++++++++++++++---------------
> > > > 1 file changed, 53 insertions(+), 26 deletions(-)
> > >
> > > I posted suggestions for the doc comment on Patch 2, otherwise:
> > >
> > > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> >
> > Thanks, fixed up the comment accordingly and applied to the block
> > branch.
>
> I'm a bit confused. Vladimir said in his review of Emanuele's patches
> that he was okay with patch 7 and that he would rebase this
> refactoring on top of it.
>
> Vladimir's main complaint for the s->method state machine was the
> extra lines of code. Here we have just as many new lines of code and
> new parameters that are passed by reference. Kevin, can you please
> look at Emanuele's patches and possibly unqueue the second patch here?
> It seems to me that it should have been tagged as RFC.
Sorry, I was not aware that Vladimir intended to rebase this one. This
has already landed in master, so if rebasing the other patch is a real
problem, we'd have to revert this one first.
Kevin