From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LKEA6-0004Ih-6l for qemu-devel@nongnu.org; Tue, 06 Jan 2009 10:48:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LKEA5-0004IC-Uf for qemu-devel@nongnu.org; Tue, 06 Jan 2009 10:48:09 -0500 Received: from [199.232.76.173] (port=43325 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LKEA5-0004I0-IU for qemu-devel@nongnu.org; Tue, 06 Jan 2009 10:48:09 -0500 Received: from mail-bw0-f12.google.com ([209.85.218.12]:54248) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LKEA4-0004FI-Vq for qemu-devel@nongnu.org; Tue, 06 Jan 2009 10:48:09 -0500 Received: by bwz5 with SMTP id 5so14854567bwz.10 for ; Tue, 06 Jan 2009 07:48:07 -0800 (PST) Message-ID: Date: Tue, 6 Jan 2009 17:46:34 +0200 From: "Blue Swirl" Subject: Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu? In-Reply-To: <200901060841.58772.frank.mehnert@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49522F8D.4000203@turnkeylinux.org> <200901052212.06947.frank.mehnert@sun.com> <49629E9E.4000303@codemonkey.ws> <200901060841.58772.frank.mehnert@sun.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 1/6/09, Frank Mehnert wrote: > Hi, > > > On Tuesday 06 January 2009, Anthony Liguori wrote: > > Frank Mehnert wrote: > > > On Wednesday 24 December 2008, Anthony Liguori wrote: > > >> Sharing implies a two-way exchange. In reality, VirtualBox has taken a > > >> bunch of QEMU code and AFAIK has not shared any of their changes back > > >> with the QEMU community. They are completely entitled to do this of > > >> course based on the licensing of QEMU. > > > > > > Sorry, that is not true. > > > > As I said, sharing implies a two-way exchange. The VirtualBox > > development was not done publicly and to the best of my knowledge, no > > attempt has been made by the VirtualBox developers to push any of their > > changes back into QEMU. All other virtualization projects (Xen and it's > > variants, KVM, etc.) have made an attempt to push changes back to QEMU. > > > > Yes, you have a public SVN that appeared long after your development > > started. Are we supposed to troll through it looking for changes that > > > Our subversion repository is public since January 2007, so for more than > two years. It is true that we did internal releases before we started to > go public but I don't understand why do you complain. Note that we were > customer-driven from the beginning, unlike, for instance, Xen, which > was a community project when it started. > > > > may or may not be applicable to upstream? It's extraordinarily > > difficult because you've made a huge number of changes to your QEMU fork > > that have nothing to do with bug fixes. > > > Believe me, it is difficult for us too, to follow the changes in Qemu. > And we use only a part of the Qemu code. As you mentioned in an earlier > post, VirtualBox and Qemu are quite different. We execute many code > inside the guest context (for performance reasons) while Qemu recompiles > the guest code in the context of the host. We depend on the Qemu code for > more rare cases where other mechanisms don't work (e.g. real mode). So > the most changes we did were adaptions to our environment. > > > > This is not how Open Source development works. You don't make a bunch > > of changes private, put out a repo after the fact, and make no attempt > > to work with any of the projects you took the majority of your code > > from. You can call it open all you want but it simply isn't. We won't > > even get into the whole contributor agreement non-sense. > > > > >> Some of their most interesting changes (like SATA emulation, rewritten > > >> USB emulation) remain available only in their closed source version. I > > >> find that extremely unfortunate because that would be some of the > > >> easiest and most useful code to try to merge from their project. > > > > > > Some of these parts might be available under GPL in the future. > > > > That would be nice but I'm not going to hold my breathe. > > > 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. I tried to merge some slirp bits once: http://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00470.html Of course it would be much easier for all of us if someone submitted the changes one at a time, each change described properly and patches generated against current Qemu SVN.