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. -- 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
