Re: [libvirt] [PATCH 09/13] qemu: process: Change semantics of functions starting PR daemon

On 05/14/2018 06:45 AM, Peter Krempa wrote: > Libvirt only manages one PR daemon. This means that we don't need to > pass the 'disk' object and also rename the functions dealing with this > so that it's obvious we only deal with the managed PR daemon. > > Signed-off-by: Peter Krempa <pkrempa@redhat st.com> ^^^^ Something strange happened here.

> --- > src/qemu/qemu_hotplug.c | 6 +++--- > src/qemu/qemu_process.c | 37 ++++++++++++++++--------------------- > src/qemu/qemu_process.h | 5 ++--- > 3 files changed, 21 insertions(+), 27 deletions(-) > [...] > int > -qemuProcessStartPRDaemon(virDomainObjPtr vm, > - const virDomainDiskDef *disk) > +qemuProcessStartManagedPRDaemon(virDomainObjPtr vm) > { > qemuDomainObjPrivatePtr priv = vm->privateData; > virQEMUDriverPtr driver = priv->driver; > @@ -2640,10 +2639,6 @@ qemuProcessStartPRDaemon(virDomainObjPtr vm, > const unsigned long long timeout = 500000; /* ms */ > int ret = -1; > > - if (!virStoragePRDefIsManaged(disk->src->pr) || > - priv->prDaemonRunning) > - return 0; > - > cfg = virQEMUDriverGetConfig(driver); > > if (!virFileIsExecutable(cfg->prHelperName)) { > @@ -2734,7 +2729,7 @@ qemuProcessStartPRDaemon(virDomainObjPtr vm, > goto cleanup; > > priv->prDaemonRunning = true; > - ret = 1; > + ret = 0; Unrelated, but since callers only care about < 0, no big deal... I'm assuming this is a holder from some other path which used the function for a return value (e.g. like qemuDomainMaybeStartPRDaemon) at some point during development. No big deal - I don't expect this to be extracted, but was just paying attention ;-)