Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Frank Mehnert]

On Tuesday 06 January 2009, Anthony Liguori wrote:
> Frank Mehnert wrote:
> > Do you really know our public SVN? The majority of the code was written
> > from scratch and the most interesting parts are available for public
> > re-use.
>
> My main concern is the device model code and that code is either from
> QEMU, Bochs, of VGABIOS.  The stuff written from scratch (SATA and OHCI
> support) is not available publicly.

AFAIK, the following public available (VBox-OSE) device emulations and
host backends were written from scratch (this is our Devices/ directory):
 * the PIIX3/PIIX4 ATA controller (almost completely rewritten, you
   might find 5% of the code in the QEMU ATA emulation)
 * the generic block layer
 * support for access to host CD/DVD mediums inclusive SCSI command
   passthrough
 * backends for VDI, VMDK, VHD file formats
 * the PulseAudio backend
 * the Solaris audio backend
 * the ICH AC97 audio controller
 * the network sniffer (creates wireshark-compatible capture files)
 * the VM-internal network backend
 * the TAP device backend
 * the host network interface driver
 * the UART device + backends for named pipes and host ports
 * the VBox guest device

Furthermore we used QEMU code from the PCnet emulation, the VGA device,
the slirp NAT engine and more. Indeed, we had to change the code heavily
to make it fit to our needs. For instance, the PCnet emulation got a
send queue to speed up sending. And of course we execute a remarkable
part of the device emulation code in the guest context. These changes
are only examples, there are more. These changes are (in most cases) no
bug fixes but adaptions of the original code to our environment and
improvements which could not easily applied to QEMU due to the different
infrastructure.

> There's a lot of divergence and a lot of code restructuring (especially
> in the VGA code) that makes merging cherry picking stuff extremely
> difficult.  Most of the changes make no attempt to maintain consistency
> with the rest of QEMU.

As I tried to explain in the previous E-mail and above, the restructuration
was necessary due to the different requirements of VirtualBox. Please don't
blame us for adapting code to our needs.

Not to forget the different coding style. VBox has a uniform coding style
which is very different from QEMU, and this makes it more difficult to
exchange code between these projects.

> If ya'll are interested in merging stuff back upstream, then I'm happy
> to work with you on it.  It seems like a huge task though and, as I've
> said, I've seen no effort or interest from Sun on this.  It's really
> unfortunate because there have been many bugs found in Xen, KVM, or QEMU
> that I've gone back and seen fixes for already in VirtualBox.  Likewise,
> there are fixes in QEMU/Xen/KVM that are not in VirtualBox.  It's a huge
> amount of wasted effort.

Your original claim was that innotek/Sun used code from QEMU but does not
make bug fixes / improvements / code written from scratch available to QEMU.

You are right that there _is_ duplicate work. Unfortunately we don't have
enough ressources to employ people to adapt VirtualBox code to make it
work with QEMU. But nobody prevents you or other QEMU hackers to go through
our changesets and pick up bug fixes and port them back to QEMU. We do the
the same with the QEMU code to get fixes into VirtualBox (and we should do
this much more often).

Kind regards,

Frank
-- 
Dr.-Ing. Frank Mehnert    Sun Microsystems    http://www.sun.com/

signature.asc
Description: This is a digitally signed message part.