Re: [PATCH] use KVMState, as upstream do

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 04, 2009 at 11:09:52PM +0300, Gleb Natapov wrote:
> 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.
> 
too late for not wanting anything strange to happen ;-)

But I do believe this is the way to turn qemu-kvm.git into something
that feeds qemu.git. And that's what we all want.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux