[libvirt] Google Summer of Code 2014 - Rewriting Virtual-Box Driver

[Laine Stump]

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 at redhat.com
> <mailto:mprivozn at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140311/b48a1afd/attachment-0001.htm>