On 04/01/2015 06:53 PM, Markus Armbruster wrote:
Marcel Apfelbaum <mar...@redhat.com> writes:
[...]
I noticed something weird. I cannot actually create an instance of machine
or get a reference to current_machine in order to query its properties!
It seems that util/qemu-config is used by qemu-img which obviously
does not have a current machine nor the means to create it.
So I have no way to create QOM objects for introspection :(.
You'd have to do something like
desc[] = generic entries + the machine's entries
where the latter is empty outside qemu proper.
Hmm! So I will loose with some dignity.
I'll keep the properties of the base "machine" on a static array
and *only* per-machine properties dynamic and I loose them.
For 2.3, I recommend to do *only* generic entries. Specifically,
*exactly* the entries we had before we cleared out
qemu_machine_opts.desc[].
I submitted:
[PATCH for-2.3] util/qemu-config" fix regression of
qmp_query_command_line_options
which includes both base-machine/per-machine properties.
Is it that bad? qmp can query it and even the new options will work
if qmp decides to set them. Can you have a look?
[...]
Big job, though.
You lost me... you are talking about QAPI that I have no knowledge about,
and I still don't see how I can create instances of QOM objects in the context
of qemu-config.
Very high level summary:
0. We use QemuOpts to define our command line. The definition is
*incomplete*. The missing parts are left to code.
query-command-line-options can't see them.
OK
1. You have a QemuOpts problem that is actually pretty common: how to
accept a few fixed parameters plus a bunch of parameters that are
specific to the value of one of the fixed parameters (the
discriminator, in your case "type").
Yes, but is more than that:
per-type properties are not static, you cannot find them before creating
an actual QOM object, and that is not possible.
We could have a per-machine static options array that will be loaded
at init time into object properties... ugly.
2. We've solved this in several different ways, and all of them make
query-command-line-options useless.
Got it
3. Same problem exists in QMP, and we have a decent solution there,
based on QAPI.
OK
4. We'll soon have QMP/QAPI introspection.
And then we can query a 'living' object's properties
5. If we used a QAPI schema to define our command line, we could do a
more complete job (because it's more expressive), and we'd get
introspection basically for free.
If the QAPI schema will include *all* properties *per* machine type, sure.
6. #5 would be a big job, though.
Less confused now?
Much better, thanks!
Marcel
[...]