[...]
+ +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; +}