[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] Extend qemu-ga's 'guest-info' command to expose
From: |
Michael Roth |
Subject: |
Re: [Qemu-devel] [PATCH] Extend qemu-ga's 'guest-info' command to expose flag 'success-response' |
Date: |
Tue, 24 Sep 2013 16:07:29 -0500 |
User-agent: |
alot/0.3.4 |
Quoting Eric Blake (2013-09-24 14:13:08)
> On 09/24/2013 01:00 PM, Michael Roth wrote:
> > Quoting Mark Wu (2013-09-22 01:50:54)
> >> Now we have several qemu-ga commands not returning response on success.
> >> It has been documented in qga/qapi-schema.json already. This patch exposes
> >> the 'success-response' flag by extending 'guest-info' command. With this
> >> change, the clients can handle the command response more flexibly.
> >>
> >> Changes:
> >> v2: add the notation 'since 1.7' to the option 'success-response'
> >> (per Eric Blake's comments)
> >>
> >> Signed-off-by: Mark Wu <address@hidden>
> >
> > Reviewed-by: Michael Roth <address@hidden>
> >
> > Eric, do we have your reviewed-by other than the changes you mentioned? If
> > so I
> > can fix those up in my tree.
>
> Aha - force me to do a FULL review, rather than just an interface
> review. I found more issues, so this probably deserves a v2:
Haha, you saw through my plan! :)
>
> >> +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);
>
> >> +++ 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.
>
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org