Re: [PATCH v2 0/5] fix migration with bitmaps and mirror

[Vladimir Sementsov-Ogievskiy]

15.05.2020 20:51, Eric Blake wrote:
> On 5/15/20 6:15 AM, Vladimir Sementsov-Ogievskiy wrote:
>
> > > > Max is trying to tackle the node-name issue:
> > > > https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg03358.html
> > > >
> > > > And trying to apply that patch after staging this series hits a conflict in 
> > > > mnigration/block-dirty-bitmap.c.  Which one should go in first?
> > >
> > > My patches are needed to fix migration for the pre-blockdev configuration with 
> > > mirror-top filter.
> > >
> > > We ofcrouse need them in Virtuozzo, but it's not hard to keep the in 
> > > downstream-only.. And it will be not simple to use new command from Max in 
> > > pre-blockdev libvirt configuration, with auto-generated node-names.
>
> Carrying a downstream fork forever is more work on you.  If the patch is easy 
> enough to maintain, incorporating it upstream is best all around, even if 
> libvirt has moved on to the point of no longer caring since it no longer uses 
> pre-blockdev.

I hope not forever, when Rhel moves to node-names, we will do it too (hmm, I 
don't know, may be future already came, and Rhel8 libvirt is node-name 
oriented?) Still, yes it's always better to reduce the downstream overhead

> > > How much we care about pre-blockdev libvirt now in upstream Qemu?
> > >
> > > If we don't care, than these series are only for downstreams, and we don't need 
> > > to apply them upstream..
>
> Eventually, we may want to deprecate pre-blockdev, but I don't think we are 
> there yet, and even when it does happen, it will be two more releases with it 
> being deprecated before it is gone, so we might as well make it work correctly 
> in the meantime.

Agree. Better to fix old behavior first, and then do proper deprecation if 
needed.

> > > On the other hand, Max have to resend anyway, to handle old code, which uses 
> > > device name instead of node-name. And if we don't want to drop now the code 
> > > which can use device name (needed for old libvirt), why not to apply the 
> > > series, which just make old code better?
> > >
> > > ====
> > >
> > > In other words: do we still support pre-blockdev libvirt (and any other 
> > > pre-blockdev users)?
> > >
> > > If we support, than, as I said somewhere, I need to resend these series as I 
> > > have updated version in our downstream. And I think, I can rebase Max's patch 
> > > by myself and send together with this all, if no objections.
> >
> > I'm going to resend the series today, let's look at it.
>
> Sounds reasonable.

--
Best regards,
Vladimir