qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 2/6] qapi: support nested structs in OptsVisi


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v2 2/6] qapi: support nested structs in OptsVisitor
Date: Wed, 17 Jun 2015 09:50:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Copying László because his fingerprints are on OptsVisitor.

"Kővágó, Zoltán" <address@hidden> writes:

> The current OptsVisitor flattens the whole structure, if there are same named
> fields under different paths (like `in' and `out' in `Audiodev'), the current
> visitor can't cope with them (for example setting `frequency=44100' will set 
> the
> in's frequency to 44100 and leave out's frequency unspecified).
>
> This patch fixes it, by the following changes:
> 1) Specifying just the field name will apply to all fields that has the
>    specified name (this means it would set both in's and out's frequency to
>    44100 in the above example).
> 2) Optionally user can specify the path in the hierarchy. Names are separated 
> by
>    a dot (e.g. `in.frequency', `foo.bar.something', etc). The user need not
>    specify the whole path, only the last few components (i.e. `bar.something' 
> is
>    equivalent to `foo.bar.something' if only `foo' has a `bar' field). This 
> way
>    1) is just a special case of this when only the last component is 
> specified.
> 3) In case of an ambiguity (e.g `frequency=44100,in.frequency=8000') the 
> longest
>    matching (the most specific) path wins (so in this example, in's frequency
>    would become 8000, because `in.frequency' is more specific that 
> `frequency',
>    and out's frequency would become 44100, because only `frequency' matches 
> it).

Can you explain why the complexity is needed, i.e. why we can't just
require full paths always?



reply via email to

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