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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
