From: Luiz Capitulino <lcapitulino@redhat.com>
To: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: Mark Wu <wudxw@linux.vnet.ibm.com>, Qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] Extend qemu-ga's 'guest-info' command to expose flag 'success-response'
Date: Tue, 24 Sep 2013 20:34:54 -0400 [thread overview]
Message-ID: <20130924203454.2901afc3@redhat.com> (raw)
In-Reply-To: <20130924210729.20300.29270@loki>
On Tue, 24 Sep 2013 16:07:29 -0500
Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> > >> +bool qmp_command_has_success_response(const char *name)
> > >> +{
> > >> + QmpCommand *cmd;
> > >> +
> > >> + QTAILQ_FOREACH(cmd, &qmp_commands, node) {
> > >> + if (strcmp(cmd->name, name) == 0) {
> > >> + return cmd->options != QCO_NO_SUCCESS_RESP;
> >
> > cmd->options is a bitmask - it is feasible that we may add more QCO_NO_*
> > flags in the future, at which point inequality is NOT correct. Rather,
> > you want:
> >
> > return !(cmd->options & QCO_NO_SUCCESS_RESP);
Good catch! IIRC I added cmd->options myself and didn't catch this...
> > >> +++ b/qga/commands.c
> > >> @@ -63,6 +63,8 @@ struct GuestAgentInfo *qmp_guest_info(Error **err)
> > >> cmd_info = g_malloc0(sizeof(GuestAgentCommandInfo));
> > >> cmd_info->name = g_strdup(*cmd_list);
> > >> cmd_info->enabled = qmp_command_is_enabled(cmd_info->name);
> > >> + cmd_info->success_response =
> > >> + qmp_command_has_success_response(cmd_info->name);
> >
> > This feels wasteful. Why are we doing an O(n) lookup for BOTH
> > qmp_command_is_enabled AND qmp_command_has_success_response, in an O(n)
> > loop over command names? That's O(n^2) in the number of commands.
> > Better would be getting a list of QmpCommand* instead of a list of
> > char*, and looking directly in each object, for O(n) computation of the
> > results.
>
> Agreed, modifying qmp_get_command_list to return a list of QmpCommand
> would be nicer. Rather than looking directly at the fields though I
> think we should just fix up qmp_command_is_enabled() and friends to
> take a QmpCommand arg instead of a char*. We already have
> qmp_find_command to map char*->QmpCommand to support any cases where
> we rely on cmd names.
I agree and I thought the same thing when I reviewed the patch, but
I didn't mind as Mark is just using what's already there.
next prev parent reply other threads:[~2013-09-25 0:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-22 6:50 [Qemu-devel] [PATCH] Extend qemu-ga's 'guest-info' command to expose flag 'success-response' Mark Wu
2013-09-23 12:32 ` Luiz Capitulino
2013-09-23 13:57 ` Eric Blake
2013-09-24 19:00 ` Michael Roth
2013-09-24 19:13 ` Eric Blake
2013-09-24 21:07 ` Michael Roth
2013-09-25 0:34 ` Luiz Capitulino [this message]
2013-09-25 12:30 ` Mark Wu
-- strict thread matches above, loose matches on Subject: below --
2013-09-18 7:23 Mark Wu
2013-09-18 12:45 ` Luiz Capitulino
2013-09-18 12:59 ` Eric Blake
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=20130924203454.2901afc3@redhat.com \
--to=lcapitulino@redhat.com \
--cc=Qemu-devel@nongnu.org \
--cc=mdroth@linux.vnet.ibm.com \
--cc=wudxw@linux.vnet.ibm.com \
/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).