[PATCH 2/4] qemu_domainjob: job funcitons moved out of `qemu_domain`
Michal Privoznik
mprivozn at redhat.com
Fri Jul 10 14:36:02 UTC 2020
On 7/10/20 9:11 AM, Prathamesh Chavan wrote:
> We move functions `qemuDomainObjPrivateXMLParseJob` and
> `qemuDomainObjPrivateXMLFormatJob` to `qemu_domainjob`.
> To make this happen, corresponding changes in their
> parameters were made, as well as they were exposed
> to be used in `qemu_domain` file.
>
> Signed-off-by: Prathamesh Chavan <pc44800 at gmail.com>
> ---
> src/qemu/qemu_domain.c | 245 +-------------------------------------
> src/qemu/qemu_domainjob.c | 244 +++++++++++++++++++++++++++++++++++++
> src/qemu/qemu_domainjob.h | 8 ++
> 3 files changed, 254 insertions(+), 243 deletions(-)
>
> static bool
> qemuDomainHasSlirp(virDomainObjPtr vm)
> {
> @@ -2399,7 +2303,7 @@ qemuDomainObjPrivateXMLFormat(virBufferPtr buf,
> if (priv->lockState)
> virBufferAsprintf(buf, "<lockstate>%s</lockstate>\n", priv->lockState);
>
> - if (qemuDomainObjPrivateXMLFormatJob(buf, vm, priv) < 0)
> + if (qemuDomainObjPrivateXMLFormatJob(buf, vm) < 0)
This means, that this patch is not a plain code movement. Just for
future work, break patches into logical/semantic changes. For instance
in this case it could have been: one patch that drops the @priv argument
(since the function already gets @vm from which it can obtain @priv),
the other patch would be actual code movement.
I know it probably doesn't make much sense and I totally get it. I did
not make any sense to me when I was starting with libvirt - the end
result is the same, isn't it? What's the fuss then? but then I started
reviewing patches and realized very quickly how important it is. And
then I started backporting patches to RHEL and I realized it again :-)
But as you'll see in patch 3/4 we probably don't need to move everything.
Michal
More information about the libvir-list
mailing list