qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v6 09/10] migration: merge enforce_config_sectio


From: Peter Xu
Subject: Re: [Qemu-devel] [PATCH v6 09/10] migration: merge enforce_config_section somewhat
Date: Fri, 30 Jun 2017 14:10:05 +0800
User-agent: Mutt/1.5.24 (2015-08-30)

On Thu, Jun 29, 2017 at 04:18:49PM -0300, Eduardo Habkost wrote:
> On Thu, Jun 29, 2017 at 11:00:13AM +0800, Peter Xu wrote:
> > On Thu, Jun 29, 2017 at 12:42:56AM +0200, Juan Quintela wrote:
> > > Eduardo Habkost <address@hidden> wrote:
> > > 
> > > >
> > > > So, this is a case where a user-provided config option (-machine
> > > > enforce-config-section) should trigger a different default in another
> > > > class (migration.send-configuration).
> > > >
> > > > Also, the new default triggered by -machine has a very specific
> > > > priority:
> > > >
> > > > * AccelClass::global_props must not override "-machine 
> > > > enforce-config-section=on"
> > > > * MachineClass::compat_props must not override
> > > >   "-machine enforce-config-section=on"
> > > >
> > > > We must also decide in advance what should be result of:
> > > > * "-machine enforce-config-section=on -global 
> > > > migration.send-configuration=off"
> > > > * "-machine enforce-config-section=off -global 
> > > > migration.send-configuration=on"
> > > > * "-global migration.send-configuration=off -machine 
> > > > enforce-config-section=off"
> > > > * "-global migration.send-configuration=on -machine 
> > > > enforce-config-section=on"
> > 
> > Yes, this is considered before this patch: currently
> > enforce-config-section will have the highest priority in case if
> > someone used both of the old & new parameters for it (considering
> > "enforce-config-section" has the word "enforce" inside, it makes some
> > sense). While...
> > 
> > > 
> > > BOOM!!!!!
> > > 
> > > We use old configuration or new one.
> > 
> > ... I agree more with Juan here, that user should not really specify
> > these two parameters at the same time. If the user knows the new
> > parameter, he/she should know that the new one is obsoleting the old
> > one. And since even for that case this patch can handle it well (will
> > take -M param), I think it's okay.
> 
> If that's the intended result, it's OK to me.  But I think the
> relationship between enforce-config-section and
> migration.send-configuration should be documented in qemu-options.hx.
> And considering that this could break silently in future code
> refactoring, an automated test would be interesting (but not critical,
> as setting options contradicting each other is not a common scenario).
> 
> 
> > 
> > > 
> > > >
> > > > I'm not sure what we should decide about these 4 cases above, but I
> > > > believe it would be safer to encode that decision at the same place we
> > > > handle the priority between accel/machine/user globals:
> > > > register_global_properties() at vl.c.
> > > >
> > > >
> > > > Or maybe this extra complexity is a sign that we shouldn't try to add
> > > > extra magic to make -machine affect the "migration" object properties,
> > > > and keep the existing machine->enforce_config_section check in the
> > > > migration code?  I'm not sure.
> > > 
> > > Not sure there either.  I preffer doing it in a single place, but I am
> > > not the expert here.
> > 
> > IMHO it is not necessary to introduce such a thing in
> > register_global_properties(). AFAIU this is the only place where one
> > machine property can collapse with a global property? And it currently
> > only happens in migration codes. Actually it is well ordered, since we
> > init the migration object after register_global_properties(), so
> > everthing should possibly be fine. Introducing framework-level thing
> > for this may only make things more complicated imho.
> 
> True.  Considering we need to keep the "overrides everything else"
> semantics of enforce-config-section, your approach is not bad.
> 
> > 
> > After all we can remove all these one day when we can obsolete the
> > "enforce-config-section" parameter (maybe we should add one OBSOLETE
> > warning when the -M parameter is used).  Thanks,
> 
> I don't think we need a warning, but a documentation update is
> important, IMO.

Since the pull request has been merged already, I'll add some
documentation to qemu-options.hx for this in separate patch (and I'll
temporarily skip the unit test since I really think we should obsolete
the old parameter one day). Thanks!

-- 
Peter Xu



reply via email to

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