From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCH] use KVMState, as upstream do Date: Thu, 4 Jun 2009 23:00:46 +0300 Message-ID: <20090604200046.GE18757@redhat.com> References: <1244139783-15787-1-git-send-email-glommer@redhat.com> <20090604192329.GD18757@redhat.com> <20090604193319.GG30777@poweredge.glommer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, avi@redhat.com To: Glauber Costa Return-path: Received: from mx2.redhat.com ([66.187.237.31]:52091 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751732AbZFDUAt (ORCPT ); Thu, 4 Jun 2009 16:00:49 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n54K0pSx014574 for ; Thu, 4 Jun 2009 16:00:51 -0400 Content-Disposition: inline In-Reply-To: <20090604193319.GG30777@poweredge.glommer> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Jun 04, 2009 at 04:33:19PM -0300, Glauber Costa wrote: > On Thu, Jun 04, 2009 at 10:23:29PM +0300, Gleb Natapov wrote: > > On Thu, Jun 04, 2009 at 02:23:03PM -0400, Glauber Costa wrote: > > > This is a pretty mechanical change. To make code look > > > closer to upstream qemu, I'm renaming kvm_context_t to > > > KVMState. Mid term goal here is to start sharing code > > > whereas possible. > > > > > > Avi, please apply, or I'll send you a video of myself > > > dancing naked. > > > > > You can start recording it since I doubt this patch will apply cleanly > > to today's master (other mechanical change was applied). Regardless, I > > think trying to use bits of qemu kvm is dangerous. It has similar function > > with same names, but with different assumptions about conditional they > > can be executed in (look at commit a5ddb119). I actually prefer to be > > different enough to not call upstream qemu function by mistake. > > I did it against today's master. If new patches came in, is just > a matter of regenerating this, since it is, as I said, mechanical. > > Also, as we don't compile in upstream functions yet (kvm-all.c and kvm.c > are not included in the final object), there is no such risk. > Of course, I am aiming towards it, but the first step will be to change > the name of conflicting functions until we can pick qemu's implementation, > in which case the former will just go away. That is the point. We can't just pick qemu's implementation most of the times. > > If we are serious about merging qemu-kvm into qemu, I don't see a way out > of it. We should start changing things this way to accomodate it. Different > enough won't do. I don't really like the idea to morph working implementation to look like non-working one. I do agree that qemu-kvm should be cleaned substantially before going upstream. Upstream qemu kvm should go away than. I don't see much work done to enhance it anyway. -- Gleb.