|
From: | Eric Blake |
Subject: | Re: [Qemu-devel] [PATCH v2] qapi: add query-display-options command |
Date: | Wed, 21 Nov 2018 11:39:55 -0600 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 |
On 11/21/18 11:09 AM, Markus Armbruster wrote:
Gerd Hoffmann <address@hidden> 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 in Thread] | Current Thread | [Next in Thread] |