On Thu, Jul 12, 2018 at 11:35:23 -0500, Chris Venteicher wrote: > 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? Yeah, that's the solution I was thinking about. With it you don't need these fragile FreeContents/Init functions and the function won't touch the input data unless it's finished at which point it will just free the input and replace it with the new structure. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
