> > 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. > > I think that union thing works, the problem is with input and output > settings, because they're common. Currently you can write in.frequency > and out.frequency, in and out are both AudiodevPerDirectionOptions.
Ah, right, I remember now. > The alternative would be to flatten the whole structure and have > in_frequency, out_frequency and everything else duplicated in Audiodev Which might be not that bad after all. The parser code is generated. The audio drivers (where the settings are looked up) have separate code paths for in and out anyway. So a per-direction struct probably wouldn't reduce the amout of code in the drivers. Driver-specific per-direction options are easier to deal with too I think (not sure we have them though). Property names should use dashes not underscores btw (i.e. in-frequency). cheers, Gerd
