From: Anthony Liguori <anthony@codemonkey.ws>
To: Jes Sorensen <Jes.Sorensen@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [PATCH] Make VNC support optional
Date: Fri, 11 Mar 2011 08:00:49 -0600 [thread overview]
Message-ID: <4D7A2B11.2080807@codemonkey.ws> (raw)
In-Reply-To: <4D7A26F7.1010901@redhat.com>
On 03/11/2011 07:43 AM, Jes Sorensen wrote:
> On 03/11/11 14:36, Anthony Liguori wrote:
>>> diff --git a/monitor.c b/monitor.c
>>> index 22ae3bb..4425315 100644
>>> --- a/monitor.c
>>> +++ b/monitor.c
>>> @@ -441,6 +441,7 @@ void monitor_protocol_event(MonitorEvent event,
>>> QObject *data)
>>> case QEVENT_RESUME:
>>> event_name = "RESUME";
>>> break;
>>> +#ifdef CONFIG_VNC
>>> case QEVENT_VNC_CONNECTED:
>>> event_name = "VNC_CONNECTED";
>>> break;
>>> @@ -450,6 +451,7 @@ void monitor_protocol_event(MonitorEvent event,
>>> QObject *data)
>>> case QEVENT_VNC_DISCONNECTED:
>>> event_name = "VNC_DISCONNECTED";
>>> break;
>>> +#endif
>> No need to if this out.
> I realized that, but I figured it would reduce the code a bit more. I'll
> leave it in.
fwiw, it's all gone in my tree so you don't need to worry about it
sticking around :-)
> @@ -3002,6 +3014,7 @@ static const mon_cmd_t info_cmds[] = {
>>> .user_print = do_info_mice_print,
>>> .mhandler.info_new = do_info_mice,
>>> },
>>> +#ifdef CONFIG_VNC
>>> {
>>> .name = "vnc",
>>> .args_type = "",
>>> @@ -3010,6 +3023,7 @@ static const mon_cmd_t info_cmds[] = {
>>> .user_print = do_info_vnc_print,
>>> .mhandler.info_new = do_info_vnc,
>>> },
>>> +#endif
>> We don't want to hide commands based on compile settings.
>>
>> Otherwise, looks good.
> I am not sure I follow you here, you prefer to have the commands visible
> even though they are disabled? There are other commands which get
> disabled like this as well.
Yeah and that's wrong and I've fixed that in my QAPI branch.
If a command is #if 0'd out, then it doesn't show up in query-commands
and if you try to use it, it returns a CommandNotFound which is the same
error as any garbage command would produce.
But query-commands is not just useful for feature checking, but also for
getting the schema to generate bindings. We have this problem with
command line options today, there's no good way to ask QEMU for every
possible command line option if you're trying to build tooling around it
because it depends on how QEMU is configured.
Having the command and returning FeatureDisabled means that QEMU still
can advertise the command's schema and a user can differentiate between
a feature that's explicitly disabled, for instance, in RHEL for support
concerns, and a command that this QEMU just knows nothing about.
This is nice for a GUI because you can expose a different error message
to the user. For CommandNotFound, you might say, "This version of QEMU
is too old for this feature" whereas for FeatureDisabled, you would say,
"This version of QEMU disables this feature, contact your vendor."
Regards,
Anthony Liguori
> Cheers,
> Jes
>
prev parent reply other threads:[~2011-03-11 14:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-11 12:38 [Qemu-devel] [PATCH] Make VNC support optional Jes.Sorensen
2011-03-11 13:36 ` [Qemu-devel] " Anthony Liguori
2011-03-11 13:43 ` Jes Sorensen
2011-03-11 14:00 ` Anthony Liguori [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=4D7A2B11.2080807@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=Jes.Sorensen@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).