Re: [libvirt] [PATCH v2 1/2] vbox: change how vbox API is initialized.
[...]
+
+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;
+}