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