[libvirt] [PATCH 2/2] VirtualBox support to libvirt

[Daniel Veillard]

On Tue, Mar 24, 2009 at 09:51:20AM +0100, Pritesh Kothari wrote:
> > > +/** @file vbox_tmpl.c
> > > + * Template File to support multiple versions of VirtualBox
> > > + * at runtime :).
> >
> > Can you explain a little about this idea... & how it works
> 
> First I will give the problem being faced and then how I tried to solve it.
> 
> Problem: I want to support "All" VirtualBox versions after and including 
> version 2.2 at "Runtime".
> 
> Now since VirtualBox adds Multiple new features for each release, it is but 
> natural that the C API which I use is volatile across versions and thus I 
> need a good mechanism to handle multiple versions during runtime.
> My solution was something like this:
> 
> I have a single template file called vbox_tmpl.c which is included multiple 
> times during compilation using some pre-processor magic, for example:

  I hit that last Friday while starting to review the patch an found
that a bit strange.

> /* #define NAME(name)  vbox22##name */
> vbox_V2_2.c includes vbox_tmpl.c but renames the driver as vbox22Driver, 
> similarly when i add support for 2.5 i would have
> /* #define NAME(name)  vbox25##name */
> vbox_V2_5.c which would include vbox_tmpl.c while renaming the driver as 
> vbox25Driver. This would make sure that it would include the appropriate 
> header files namely VBoxCAPI_v2_2.h and VBoxCAPI_v2_5.h respectively.
> 
> The Objects which I depend on, basically the IVirtualBox and ISession are 
> defined in these headers and change for each version depending on the 
> functionality. These Objects are nothing but structs with function pointers 
> in them (vtables equivalent of C++) and it would be disaster if i try to 
> access them if I don't have the right version and thus the crazy stuff above 
> to circumvent it.
> 
> Hope it is clear now, or else I would try to explain it in more detail again.

  That's probably worth a README in the vbox/ directory IMHO


I guess Dan did a more complete review of the code than mine. One of the
issues I had was many pieces of code licenced under the MIT Licence,
which is compatible with the LGPL, but I must admit that if you are the
authors of that code I would prefer just LGPL. I also saw parts which
were MIT but allowed to relicence under LGPL, for the sake of uniformity
I would prefer all files provided under LGPLv2 like the other parts of
libvirt code. In a sense it's equivalent for you, but for people doing
the legal review when trying to embbed libvirt this makes things more
complicated. Any chance you could fix all those headers ?

  thanks,

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/