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 ;-)
John
cleanup:
if (ret < 0) {
virCommandAbort(cmd);
@@ -2754,22 +2749,22 @@ qemuProcessStartPRDaemon(virDomainObjPtr vm,
[...]