On 04/01/2015 11:01 AM, Paolo Bonzini wrote:
On 01/04/2015 08:54, Marcel Apfelbaum wrote:
This is the first object for which QemuOps are defined per
sub-type and are not global (if you don't take "object" under
consideration).
We can return the same QemuOpts that were included before.
Per-machine-type options are new and need not be covered by
query-command-line-options.
OK, we have them under hw/core/machine.c as "base" machine properties.
We still need a way to fill them back into QemuOpts right?
Maybe return them to the static global list? It seems like a step
back, but if there is no better way...
Thanks,
Marcel
Paolo
I saw others as well, like netdev, but I am not sure what happens there.
Once the QemuOpts are parsed, the only place we can find those options
is the machine object itself (as QOM properties).
I see a few options here:
1. Add a feature to QemuOpts: "Look for options in QOM properties of
this obj"
2. Add a callback to QEMU opts that supplies the options (have machine
supply the callback)
3. Have the machine object fill in the corresponding QemuOpts on init.
