Re: [PATCH] use KVMState, as upstream do

[Gleb Natapov <gleb@redhat.com>]

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.