Re: QEMU API cleanup initiative - Let's chat during the KVM call

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Oct 05, 2020 at 10:52:41AM -0400, John Snow wrote:
> - Markus considers the platonic ideal of a CLI one in which each flag is a
> configuration directive, and each directive that references another
> directive must appear after the directive in which it references.

In this view you would be creating resources in the order in which they
appear in the understanding that the mgmt app knows what dependancies
it placed between cli options. ie it knows that it wants "-object secret"
created before "-chardev foo", because the chardev depends on the secret
to exist.

Despite the fact that QEMU does not correctly honour the CLI arg order
today, libvirt will place arguments in the order in which they must be
created already. IOW, we know the order they appear in the CLI or
configuration will always work correctly, as long as QEMU honours it.

QEMU has had todo various hacks to deal with the fact that it doesn't
honour ordering, such as creating different -object types at different
stages in startup. This is a really horrible part of QEMU that constantly
causes us pain.

> - I tend to consider the ideal configuration to be a static object that has
> no inherent order from one key to the next, e.g. a JSON object or static
> flat file that can be used to configure the sysemu.

If you treat the configuration as un-ordered, then QEMU needs to be
intelligent enough to figure out the correct order to create all the
resources in. This requires some pieces of code to have a complete
view of all configuration, and know which attrs express dependencies.
It then has to be able to traverse the configuration in the correct
topological sorted order to create things.

Anything is possible, but from where QEMU is starting right now this
feels like a massive task to put in front of ourselves. We basically
have to solve the entire global configuration problem in order to get
this working as you can only do the topological sorting if you can see
the full picture.

The concern I have is that it also injects an element of non-determinism
into the startup procedure that can make things painful to debug. eg there
are theoretically many possible sort orders that are correct for creation,
but if things have unexpected side-effects during creation, these different
orders will not be strictly equivalent in reality.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|