[libvirt] [PATCHv2 04/11] qemu_monitor: Introduce qemuMonitorCPUModelInfoInit and qemuMonitorCPUModelInfoFreeContents

Chris Venteicher cventeic at redhat.com
Thu Jul 12 16:35:23 UTC 2018


Quoting Jiri Denemark (2018-07-12 08:13:07)
> On Mon, Jul 09, 2018 at 22:56:48 -0500, Chris Venteicher wrote:
> > These forms modify contents of a qemuMonitorCPUModelInfo structure but
> > do not allocate or free the actual structure.
> > 
> > Init - Initialize model name and empty properties within existing structure
> > FreeContents - Free model name and properties within existing structure
> 
> We call such function with "Clear" suffix, i.e.,
> qemuMonitorCPUModelInfoClear.
> 
> But it is usually used when we have a structure stored somewhere
> directly rather than having a pointer to it. And this was not the case
> so far and I don't think there's any reason to introduce a code which
> would need any of these functions.
> 
> NACK to this patch.
>
Hi Jirka.  I see what you mean about combining dependent patches... It would be 
helpful if this patch was coupled with the qemuMonitorGetCPUModelExpansion 
patch.

Could I get you're thoughts on the qemuMonitorGetCPUModelExpansion patch to know 
what to do with this one?  

Specifically, I seem to need to send a full CPUModelInfo to QEMU (w/ model name 
+ properties) and get a full CPUModelInfo back from QEMU (again w/ model name + 
expanded properties).

I implemented this by rewriting the contents (property list) of the CPUModelInfo 
structure that is passed in to qemuMonitorGetCPUModelExpansion.  

I do a similar thing in qemuMonitorCPUModelInfoRemovePropByBoolValue... I 
rewrite the property list rather than allocating and returning a completely new 
CPUModelInfo for output.

Is this consistent with other functions or would I be better off allocating and 
returning a completely new CPUModelInfo for the output?

Or something else.

Thanks for feedback. Chris

> 
> Jirka




More information about the libvir-list mailing list