Re: [libvirt] [PATCH RFC 10/22] qemu_process: Introduce qemuProcessStartQmp
On Wed, Nov 14, 2018 at 10:47:14 -0600, Chris Venteicher wrote:
Quoting Michal Privoznik (2018-11-14 09:45:07)
> On 11/11/2018 08:59 PM, Chris Venteicher wrote:
> > Move a step closer to the function structure used elsewhere in
> > qemu_process where qemuProcessStart and qemuProcessStop are the exposed
> > functions.
> >
> > qemuProcessStartQmp mirrors qemuProcessStart in calling sub functions to
> > intialize, launch the process and connect the monitor to the QEMU
> > process.
> >
> > static functions qemuProcessInitQmp, qemuProcessLaunchQmp and
> > qemuConnectMonitorQmp are also introduced.
> >
> > qemuProcessLaunchQmp is just renamed from qemuProcessRun and
> > encapsulates all of the original code.
> >
> > qemuProcessInitQmp and qemuProcessMonitorQmp are introduced as empty
> > wrappers into which subsequent patches will partition code from
> > qemuProcessLaunchQmp.
> >
...
> > +/* Initialize configuration and paths prior to starting
QEMU
> > + */
> > +static int
> > +qemuProcessInitQmp(qemuProcessPtr proc)
> > +{
> > + int ret = -1;
> > +
> > + VIR_DEBUG("Beginning VM startup process"
> > + "emulator=%s",
> > + proc->binary);
> > +
> > + ret = 0;
> > +
> > + VIR_DEBUG("ret=%i", ret);
> > + return ret;
> > +}
> > +
>
> I am sorry, but I'm failing to see the purpose of this function.
>
> > +
> > +/* Launch QEMU Process
> > + */
> > +static int
> > +qemuProcessLaunchQmp(qemuProcessPtr proc)
> > +{
> > virDomainXMLOptionPtr xmlopt = NULL;
> > const char *machine;
> > int status = 0;
> > @@ -8226,6 +8247,77 @@ qemuProcessRun(qemuProcessPtr proc){
> > }
> >
> >
> > +/* Connect Monitor to QEMU Process
> > + */
> > +static int
> > +qemuConnectMonitorQmp(qemuProcessPtr proc)
> > +{
> > + int ret = -1;
> > +
> > + VIR_DEBUG("proc=%p, emulator=%s, proc->pid=%lld",
> > + proc, NULLSTR(proc->binary), (long long) proc->pid);
> > +
> > + ret = 0;
> > +
> > + VIR_DEBUG("ret=%i", ret);
> > + return ret;
> > +}
>
> Or this function. Looking into next patches I can see that you're
> extending them. Well, I still think it's not worth introducing empty
> functions, just do the rename as you're doing in next patches.
Yep, I was trying to make it easier to review but didn't explain well
enough from the start. Sorry I wasn't clear.
Patch 10 (this patch) and 12 are about making it possible to do simple
cut/paste moves on semi-complicated blocks of original code moved
within patches 11 and 13.
The goal was to make patches 11 and 13 easy to review because
I don't actually change the code. It's just moved.
If this seems good with the better explanation I can just try to make
that clear in the commit message for patch 10 and 12.
If it's more confusing this way I can start out with qemuProcesStartQmp
only calling qemuProcessLaunchQmp and the add qemuProcessInitQmp and
qemuConnectMonitorQmp as individual commits with full contents and just
explain that the guts are cut/paste moves with no changes in the commit
message.
The approach would be fine, but I believe Michal just didn't see any
reason to split the function in three parts in the first place.
qemuProcessStart which you're trying to mirror was split into several
phase because there is a code which needs to call the individual phases
separately so that additional logic can be put between the phases.
But it doesn't look like you need to do anything like this in your
series. So unless you want to somehow merge parts of the code for
qemuProcessStart and qemuProcessStartQmp, there's no real reason for the
split. So either you need to explain why we need to split the function
or you can drop this and the follow up patches doing the split.
And since this and the changes I suggested for the patches 1-9 may
result non-trivial changes to the other patches in this series, I'm
going to stop my series now. The main reason is that it is not entirely
obvious which of the following patches are just advancing the function
split or fixing issues introduced by the split and which of them would
be needed anyway.
So please, digest the review and send an updated version for further
review. And as explained in my reply to the cover latter, please send
both this refactoring and the new CPU related code in one series.
I hope it won't take me so long to review. I apologize for the delay
this time.
Jirka