[libvirt] [REPOST PATCH v2 6/9] qemu: Add support for parsing iotune group setting

[John Ferlan]

[...]

>>> Also, once you do what I'm suggesting, the crash from 6/9 will be resolved,
>>> however I still would like to see the @reply structure in
>>> qemuDomainGetBlockIoTune initialized properly on the stack.
>>
>> Weird how that crash happens for you, but not me especially since you
>> show 20 nparams which would seem to imply you're getting something back
>> from qemu. Even though it's not set by libvirt, qemu does default to
>> something (the id/alias for the object - in my case "drive-virtio-disk0"
>> for my qemu 2.6.2). What do you get from a command:
>>
>>  virsh qemu-monitor-command $domain '{"execute":"query-block"}'
>>
>> ?
>>
> 
> The returned JSON doesn't indicate any default on my qemu 2.6.0:
> 

[...]

Ahhh... Right a domain without iotune adjustments... I think I checked
that at one time, but that was before I changed my mind in the
implementation from having "group" be some number to allowing a string
for group. With the number implementation I was just prepending some
constant string. So I guess I had it in my mind that I had already
tested that non iotune path.

> What I did was just to start a domain that had no block iotuning turned on
> whatsoever and when I saw the code I was like, wait, I need to try that as it
> looked suspicious at first glance (since at that moment I'd already known about
> the missing initialization) so I tried it and it crashed.
> 
>> In any case, I'll add a memset(&reply, 0, sizeof(reply)) in the qemu
> 
> Yeah, that would do, sure, but is there a problem with a plain static
> initialization at the function entry point? I mean that's where we (most of the
> time) put all of our initializations and also where everyone would actually
> expect such an assignment to take place...
> 
> Erik
> 

OK, I'll just change the definition:

    virDomainBlockIoTuneInfo reply = {0};

John