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 13:50:17 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

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

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

I agree opts.data.in.try-poll would be an ugly user interface.  But
instead of hiding opts.data. with a convenience feature, I'd like us to
investigate avoiding it altogether.



reply via email to

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