qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Migration compatibility for serial


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH] Migration compatibility for serial
Date: Wed, 17 Jun 2015 12:40:53 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

* Paolo Bonzini (address@hidden) wrote:
> 
> 
> On 17/06/2015 12:13, Michael S. Tsirkin wrote:
> > On Wed, Jun 17, 2015 at 10:11:48AM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 17/06/2015 09:52, Michael S. Tsirkin wrote:
> >>>> No, please.  Upstream QEMU doesn't want to get into judgement about when
> >>>> migration quality might be "good enough" that you can drop subsections.
> >>>>  It's one thing to perfect the .needed functions to make the appearance
> >>>> of subsections as unlikely as possible, but adding flags is not
> >>>> something we've done so far---and not something at least *I* want to do.
> >>>
> >>> Not like this, sure.  But e.g. patches that force specific fields to
> >>> behave in a way consistent with QEMU 2.2, with appropriate
> >>> doducmentation would be ok I think.
> >>
> >> That's not what 2.2 means in "pc-i440fx-2.2".  It means "same hardware
> >> as 2.2", not "bug-compatible with 2.2".
> >>
> >> Refining the .needed functions (e.g. see commit bfa7362889) is just
> >> that: describing when a subsection is needed.  Forcing specific fields
> >> to behave in a way consistent with QEMU 2.2 is bug compatibility.
> > 
> > We do bug-compatible if it's not a big pain, too.
> 
> Where, in the specific case of migration?
> 
> Like Juan, I see where you're coming from.  But it's a slippery slope,
> and upstream chose not to go down it.

Whatever choice upstream may have made, that was a long time ago
and doesn't mean it can't change.

Dave

> 
> Paolo
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]