qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 06/52] audio: -audiodev command line option b


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH v2 06/52] audio: -audiodev command line option basic implementation
Date: Thu, 10 Jan 2019 11:37:29 +0100
User-agent: NeoMutt/20180716

> > 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]