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