[libvirt] [PATCH 06/11] qemu: Add monitor functions to set IOThread params

Michal Prívozník mprivozn at redhat.com
Tue Oct 23 15:36:10 UTC 2018


On 10/23/2018 03:42 PM, John Ferlan wrote:
> [...]
> 
>>>>
>>>
>>> Not 100% sure what you meant... The point of the bools is to indicate
>>> when the value was set, doesn't matter if it's zero.
>>
>> Ah sorry, I've misunderstood then. set_##propVal is a boolean not
>> integer holding the value we want to set. So you'd have two variables,
>> int A and bool set_A. Okay, this will work well. However, at this point
>> I wonder if having monitor API that would take attribute name and a
>> value would be simpler. Something like:
>>
>>
>> qemuMonitorSetIOThreadAttr(qemuMonitorPtr mon,
>>                            unsigned int thread_id,
>>                            const char *attrName,
>>                            int attrVal);
>>
>>
>> Then this function would be called like this:
>>
>> static int
>> qemuDomainSetIOThreadParams(virDomainPtr dom,
>>                             unsigned int iothread_id,
>>                             virTypedParameterPtr params,
>>                             int nparams,
>>                             unsigned int flags)
>> {
>>     ...
>>
>>     for (i = 0; i < nparams; i++) {
>>         qemuMonitorSetIOThreadAttr(mon, thread_id, param[i].str,
>>                                    param[i].val);
>>     }
>>     ...
>> }
>>
>>
>> Anyway, I'll leave it up to you.
>>
>> Michal
>>
> 
> I kept a lot of what Pavel already had for simplicity and leaving the
> setting deeper in the _json code for all values rather than 'n' calls to
> essentially do the same thing. Those patches were posted before this
> discussion. I'm not against rewriting to conform to some other
> mechanism, just let me know.

At this point it is more of a personal preference than anything. From
functional POV these two approaches are the same. So I am okay with you
keeping what you suggested.

Michal




More information about the libvir-list mailing list