Re: [libvirt] [PATCH 2/2] VirtualBox support to libvirt
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/