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: Kővágó Zoltán
Subject: Re: [Qemu-devel] [PATCH v2 2/6] qapi: support nested structs in OptsVisitor
Date: Wed, 17 Jun 2015 13:01:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

2015-06-17 10:41 keltezéssel, Gerd Hoffmann írta:
On Mi, 2015-06-17 at 09:50 +0200, Markus Armbruster wrote:
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?

Keeping the short names is required for -netdev backward compatibility.

Restricting to short or full (i.e. something= or foo.bar.something=, but
disallow bar.something=) should not be a problem.  I'm not sure this
simplifies things much though.  We have to build the full path anyway,
and I think bar.something= is just a convenient thing we get almost for
free ...

With the current implementation you can specify (see my previous patch) in.try-poll=off in case of alsa. If we would need full paths, it would look like opts.data.in.try-poll=off, which is probably not something we want.




reply via email to

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