[libvirt] [PATCH 3/4] vbox: change API (un)initialization logic.

[Dawid Zamirski]

On Thu, 2016-10-13 at 12:04 +0200, Martin Kletzander wrote:
> On Wed, Oct 12, 2016 at 04:00:52PM -0400, Dawid Zamirski wrote:
> > 
> > So after my initial attempts at handling this as suggested (create
> > vboxDriver struct and initialize in VIR_ONCE_GLOBAL_INIT), I've
> > stumbled upon virStateDriver structs used in other drivers that
> > apparently has .stateInitialize, .stateCleanup that to me look like
> > perfect places to call vbox's pfnComInitialize pfnComUnintialize
> > pairs.
> > Would this be a good idea to utilize the virStateDriver for this or
> > should I stick with VIR_ONCE_GLOBAL_INIT way?
> > 
> 
> 
> I just now realized you said the issue we are talking about crashes
> the
> libvirt daemon, right?  And it does not use virStateDriver?  That's
> weird.  You are connecting to vbox:///session, but the crash happens
> in
> the libvirt daemon.  That means we switched the vbox driver to the
> daemo-side driver, so I'd expect it to be stateful driver.  However
> it
> doesn't use virStateDriver.  I'm Cc'ing Michal to let him look at it
> as
> he's more handy in the whole vbox area.
> 
> > PS. Thanks a lot for reviewing my code and guiding me through it
> > all.

Yes, it's crashing libvirtd daemon, however the local one that is
started on behalf of vbox:///session owned by the user that started it
(not the system-wide one running as root). One thing I realized is that
putting pfnComInitialize into the .stateInitialize will likely make
VBoxSVC start together with libvirtd which IMO is not desired. I might
still utilize the state driver to at least initialize vboxDriver object
and obtain pFuncs reference and then defer pfnComInitialize to the
first connection that comes in, similarly as my original patch does.
That way, I might be able to make vbox driver follow the initialization
pattern used by other drivers and hopefully get rid of the
g_pVBoxGlobalData.