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

[Michal Privoznik]

On 13.10.2016 23:33, Dawid Zamirski wrote:
> 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.
> 

Yes, this sounds reasonable. We certainly do not want to have a
permanent 'connection' to vboxsvc from the time daemon starts. It would
be pure waste of resources.

Michal