[libvirt] [PATCH v2 1/2] vbox: change how vbox API is initialized.

[John Ferlan]

[...]
> +
> +static vboxDriverPtr
> +vboxGetDriverConnection(void)
> +{
> +    virMutexLock(&vbox_driver_lock);
> +
> +    if (vbox_driver) {
> +        virObjectRef(vbox_driver);
> +    } else {
> +        vbox_driver = vboxDriverObjNew();
> +
> +        if (!vbox_driver) {
> +            virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> +                           _("Failed to create vbox driver object."));
> +            return NULL;
> +        }
> +    }
> +
> +    if (vboxSdkInitialize() < 0 || vboxExtractVersion() < 0) {

In this path should vboxSdkUninitialize be called (since it wouldn't be
called in the destroy path)?

I can make the adjustment before push, but figured I'd ask.

The only caveat/question being if gVBoxAPI.UPFN.Initialize(vbox_driver)
failed, then does calling gVBoxAPI.UPFN.Uninitialize(vbox_driver) have
any negative effect?

Beyond that - both patches seem fine.... Given recent discussion about
removing an older Xen driver from libvirt:

http://www.redhat.com/archives/libvir-list/2016-November/msg00911.html

causes me to wonder is there "some version" in history that perhaps can
be removed from/for vbox support? Perhaps cutting down on the number of
various variant compilation options based on some VBOX_API_VERSION?

ACK to both (I can push once you let me know about the Uninitialize call).

John


> +        virObjectUnref(vbox_driver);
> +        virMutexUnlock(&vbox_driver_lock);
> +
> +        return NULL;
> +    }
> +
> +    vbox_driver->connectionCount++;
> +
> +    virMutexUnlock(&vbox_driver_lock);
> +
> +    return vbox_driver;
> +}