Re: [Qemu-devel] [PATCH 4/5] qapi: support nested structs in OptsVisitor

[Kővágó Zoltán]

2015-07-02 19:34 keltezéssel, Markus Armbruster írta:
> "Kővágó, Zoltán" <address@hidden> writes:
>
> > The current OptsVisitor flattens the whole structure, if there are same
> > named fields under different paths the current visitor can't cope with
> > them (it'll just set the first field, leaving the others unspecified (if
> > they're optional) or erroring out (if they're required).
> >
> > This patch add support for it, by always requiring a complete path in
> > case of nested structs.  Fields in the path are separated by dots,
> > similar to C structs (without pointers), like `foo.bar'.
> >
> > You must provide a full path even in non-ambigous cases.  The previous
> > two commits hopefully ensures that this change doesn't create backward
> > compatibility problems.
> >
> > Signed-off-by: Kővágó, Zoltán <address@hidden>
> >
> > ---
> >
> > Rationale for this commit: see these threads
> > http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg04189.html
> > http://lists.nongnu.org/archive/html/qemu-devel/2015-06/msg04186.html
>
> So, despite your flattening work, we still need to parse option strings
> into nested QAPI types?

The reason why this whole flattening stuff is done it's because 
otherwise this nested parsing patch breaks backward compatibility.

> Can you give examples of the need for such nested QAPI types in
> configuration?  I may have seen them already in your audio patches, but
> I think having some right here would be useful.

I'm afraid that only the audio patches contains code that actually use 
this new feature.  But that has a lot of configuration options that 
apply to both input and output, and having a shared struct that is 
available via `in.' and `out.' is better than having to manually 
duplicate all these settings under unique names in a single struct (like 
in_frequency, out_frequency, in_channels, out_channels, ...).