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