On Thu, Jun 29, 2017 at 12:42:56AM +0200, Juan Quintela wrote: > Eduardo Habkost <ehabk...@redhat.com> 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. > > > > > 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. 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, -- Peter Xu
