[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.
- [Qemu-devel] [PATCH v2 0/6] -audiodev option, Kővágó, Zoltán, 2015/06/16
- [Qemu-devel] [PATCH v2 3/6] opts: do not print separator before first item in qemu_opts_print, Kővágó, Zoltán, 2015/06/16
- [Qemu-devel] [PATCH v2 2/6] qapi: support nested structs in OptsVisitor, Kővágó, Zoltán, 2015/06/16
- Re: [Qemu-devel] [PATCH v2 2/6] qapi: support nested structs in OptsVisitor, Markus Armbruster, 2015/06/17
- Re: [Qemu-devel] [PATCH v2 2/6] qapi: support nested structs in OptsVisitor, Markus Armbruster, 2015/06/17
- Re: [Qemu-devel] [PATCH v2 2/6] qapi: support nested structs in OptsVisitor, Kővágó Zoltán, 2015/06/17
- Re: [Qemu-devel] [PATCH v2 2/6] qapi: support nested structs in OptsVisitor, Markus Armbruster, 2015/06/17
- Re: [Qemu-devel] [PATCH v2 2/6] qapi: support nested structs in OptsVisitor, Kővágó Zoltán, 2015/06/17
- Re: [Qemu-devel] [PATCH v2 2/6] qapi: support nested structs in OptsVisitor, Markus Armbruster, 2015/06/17
[Qemu-devel] [PATCH v2 1/6] qapi: qapi for audio backends, Kővágó, Zoltán, 2015/06/16