On 03/11/2014 08:35 AM, prashanth sunder wrote:

Hello,

I am applying for the project idea "Rewriting Virtual-Box Driver" suggested by Michal Privoznik(mprivozn@redhat.com) in the "Qemu" ideas page (http://wiki.qemu.org/Google_Summer_of_Code_2014).

In the short span of time that I had after my discussion with Mr. Privoznik, the current Virtual Box driver code is not structured very well(lot of #ifdef's in the current code) and very hard to read.

Since libvirt has to support all versions of Virtual Box, the current code decides on what code to compile based on the value of the macro
VBOX_API_VERSION

that is checked during ./configure.

The only thing after discussion that we were able to come up with is putting
version specific code under particular files and only compile the those necessary
files during "make"

For instance,
if a function X() supports version A, B, C we will have function X() in vbox_A.c just for version A, function X() in vbox_B.c just for version B and so on.

Any other suggestions than the above mentioned one which
can be used to fix the problem??

Just a couple things off the top of my head (keeping in mind that I've never actually used virtual box or the virtual box driver, but only have suffered the pain of reviewing a few virtualbox driver patches :-)

1) I recall that there is a lot of *almost* identical code for the various versions. Rather than just moving those nearly identical pieces of code into different files for each version, it would make maintenance simpler if the essence of the difference between versions could be extracted into smaller lower-level functions that had as little shared code as possible, and were called from common top-level functions.

2) If possible, it would be nice if the code for all versions of virtualbox was always compiled, and the decision of which set of functions to use was made at runtime. (Basically, each incompatible vbox version would have a separate "backend driver" in libvirt parlance, and the dispatch table for the backend drivers would essentially be the list of low-level functions from item (1)). This way it would be possible to upgrade to a new virtualbox version without requiring a lock-step update to a libvirt that had been compiled for the new virtualbox version.