[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: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH] Extend qemu-ga's 'guest-info' command to expose flag 'success-response' |
Date: |
Tue, 24 Sep 2013 13:13:08 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 |
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:
>> +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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature