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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
