Hi,
> I was thinking about creating an Audiodev (the qapi type) directly would
> be better, then somehow print it with reflection. While this is not a
> typical use of qapi, at least qmp_qom_list creates qapi objects
> directly, so I assume it's ok.
Yes, it's perfectly fine.
> The second problem: with my patched options visitor, nested structs were
> required in qapi, the options visitor unconditionally filled them. With
> qobject_input_visitor, I have to mark them optional, otherwise the user
> have to specify at least one option from the nested structs.
Can we just drop the nesting?
Have a look at DisplayOptions (qapi struct used to store -display
options). It's a union, has some common base fields, and the
discriminator field (type in that case) decides which of the data
branches is used. And on the command line I can do stuff like this:
-display gtk,full-screen=on,zoom-to-fit=on
^^^^^^^^^^^ in struct DisplayGTK
^^^^^^^^^^^ common base field
Audiodev should be able to do the same to support backend-specific
options without nesting.
cheers,
Gerd
