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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/