Just one question: why not always use boxed configuration? It should not
make the instance_config types any larger, and it avoids unwieldy argument
lists.
Basically for the same reason as for commands (and for consistency with
commands): If you have only one or two options, then creating a separate
type for them feels just a little over the top, and boxing doesn't work
with implicit types.
I really like the concise definitions without a separate struct like in:
{ 'class': 'rng-egd',
'parent': 'rng-backend',
'config': { 'chardev': 'str' } }
Though maybe we could make it work by giving the implicit type another
prefixed name?
Also, for the obligatory bikeshedding remark, do you have any other plans or
ideas for the colon-separated auto generated typenames? Having both the
"namespace" (qom) and the more specific use (config) before the classname is
a bit weird, compared to the existing structs like RngRandomProperties.
Especially if boxed config is more used (or becomes the only possibility),
it might be that qom:class-name:config, or even just class-name:config, make
for nicer code in the object implementation.
'qom-config:classname' isn't a type that is useful for the object
implementations at all. Its only use is really storing the whole
configuration temporarily in a QAPI C struct before applying it.