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"
BOOM!!!!! We use old configuration or new one. > > 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. Later, Juan.
