From: Markus Armbruster <armbru@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: peter.maydell@linaro.org, drjones@redhat.com,
mdroth@linux.vnet.ibm.com, qemu-devel@nongnu.org,
abologna@redhat.com, qemu-arm@nongnu.org
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH v5 2/5] arm: qmp: add query-gic-capabilities interface
Date: Wed, 23 Mar 2016 15:06:35 +0100 [thread overview]
Message-ID: <87wpot47bo.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <20160323120449.GT28183@pxdev.xzpeter.org> (Peter Xu's message of "Wed, 23 Mar 2016 20:04:49 +0800")
Peter Xu <peterx@redhat.com> writes:
> On Wed, Mar 23, 2016 at 10:52:29AM +0100, Markus Armbruster wrote:
>> The rule against returning non-dictionaries exists to avoid interfaces
>> that cannot evolve. With a dictionary, you can evolve by adding
>> members.
>>
>> The rule does *not* forbid returning lists of dictionaries. When a
>> command fundamentally returns a list of things, being able to evolve the
>> things suffices.
>
> Ok.
>
>>
>> query-gic-capabilities looks like it fundamentally returns a list of
>> capabilities. Returning ['GICCapability'] is just fine then.
>
> I have posted v6 just as Eric has suggested. At least one advantage
> is that it is easier to be extended (if needed) in the future, also
> to follow the more-generic format to use dicts rather than
> arrays. If you would not mind, I'll keep the dict interface there.
Returning such a list of a structured type is a well-established
convention by now --- qmp-introspect.c shows 28 commands doing it, most
of them named query-FOO. I'd rather not start a different convention
now, just because we got temporarily confused about our own rules. So,
unless there's something about query-gic-capabilities that makes it more
likely to need extension outside its list element type, let's stick to
returning the list.
Eric?
>
> [...]
>
>> In either case, drop the change to returns_whitelist.
>
> Yep. Dropped in v6.
>
> Thanks.
>
> -- peterx
WARNING: multiple messages have this Message-ID (diff)
From: Markus Armbruster <armbru@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: wei@redhat.com, peter.maydell@linaro.org, drjones@redhat.com,
mdroth@linux.vnet.ibm.com, qemu-devel@nongnu.org,
abologna@redhat.com, qemu-arm@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v5 2/5] arm: qmp: add query-gic-capabilities interface
Date: Wed, 23 Mar 2016 15:06:35 +0100 [thread overview]
Message-ID: <87wpot47bo.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <20160323120449.GT28183@pxdev.xzpeter.org> (Peter Xu's message of "Wed, 23 Mar 2016 20:04:49 +0800")
Peter Xu <peterx@redhat.com> writes:
> On Wed, Mar 23, 2016 at 10:52:29AM +0100, Markus Armbruster wrote:
>> The rule against returning non-dictionaries exists to avoid interfaces
>> that cannot evolve. With a dictionary, you can evolve by adding
>> members.
>>
>> The rule does *not* forbid returning lists of dictionaries. When a
>> command fundamentally returns a list of things, being able to evolve the
>> things suffices.
>
> Ok.
>
>>
>> query-gic-capabilities looks like it fundamentally returns a list of
>> capabilities. Returning ['GICCapability'] is just fine then.
>
> I have posted v6 just as Eric has suggested. At least one advantage
> is that it is easier to be extended (if needed) in the future, also
> to follow the more-generic format to use dicts rather than
> arrays. If you would not mind, I'll keep the dict interface there.
Returning such a list of a structured type is a well-established
convention by now --- qmp-introspect.c shows 28 commands doing it, most
of them named query-FOO. I'd rather not start a different convention
now, just because we got temporarily confused about our own rules. So,
unless there's something about query-gic-capabilities that makes it more
likely to need extension outside its list element type, let's stick to
returning the list.
Eric?
>
> [...]
>
>> In either case, drop the change to returns_whitelist.
>
> Yep. Dropped in v6.
>
> Thanks.
>
> -- peterx
next prev parent reply other threads:[~2016-03-23 14:06 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-18 3:27 [Qemu-arm] [PATCH v5 0/5] ARM: add query-gic-capabilities SMP command Peter Xu
2016-03-18 3:27 ` [Qemu-devel] " Peter Xu
2016-03-18 3:27 ` [Qemu-arm] [PATCH v5 1/5] arm: qmp: add GICCapability struct Peter Xu
2016-03-18 3:27 ` [Qemu-devel] " Peter Xu
2016-03-22 18:29 ` [Qemu-arm] " Markus Armbruster
2016-03-22 18:29 ` Markus Armbruster
2016-03-22 18:41 ` [Qemu-arm] " Markus Armbruster
2016-03-22 18:41 ` Markus Armbruster
2016-03-23 2:58 ` [Qemu-arm] " Peter Xu
2016-03-23 2:58 ` Peter Xu
2016-03-23 9:33 ` [Qemu-arm] " Markus Armbruster
2016-03-23 9:33 ` Markus Armbruster
2016-03-23 11:48 ` [Qemu-arm] " Peter Xu
2016-03-23 11:48 ` Peter Xu
2016-03-23 12:21 ` [Qemu-arm] " Markus Armbruster
2016-03-23 12:21 ` Markus Armbruster
2016-03-23 14:25 ` [Qemu-arm] " Peter Xu
2016-03-23 14:25 ` Peter Xu
2016-03-23 15:17 ` [Qemu-arm] " Markus Armbruster
2016-03-23 15:17 ` Markus Armbruster
2016-03-24 2:27 ` [Qemu-arm] " Peter Xu
2016-03-24 2:27 ` Peter Xu
2016-03-22 18:32 ` [Qemu-arm] " Eric Blake
2016-03-22 18:32 ` [Qemu-devel] " Eric Blake
2016-03-23 3:09 ` [Qemu-arm] " Peter Xu
2016-03-23 3:09 ` [Qemu-devel] " Peter Xu
2016-03-23 9:44 ` [Qemu-arm] " Markus Armbruster
2016-03-23 9:44 ` Markus Armbruster
2016-03-23 11:56 ` [Qemu-arm] " Peter Xu
2016-03-23 11:56 ` Peter Xu
2016-03-18 3:27 ` [Qemu-arm] [PATCH v5 2/5] arm: qmp: add query-gic-capabilities interface Peter Xu
2016-03-18 3:27 ` [Qemu-devel] " Peter Xu
2016-03-22 18:28 ` [Qemu-arm] " Markus Armbruster
2016-03-22 18:28 ` Markus Armbruster
2016-03-23 4:14 ` [Qemu-arm] " Peter Xu
2016-03-23 4:14 ` Peter Xu
2016-03-23 9:52 ` [Qemu-arm] " Markus Armbruster
2016-03-23 9:52 ` Markus Armbruster
2016-03-23 12:04 ` [Qemu-arm] " Peter Xu
2016-03-23 12:04 ` Peter Xu
2016-03-23 14:06 ` Markus Armbruster [this message]
2016-03-23 14:06 ` Markus Armbruster
2016-03-23 14:31 ` [Qemu-arm] " Eric Blake
2016-03-23 14:31 ` Eric Blake
2016-03-22 18:42 ` [Qemu-arm] " Eric Blake
2016-03-22 18:42 ` [Qemu-devel] " Eric Blake
2016-03-22 19:09 ` [Qemu-arm] " Markus Armbruster
2016-03-22 19:09 ` Markus Armbruster
2016-03-23 4:07 ` [Qemu-arm] " Peter Xu
2016-03-23 4:07 ` [Qemu-devel] " Peter Xu
2016-03-23 9:54 ` [Qemu-arm] " Markus Armbruster
2016-03-23 9:54 ` Markus Armbruster
2016-03-18 3:27 ` [Qemu-arm] [PATCH v5 3/5] arm: enhance kvm_arm_create_scratch_host_vcpu Peter Xu
2016-03-18 3:27 ` [Qemu-devel] " Peter Xu
2016-03-18 3:27 ` [Qemu-arm] [PATCH v5 4/5] kvm: add kvm_support_device() helper function Peter Xu
2016-03-18 3:27 ` [Qemu-devel] " Peter Xu
2016-03-18 3:27 ` [Qemu-arm] [PATCH v5 5/5] arm: implement query-gic-capabilities Peter Xu
2016-03-18 3:27 ` [Qemu-devel] " Peter Xu
2016-03-21 15:56 ` [Qemu-arm] [PATCH v5 0/5] ARM: add query-gic-capabilities SMP command Andrea Bolognani
2016-03-21 15:56 ` [Qemu-devel] " Andrea Bolognani
2016-03-22 2:23 ` [Qemu-arm] " Peter Xu
2016-03-22 2:23 ` [Qemu-devel] " Peter Xu
2016-03-22 14:20 ` [Qemu-arm] " Markus Armbruster
2016-03-22 14:20 ` Markus Armbruster
2016-03-23 5:19 ` [Qemu-arm] " Peter Xu
2016-03-23 5:19 ` Peter Xu
2016-03-22 14:49 ` Peter Maydell
2016-03-23 5:43 ` [Qemu-arm] " Peter Xu
2016-03-23 5:43 ` [Qemu-devel] " Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wpot47bo.fsf@blackfin.pond.sub.org \
--to=armbru@redhat.com \
--cc=abologna@redhat.com \
--cc=drjones@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.