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:09:52 +0300 Message-ID: <20090604200952.GG18757@redhat.com> References: <1244139783-15787-1-git-send-email-glommer@redhat.com> <20090604192329.GD18757@redhat.com> <20090604193319.GG30777@poweredge.glommer> <20090604200046.GE18757@redhat.com> <20090604201051.GH30777@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]:42403 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751468AbZFDUJx (ORCPT ); Thu, 4 Jun 2009 16:09:53 -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 n54K9thO016566 for ; Thu, 4 Jun 2009 16:09:55 -0400 Content-Disposition: inline In-Reply-To: <20090604201051.GH30777@poweredge.glommer> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Jun 04, 2009 at 05:10:51PM -0300, Glauber Costa wrote: > On Thu, Jun 04, 2009 at 11:00:46PM +0300, Gleb Natapov wrote: > > 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. > "until we can pick up qemu's implementation" potentially involves replacing > that particular piece with upstream version first. > > > > > > > > > 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. > > > > this first phase has nothing to do with functionality. To begin with, > KVMState is qemu style, kvm_context_t is not, like it or not (I don't). > I am not against this mechanical change at all, don't get me wrong. I don't want to mix two kvm implementation together in strange ways. > I don't plan to introduce regressions, you can rest assured. But we _do_ > have to make things look much more qemuer, and that's what this patch > aims at. -- Gleb.