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,
>
>
[...]
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
