qemu-devel
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]