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


Reply via email to