From: Eric Blake <eblake@redhat.com>
To: Markus Armbruster <armbru@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] qapi: add query-display-options command
Date: Wed, 21 Nov 2018 11:39:55 -0600 [thread overview]
Message-ID: <7dea4e0f-ae71-caf6-c637-e1d150b0bcd8@redhat.com> (raw)
In-Reply-To: <874lca1hnf.fsf@dusky.pond.sub.org>
On 11/21/18 11:09 AM, Markus Armbruster wrote:
> Gerd Hoffmann <kraxel@redhat.com> writes:
>
>> Add query-display-options command, which allows querying the qemu
>> display configuration, and -- as an intentional side effect -- makes
>> DisplayOptions discoverable via query-qmp-schema so libvirt can go
>> figure which display options are supported.
>
> I understand the why the side effect is useful. But is it the only
> reason for the new command?
The reason for needing the side effect in 3.1 is because commit d4dc4ab1
also landed in 3.1; the commit message should really mention that
relationship.
You are right that in general, a management app should remember what it
asked for on the command line, and is therefore unlikely to learn
anything by invoking this command directly. On the other hand, if the
display options populate any defaults omitted from the command line,
this query command might still be useful to show what defaults got
populated.
>> +DisplayOptions *qmp_query_display_options(Error **errp)
>> +{
>> + DisplayOptions *opts;
>> +
>> + opts = g_new(DisplayOptions, 1);
>> + QAPI_CLONE_MEMBERS(DisplayOptions, opts, &dpy);
>> + return opts;
>
> What's wrong with
>
> return QAPI_CLONE(DisplayOptions, &dpy)
>
> ?
Looks like it should work.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
prev parent reply other threads:[~2018-11-21 17:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-21 13:16 [Qemu-devel] [PATCH v2] qapi: add query-display-options command Gerd Hoffmann
2018-11-21 17:09 ` Markus Armbruster
2018-11-21 17:39 ` Eric Blake [this message]
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=7dea4e0f-ae71-caf6-c637-e1d150b0bcd8@redhat.com \
--to=eblake@redhat.com \
--cc=armbru@redhat.com \
--cc=kraxel@redhat.com \
--cc=pbonzini@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).