<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 03/11/2014 08:35 AM, prashanth
sunder wrote:<br>
</div>
<blockquote
cite="mid:CAJa4tUn9qt6XM8SKx1xHfRe4xghN=Sj+VYEB8r8wd1wVVmz=9A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
</div>
Hello,<br>
<br>
</div>
I am applying for the project idea "Rewriting
Virtual-Box Driver" suggested by Michal Privoznik(<a
moz-do-not-send="true"
href="mailto:mprivozn@redhat.com">mprivozn@redhat.com</a>)
in the "Qemu" ideas page (<a
moz-do-not-send="true"
href="http://wiki.qemu.org/Google_Summer_of_Code_2014">http://wiki.qemu.org/Google_Summer_of_Code_2014</a>).
<br>
<br>
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. <br>
<br>
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 <br>
VBOX_API_VERSION <br>
<br>
that is checked during ./configure. <br>
<br>
</div>
The only thing after discussion that we were able to
come up with is putting <br>
</div>
version specific code under particular files and only
compile the those necessary <br>
</div>
files during "make"<br>
<br>
</div>
For instance, <br>
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.<br>
<br>
</div>
Any other suggestions than the above mentioned one which <br>
can be used to fix the problem??<br>
</div>
</div>
</div>
</blockquote>
<br>
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 :-)<br>
<br>
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.<br>
<br>
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.<br>
<br>
</body>
</html>